1. Pengenalan & Motivasi

Latar Belakang

Platform EQTY bergantung pada arsitektur dua lapisan:

  • Sebuah lapisan pribadi untuk mengelola rantai acara yang dapat diverifikasi (misalnya Ownables, pesan)

  • Sebuah lapisan pengikatan publik untuk memberi cap waktu dan memverifikasi rantai acara tersebut di blockchain yang tidak dapat diubah

Secara historis, lapisan publik ini disediakan oleh LTO Network Layer 1, sebuah blockchain Proof-of-Stake yang ditujukan untuk pengikatan.

Namun, konteks operasional telah berubah secara signifikan.

Mengapa LTO Layer 1 harus didepresiasi

1. Keamanan ekonomi telah runtuh

  • LTO saat ini memiliki kapitalisasi pasar di bawah $5 juta, dengan hanya ~20% token yang dipertaruhkan.

  • Ini berarti anggaran keamanan yang efektif (yaitu, total nilai yang mengamankan konsensus) adalah < $1 juta.

  • Pada tingkat ini, secara finansial layak bagi aktor jahat untuk mengkompromikan konsensus, menyensor transaksi pengikatan, atau menulis ulang sejarah.

  • Untuk platform seperti EQTY — yang mengikat catatan aset yang dapat ditegakkan secara hukum — ini tidak dapat diterima.

2. Sentralisasi validator dan insentif rendah

  • Node komunitas tidak lagi layak secara ekonomi.

  • Node yang mengakhiri layanan dapat menyebabkan seperangkat kecil node memegang kontrol yang tidak proporsional atas konsensus.

  • Ini merusak jaminan desentralisasi yang dimaksudkan untuk diberikan oleh pengikatan.

3. Gesekan adopsi

  • Semakin sulit untuk membenarkan LTO sebagai lapisan pengikatan yang aman dalam percakapan penjualan atau audit.

  • Klien dan mitra mengharapkan EQTY untuk mengikat di jaringan publik yang diterima luas dan kredibel (misalnya Ethereum, Base).

  • Persepsi tentang “pengikatan ke Layer 1 senilai $5 juta” melemahkan kepercayaan pada infrastruktur inti EQTY.

4. Kerentanan infrastruktur

  • Jika bahkan beberapa validator kunci offline, LTO menjadi tidak stabil atau berhenti sepenuhnya.

  • Pemeliharaan berkelanjutan (penjelajah, pengindeks, infrastruktur node) menambah beban dengan nilai yang menyusut.

Mengapa Base adalah lapisan pengikatan yang tepat

Base menawarkan:

  • Kompatibilitas EVM penuh

  • Keamanan ekonomi dan teknis yang diwarisi dari Ethereum

  • Dukungan alat yang luas (MetaMask, WalletConnect, The Graph, dll.)

  • Biaya hampir nol dengan finalitas cepat

  • Penyesuaian yang dekat dengan lapisan aset dan likuiditas EQTY, yang juga berada di Base

Pengikatan ke Base menghapus beban pemeliharaan Layer 1 kustom sambil meningkatkan auditabilitas, komposabilitas, dan kepercayaan.

Motivasi strategis

  • Nilai EQTY tidak ada dalam konsensus — ada di lapisan pribadinya, model aset, dan arsitektur kepatuhan.

  • Mempertahankan Layer 1 menawarkan sedikit keuntungan strategis dengan biaya tinggi.

  • Berpindah ke Base memungkinkan EQTY untuk fokus sepenuhnya pada adopsi produk, integrasi hukum, dan tokenisasi aset, tanpa terhambat oleh infrastruktur Layer 1.

2. Token ERC-20 $EQTY Baru

Platform EQTY akan memperkenalkan token ERC-20 baru, $EQTY, yang diterapkan di jaringan Base. Token ini menggantikan token LTO dan berfungsi sebagai mata uang asli untuk operasi protokol, termasuk pengikatan dan pemerintahan.

Kontrak token dimulai dengan pasokan nol. $EQTY dicetak berdasarkan permintaan ketika pengguna menukar token LTO mereka selama periode migrasi terbatas. Jendela ini ditegakkan di on-chain: setelah tinggi blok yang telah ditentukan, fungsi mint akan dinonaktifkan secara permanen. Token LTO yang tidak ditukar sebelum batas ini dikecualikan dari ekosistem EQTY, dan pasokan $EQTY yang terakhir akan lebih rendah daripada pasokan LTO yang asli.

Kontrak token sengaja minimal. Ini mengikuti antarmuka standar ERC-20, tanpa logika transfer khusus, fitur airdrop, atau jadwal vesting.

Token $EQTY akan digunakan untuk membayar biaya pengikatan, berpartisipasi dalam pemerintahan protokol, dan berpotensi mendukung peran utilitas tambahan seiring evolusi platform. Utilitas memerlukan token untuk dibakar, mengurangi pasokan keseluruhan.

3. Kontrak Anchor di Base

Pengikatan akan dilakukan melalui kontrak pintar ringan yang diterapkan di jaringan Base. Kontrak ini mengeluarkan acara yang mencatat secara publik hash dari rantai acara atau pesan, tanpa menyimpan status on-chain apa pun.

Setiap anchor memetakan kunci ke nilai, di mana:

  • Untuk rantai acara: kunci = stateHash, nilai = eventHash

  • Untuk pesan: kunci = messageHash, nilai = 0x0

Antarmuka

struktur Anchor {

bytes32 kunci;

nilai bytes32;

}

fungsi anchor(Anchor[] calldata anchors) eksternal;

acara Terikat(

bytes32 kunci yang diindeks,

nilai bytes32,

alamat pengirim yang diindeks,

uint64 cap waktu

);

Perilaku

  • Kontrak mengeluarkan satu acara Terikat per pasangan (kunci, nilai).

  • Cap waktu blok saat ini disertakan dalam acara sebagai bidang terpisah untuk kenyamanan dan auditabilitas.

  • Tidak ada status yang disimpan dalam kontrak. Semua data pengikatan dicatat melalui log saja.

  • Kontrak bersifat tanpa izin — siapa pun dapat mengikat.

Acara ini dirancang untuk dapat diindeks dan diakses oleh:

  • Komponen internal, seperti pengindeks oBridge dan platform EQTY

  • Layanan eksternal, termasuk The Graph, Infura, atau verifikator kustom

Dengan menjaga pengikatan tanpa status dan mengeluarkan acara lengkap, desain ini memastikan bahwa pengikatan dapat diverifikasi, efisien, dan independen dari infrastruktur.

Mekanisme biaya

  • Klien perlu memanggil approve() pada kontrak ERC20 untuk mengizinkan pengikatan

  • Setiap anchor mengakibatkan pembakaran $EQTY, yang ditegakkan dalam fungsi anchor()

  • Jumlah biaya dibaca dari kontrak konfigurasi terpisah yang dikendalikan oleh pemerintahan

  • Pengikatan tidak akan menggunakan approve() tetapi sebaliknya membakar melalui eqtyToken.burnFrom(msg.sender, fee * n)

4. Pemerintahan Biaya

Untuk menjaga pengikatan tetap berkelanjutan secara ekonomi dan adil seiring waktu, biaya yang dibayar dalam $EQTY per anchor harus dapat disesuaikan. Alih-alih mengkodekan biaya statis atau bergantung pada oracle harga, EQTY akan menggunakan model pemerintahan on-chain untuk mengontrol parameter ini dengan cara yang transparan dan terdesentralisasi.

Kontrak konfigurasi yang ditujukan akan menyimpan biaya pengikatan saat ini. Nilai ini hanya dapat diperbarui oleh kontrak pemerintahan — khususnya, sebuah instance dari Gubernur OpenZeppelin yang terikat pada token $EQTY. Suara akan diberikan berdasarkan saldo $EQTY menggunakan logika standar ERC20Votes.

Kontrak pengikatan membaca biaya saat ini dari kontrak konfigurasi setiap kali anchor() dipanggil. Kemudian membakar jumlah $EQTY yang sesuai langsung dari saldo pengirim. Pendekatan ini menghindari kebutuhan untuk transaksi approve() dan memastikan bahwa kontrak pengikatan tetap ringan dan tanpa status di luar penegakan biaya.

Model pemerintahan memungkinkan komunitas untuk menyesuaikan biaya seiring waktu sebagai respons terhadap kondisi pasar, fluktuasi harga token, atau perubahan permintaan pengikatan — tanpa bergantung pada sumber data eksternal atau kontrol terpusat.

5. Perpustakaan Lapisan Pribadi Baru

Untuk mendukung pengikatan di Base dan penandatanganan berbasis dompet, sebuah perpustakaan TypeScript mandiri baru akan dibuat untuk menangani logika lapisan pribadi — termasuk rantai acara, penandatanganan acara, pengikatan, dan struktur pesan relay. Perpustakaan ini menggantikan @ltonetwork/lto-api.js yang spesifik untuk LTO untuk semua kasus penggunaan EQTY.

Perpustakaan baru dirancang untuk digunakan di lingkungan browser (misalnya MetaMask, WalletConnect) dan alat sisi server.

Ruang lingkup dan isi

Hanya komponen relevan dari lapisan pribadi LTO yang akan dimasukkan:

  • events/ Termasuk Event, EventChain, MergeConflict, dan logika serialisasi terkait.

  • message/ Termasuk Message dan Relay, digunakan untuk komunikasi terenkripsi off-chain.

  • Kode pendukung Termasuk kelas utilitas seperti Binary.

Perpustakaan ini tidak akan memiliki ketergantungan pada Jaringan LTO:

  • Tidak ada API node LTO

  • Tidak ada logika transaksi

  • Tidak ada alat pembuatan pasangan kunci

  • Tidak ada pengkodean alamat khusus LTO

Ini akan mendukung pengikatan melalui kontrak pintar di Base, dan terintegrasi dengan bersih dengan ethers.js untuk menandatangani dan mengajukan pengikatan.

Model penandatanganan acara

Metode Event.signWith() akan dibuat asinkron untuk mendukung penandatanganan berbasis browser melalui MetaMask, WalletConnect, atau penandatangan eksternal mana pun, selain menandatangani langsung dengan ethers. Ini menggunakan antarmuka ISigner abstrak:

antarmuka ISigner {

tandai(data: Uint8Array): Janji<Uint8Array>;

}

Acara yang ditandatangani tidak lagi memerlukan kunci publik; hanya tanda tangan dan alamat yang diturunkan yang disertakan. Ini membuatnya kompatibel dengan aliran penandatanganan Ethereum (personal_sign) dan menghilangkan kebutuhan untuk mengekstrak kunci publik, yang tidak mungkin dilakukan di sebagian besar lingkungan dompet.

Integrasi pengikatan

Perpustakaan ini mencakup metode untuk menghasilkan peta anchor:

const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();

Setiap anchor memetakan stateHash (kunci) ke lastEventHash (nilai), siap untuk diajukan ke kontrak pintar Base. Untuk pesan relay, hash pesan itu sendiri digunakan sebagai kunci anchor, dan nilainya diatur ke nol (0x0).

Pengikatan dapat dilakukan dengan memanggil kontrak pintar secara langsung melalui ethers.Contract.anchor(Anchor[]). Ini menghindari ketergantungan pada layanan backend atau infrastruktur kepemilikan.

Penandatanganan pesan

Perpustakaan ini juga mencakup kelas Pesan dan Relay untuk komunikasi off-chain. Seperti acara, pesan ditandatangani secara asinkron menggunakan antarmuka ISigner. Tanda tangan adalah atas hash pesan, dan tidak ada kunci publik yang disertakan — hanya alamat yang diturunkan yang digunakan untuk verifikasi.

Setelah menandatangani, hash pesan diikat di on-chain melalui kontrak Anchor yang sama. Formatnya adalah:

  • kunci = messageHash

  • nilai = 0x0

Ini memastikan bahwa pesan off-chain dapat diberi cap waktu secara publik dan diverifikasi tanpa mengungkapkan isinya. Pengikatan dapat dilakukan oleh pengirim atau layanan relay.

Penerapan dan penggunaan

Perpustakaan ini akan diterbitkan sebagai paket NPM terpisah. Ini dimaksudkan untuk menjadi inti bersama yang digunakan oleh:

  • Dompet EQTY (untuk penandatanganan acara dan pesan)

  • Layanan relay (untuk perhitungan hash dan parsing pesan)

  • SDK Ownables (untuk konstruksi dan pengiriman acara)

  • Antarmuka pihak ketiga mana pun atau verifikator

6. Pengindeksan oBridge

Layanan oBridge akan mengganti logika pengindeksan berbasis LTO saat ini dengan pengindeks baru yang memproses acara Terikat yang dikeluarkan oleh kontrak pengikatan Base.

Pengindeks ini mendengarkan log pengikatan di Base dan mempertahankan database lokal dari anchor terbaru per kunci, yang dapat mewakili baik status rantai acara atau hash pesan relay. Setiap entri mencakup:

  • kunci: status yang diikat atau hash pesan

  • nilai: hash acara yang sesuai atau 0x0

  • txHash, blockNumber, logIndex, dan pengirim

Catatan ini diekspos melalui API HTTP publik. Struktur dan perilaku API ini akan tetap kompatibel dengan pengindeks pengikatan LTO yang ada, termasuk endpoint GET /hash/verify, memungkinkan komponen EQTY yang ada untuk bertransisi dengan perubahan minimal.

Pengindeks oBridge memiliki dua peran:

  1. Sebagai ketergantungan internal untuk layanan relay, yang harus memverifikasi bahwa pesan telah diikat sebelum melepaskannya.

  2. Sebagai layanan verifikasi publik untuk klien dan dompet eksternal yang ingin memeriksa status pengikatan tanpa menanyakan Base secara langsung.

Semua data tetap dapat diverifikasi di on-chain, dan klien dapat melewati oBridge jika diinginkan dengan menggunakan eth_getLogs atau pengindeks mereka sendiri.

7. Layanan Relay

Layanan relay menangani pengiriman aman pesan terenkripsi antara pihak-pihak. Untuk memastikan pesan autentik, bertanggal, dan terkendali aksesnya, layanan akan diperbarui untuk mendukung validasi pengikatan on-chain dan autentikasi modern, berbasis dompet menggunakan Sign-In with Ethereum (SIWE).

Otentikasi Pesan dengan SIWE

Alih-alih bergantung pada tanda tangan pesan HTTP atau tantangan kustom, relay akan menerapkan standar SIWE (EIP-4361). Pendekatan ini memungkinkan pengguna untuk mengautentikasi dengan menandatangani pesan teks standar dengan dompet Ethereum mereka, menghasilkan tanda tangan yang dapat dipulihkan yang mengikat mereka ke sesi.

Alur masuk:

  1. Klien meminta pesan SIWE dari backend relay: GET /auth/siwe-message?address=0x...

  2. Server mengembalikan pesan SIWE standar yang mencakup:

  • Domain (misalnya relay.eqty.network)

  • Nonce

  • Cap waktu kedaluwarsa

  • Bidang sumber daya opsional dibatasi pada /messages?to=...

  • Pernyataan: misalnya, “Masuk untuk mengakses pesan EQTY Anda.”

  1. Klien menandatangani pesan menggunakan personal_sign

  2. Klien mengirimkan pesan yang ditandatangani dan tanda tangan untuk POST /auth/verify

  3. Server memverifikasi tanda tangan dan mengeluarkan:

  • Token akses JWT (jangka pendek, misalnya 15 menit)

  • Token penyegar (jangka panjang, misalnya 24 jam)

Semua permintaan pengambilan pesan berikutnya (GET /messages?to=...) harus menyertakan token akses di header Otorisasi.

Ketika token kedaluwarsa, klien dapat menggunakan token penyegar untuk mendapatkan token akses baru tanpa perlu menandatangani ulang.

Model ini sepenuhnya kompatibel dengan MetaMask, WalletConnect, dan dompet EIP-1193 lainnya, dan mengikuti pola keamanan yang diterima secara luas. Tidak diperlukan logika atau infrastruktur khusus selain perpustakaan SIWE yang ada.

Pengikatan dan Verifikasi Pesan

Selain otentikasi, layanan relay akan memvalidasi bahwa setiap pesan telah diikat di on-chain sebelum mengirimkannya. Pengikatan memberikan ketidakberdayaan, cap waktu, dan mencegah spam atau serangan replay.

Relay mempertahankan pengindeks ringan untuk kontrak pengikatan di Base. Ini mendengarkan acara Terikat dan mencatat:

  • kunci = messageHash

  • nilai = 0x0

  • pengirim

  • nomorBlok, txHash, cap waktu

Untuk memverifikasi pesan sebelum pengiriman, relay memeriksa bahwa:

  • Acara Terikat ada dengan kunci = messageHash

  • Nilainya persis 0x0 (yaitu bukan pengikat rantai acara)

  • Pengirim cocok dengan penanda tangan pesan (yaitu alamat dari)

Hanya setelah pengikatan yang berhasil, pesan dirilis kepada penerima. Ini memastikan semua pesan dapat diverifikasi secara publik, diberi cap waktu di Base, dan diikat oleh identitas yang benar.

Layanan relay melakukan verifikasi ini menggunakan pengindeks internalnya sendiri dan tidak bergantung pada oBridge.

8. Perubahan Kontrak Ownable (CosmWasm)

Dengan migrasi dari LTO Layer 1 dan penghapusan penandatanganan acara berbasis kunci publik, kontrak Ownable harus diperbarui untuk mendukung otorisasi berbasis alamat menggunakan alamat Ethereum standar.

Otorisasi berbasis alamat

Sebelumnya, verifikasi kepemilikan bergantung pada pemulihan dan perbandingan kunci publik yang diekstrak dari acara yang ditandatangani. Karena dompet Ethereum tidak mengekspos kunci publik, dan tanda tangan sekarang menggunakan personal_sign (dapat dipulihkan ke alamat), model verifikasi harus beralih ke perbandingan alamat secara langsung.

Logika kontrak yang diperbarui menggunakan info.sender — alamat yang menandatangani dan mengajukan acara — sebagai identitas otoritatif.

Ini mempengaruhi semua titik masuk di mana otorisasi diperlukan:

  • try_transfer: pengirim harus cocok dengan alamat pemilik saat ini

  • try_release: pengirim harus cocok dengan alamat pemilik yang terkunci sebelumnya

  • try_register_lock: memverifikasi bahwa bidang pemilik acara cocok dengan penanda tangan

Alih-alih mengonversi kunci publik ke alamat LTO, kontrak cukup menyimpan dan membandingkan nilai Addr (misalnya 0xabc123...).

CAIP-2 dan pencocokan jaringan

Kontrak terus memvalidasi asal acara lintas rantai menggunakan pengidentifikasi jaringan CAIP-2. Untuk pesan berbasis Ethereum, ruang nama adalah eip155:<chainId>. Kontrak memverifikasi bahwa:

  • Jaringan acara cocok dengan jaringan yang diharapkan

  • Bidang pemilik dalam acara cocok dengan penanda tangan (info.sender) di bawah ruang nama CAIP yang diberikan

Fungsi konversi address_lto() dan address_eip155() dapat dihapus, karena tidak ada terjemahan ke atau dari alamat LTO yang dibutuhkan lagi.

Dampak

Perubahan ini membuat kontrak Ownable:

  • Sepenuhnya kompatibel dengan penandatanganan dan identitas berbasis Ethereum

  • Independen dari infrastruktur kunci LTO

  • Kompatibel dengan rantai mana pun yang mendukung pemulihan berbasis alamat (misalnya, EVM)

Ownables yang ada, yang bergantung pada penandatanganan dan pengikatan yang spesifik untuk LTO, akan menjadi tidak dapat diverifikasi di bawah model baru dan harus diterbitkan kembali (lihat Bagian 11).

9. Pembaruan SDK Ownables

SDK Ownables harus diperbarui untuk mencerminkan peralihan dari penandatanganan kunci publik berbasis LTO ke otorisasi berbasis alamat gaya Ethereum dan pengikatan Base.

Pembaruan kunci

  1. Penandatanganan acara

  • Perbarui pembuatan acara untuk menggunakan perpustakaan lapisan pribadi baru (@eqty-core/events)

  • Gunakan implementasi ISigner yang kompatibel dengan MetaMask, WalletConnect, atau penandatangan berbasis ethers

  • Pastikan signWith() tidak lagi bergantung pada kunci publik; hanya alamat yang dapat dipulihkan yang digunakan

  1. Pengikatan

  • Ganti logika pengikatan node LTO dengan pengajuan kontrak pintar di Base

  • Gunakan getAnchorMap() untuk mengumpulkan pasangan (kunci, nilai) dan mengajukannya melalui ethers.Contract.anchor()

  • Pastikan pengikatan pesan menggunakan (kunci = messageHash, nilai = 0x0)

  1. Verifikasi

  • Perbarui logika verifikasi untuk menggunakan API /hash/verify yang kompatibel dengan oBridge atau kueri log langsung

  • Konfirmasi bahwa nilai anchor cocok dengan hash acara yang diharapkan dan bahwa pengirim cocok dengan alamat Ethereum dari penanda tangan

  1. Penggunaan alamat

  • Ganti logika apa pun yang membandingkan atau menghasilkan alamat LTO

  • Gunakan alamat Ethereum biasa (0x...) di seluruh aliran acara dan pesan

Kompatibilitas

SDK yang diperbarui tetap serupa secara struktural tetapi tidak lagi terikat pada perpustakaan @ltonetwork/lto-api.js atau layanan node LTO. Ini kompatibel dengan perpustakaan lapisan pribadi baru dan pengikatan Base, dan akan berinteraksi dengan kontrak Ownable yang diperbarui dan layanan relay.

10. Pembaruan Dompet Universal

Dompet universal harus diperbarui untuk mencerminkan migrasi ke Base dan arsitektur EQTY yang baru. Ini tidak lagi berinteraksi dengan node LTO.

Pembaruan inti

  1. Koneksi dompet

  • Ganti penanganan pasangan kunci LTO dengan perpustakaan yang kompatibel dengan Ethereum (ethers.js)

  • Gunakan antarmuka penyedia EIP-1193 untuk memungkinkan penandatanganan dan pengambilan alamat

  1. Dukungan token

  • Tambahkan dukungan untuk menampilkan dan mengelola saldo token ERC-20 $EQTY yang baru di Base

  • Sertakan metadata token, riwayat, dan pelacakan saldo melalui endpoint RPC publik

  1. Penandatanganan acara dan pesan

  • Integrasikan perpustakaan lapisan pribadi baru untuk memungkinkan pengguna membuat dan menandatangani rantai acara dan pesan

  • Gunakan personal_sign melalui dompet yang terhubung; kunci publik tidak lagi diperlukan

  1. Pengikatan

  • Kirim peta anchor langsung ke kontrak anchor Base menggunakan ethers.js

  • Tangani pengajuan on-chain, konfirmasi, dan umpan balik UI opsional untuk biaya pengikatan dalam $EQTY

  1. Integrasi relay

  • Otentikasi melalui SIWE (Sign-In with Ethereum)

  • Simpan dan segarkan token akses sesuai kebutuhan

  • Gunakan permintaan yang terautentikasi untuk mengambil pesan terenkripsi dari layanan relay

Fitur yang dihapus

  • UI leasing LTO

  • Pemilihan node dan tampilan rantai

  • Manajemen identitas on-chain yang terikat pada LTO

11. Rencana Migrasi

Dengan penghapusan LTO Layer 1 dan pengenalan sistem pengikatan baru di Base, semua komponen inti protokol harus bermigrasi. Data warisan yang terikat pada infrastruktur LTO — termasuk pengikatan, rantai acara, dan pesan — tidak akan lagi valid.

Apa yang menjadi tidak valid

  • Rantai acara yang ditandatangani menggunakan pasangan kunci LTO tidak dapat diverifikasi, karena kunci publik tidak lagi dapat diekstrak dari tanda tangan berbasis Ethereum.

  • Pengikatan yang dicatat di LTO L1 tidak dapat dipercaya atau ditanyakan ke depannya.

  • Kepemilikan yang terikat pada identitas berbasis LTO atau rantai yang terikat harus diganti.

  • Pesan yang tidak terikat di Base akan ditolak oleh layanan relay.

Tindakan yang diperlukan

  1. Migrasi tokenPengguna harus secara manual menukar token LTO mereka dengan $EQTY menggunakan jembatan. Pencetakan hanya dimungkinkan hingga ketinggian blok tertentu di Base. Setelah blok ini, jembatan akan ditutup dan fungsi mint dinonaktifkan secara permanen. Token LTO yang tidak ditukar menjadi tidak bernilai.

  2. Mengeluarkan Aset Ownables.Penerbit Ownable harus menerbitkan ownables baru yang terikat pada jaringan BASE. Instruksi akan menyusul tentang cara menukar legacy Ownables menjadi Ownables baru

  3. Transisi dompet Pengguna perlu memperbarui Dompet Universal.

Tidak ada snapshot

Tidak akan ada snapshot, migrasi otomatis, atau lapisan kompatibilitas ke belakang. Setiap komponen (acara, pesan, saldo token) harus dibangun kembali di Base melalui antarmuka yang tepat. Protokol baru ini bersih secara desain dan tidak mempertahankan hubungan dengan LTO L1.

#ETH