1. Pengenalan & Motivasi

Latar belakang

Platform EQTY bergantung pada arsitektur dua lapisan:

  • Lapisan pribadi untuk mengelola rantai peristiwa yang dapat diverifikasi (mis. Ownables, pesan)

  • Lapisan jangkar publik untuk memberi cap waktu dan memverifikasi rantai peristiwa tersebut di blockchain yang tidak dapat diubah

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

Namun, konteks operasional telah berubah secara signifikan.

Mengapa LTO Layer 1 harus dihapus

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 jangkar, atau menulis ulang sejarah.

  • Untuk platform seperti EQTY — yang menjangkarkan 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 seimbang atas konsensus.

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

3. Friksi adopsi

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

  • Klien dan mitra mengharapkan EQTY untuk menjangkarkan pada jaringan publik yang diadopsi secara luas dan kredibel (mis. Ethereum, Base).

  • Persepsi "menjangkar ke Layer 1 senilai $5 juta" melemahkan kepercayaan terhadap infrastruktur inti EQTY.

4. Kerapuhan infrastruktur

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

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

Mengapa Base adalah lapisan jangkar 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 mendekati nol dengan finalitas cepat

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

Menjangkar ke Base menghilangkan beban mempertahankan Layer 1 kustom sambil meningkatkan auditabilitas, komposabilitas, dan kepercayaan.

Motivasi strategis

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

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

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

2. Token $EQTY ERC-20 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 jangkar dan pemerintahan.

Kontrak token dimulai dengan pasokan nol. $EQTY dicetak sesuai 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 menjadi dinonaktifkan secara permanen. Token LTO yang tidak dikonversi sebelum batas ini dikecualikan dari ekosistem EQTY, dan pasokan akhir $EQTY akan lebih rendah dari pasokan LTO yang asli.

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

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

3. Kontrak Jangkar di Base

Jangkar akan dilakukan melalui kontrak pintar ringan yang diterapkan di jaringan Base. Kontrak ini memancarkan peristiwa yang mencatat secara publik hash rantai peristiwa atau pesan, tanpa menyimpan status di on-chain.

Setiap jangkar memetakan kunci ke nilai, di mana:

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

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

Antarmuka

struktur Anchor {

bytes32 kunci;

nilai bytes32;

}

fungsi anchor(Anchor[] calldata anchors) eksternal;

peristiwa Dijangkarkan(

bytes32 kunci terindeks,

nilai bytes32,

alamat pengirim terindeks,

uint64 timestamp

);

Perilaku

  • Kontrak mengeluarkan satu peristiwa Dijangkarkan per pasangan (kunci, nilai).

  • Timestamp blok saat ini disertakan dalam peristiwa sebagai bidang terpisah untuk kenyamanan dan auditabilitas.

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

  • Kontrak ini tanpa izin — siapa pun dapat menjangkarkan.

Peristiwa ini dirancang untuk dapat diindeks dan diakses oleh:

  • Komponen internal, seperti pengindeks oBridge dan platform EQTY

  • Layanan eksternal, termasuk The Graph, Infura, atau verifier khusus

Dengan menjaga jangkar tanpa status dan memancarkan peristiwa lengkap, desain ini memastikan bahwa jangkar dapat diverifikasi, efisien, dan independen dari infrastruktur.

Mekanisme biaya

  • Klien perlu memanggil approve() pada kontrak ERC20 untuk mengaktifkan jangkar

  • Setiap jangkar dikenakan pembakaran $EQTY, ditegakkan dalam fungsi anchor()

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

  • Jangkar tidak akan menggunakan approve() tetapi sebagai gantinya membakar melalui eqtyToken.burnFrom(msg.sender, fee * n)

4. Pemerintahan Biaya

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

Kontrak konfigurasi khusus akan menyimpan biaya jangkar 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 jangkar 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 jangkar tetap ringan dan tanpa status di luar penegakan biaya.

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

5. Perpustakaan Lapisan Pribadi Baru

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

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

Lingkup dan isi

Hanya komponen relevan dari lapisan pribadi LTO yang akan disertakan:

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

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

  • Kode pendukung Termasuk kelas utilitas seperti Biner.

Perpustakaan ini tidak akan memiliki ketergantungan pada LTO Network:

  • Tidak ada API node LTO

  • Tidak ada logika transaksi

  • Tidak ada alat pembuatan pasangan kunci

  • Tidak ada pengkodean alamat khusus LTO

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

Model penandatanganan peristiwa

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

antarmuka ISigner {

sign(data: Uint8Array): Promise<Uint8Array>;

}

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

Integrasi jangkar

Perpustakaan ini mencakup metode untuk menghasilkan peta jangkar:

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

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

Jangkar dapat dilakukan dengan memanggil kontrak pintar 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 peristiwa, pesan ditandatangani secara asinkron menggunakan antarmuka ISigner. Tanda tangan berada di atas hash pesan, dan tidak ada kunci publik yang disertakan — hanya alamat yang diturunkan yang digunakan untuk verifikasi.

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

  • kunci = messageHash

  • nilai = 0x0

Ini memastikan bahwa pesan off-chain dapat diberi cap waktu dan diverifikasi secara publik tanpa mengungkapkan isi mereka. Jangkar 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 peristiwa dan pesan)

  • Layanan relay (untuk perhitungan hash dan parsing pesan)

  • SDK Ownables (untuk konstruksi dan pengajuan peristiwa)

  • Frontend atau verifier pihak ketiga mana pun

6. Pengindeksan oBridge

Layanan oBridge akan menggantikan logika pengindeksan berbasis LTO saat ini dengan pengindeks baru yang memproses peristiwa Dijangkarkan yang dipancarkan oleh kontrak jangkar Base.

Pengindeks ini mendengarkan log jangkar di Base dan mempertahankan basis data lokal dari jangkar terbaru per kunci, yang dapat mewakili keadaan rantai peristiwa atau hash pesan relay. Setiap entri mencakup:

  • kunci: keadaan terjankarkan atau hash pesan

  • nilai: hash peristiwa 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 jangkar LTO yang ada, termasuk titik akhir GET /hash/verify, memungkinkan komponen EQTY yang ada bertransisi dengan perubahan minimal.

Pengindeks oBridge memiliki dua peran:

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

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

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, diberi cap waktu, dan dikendalikan aksesnya, layanan ini akan diperbarui untuk mendukung baik validasi jangkar on-chain maupun otentikasi modern yang bersifat dompet-natif menggunakan Sign-In with Ethereum (SIWE).

Otentikasi Pesan dengan SIWE

Alih-alih bergantung pada tanda tangan pesan HTTP atau tantangan khusus, 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 termasuk:

  • Domain (mis. relay.eqty.network)

  • Nonce

  • Timestamp kedaluwarsa

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

  • Pernyataan: mis. "Masuk untuk mengakses pesan EQTY Anda."

  1. Klien menandatangani pesan menggunakan personal_sign

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

  3. Server memverifikasi tanda tangan dan mengeluarkan:

  • Token akses JWT (jangka pendek, mis. 15 menit)

  • Token penyegaran (jangka lebih lama, mis. 24 jam)

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

Ketika token kedaluwarsa, klien dapat menggunakan token penyegaran 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 diadopsi secara luas. Tidak ada logika atau infrastruktur khusus yang diperlukan di luar perpustakaan SIWE yang ada.

Jangkar dan Verifikasi Pesan

Selain otentikasi, layanan relay akan memverifikasi bahwa setiap pesan telah dijangkarkan di on-chain sebelum mengirimkannya. Jangkar menyediakan ketidakberubahan, cap waktu, dan mencegah spam atau serangan replay.

Relay mempertahankan pengindeks ringan sendiri untuk kontrak jangkar di Base. Ini mendengarkan peristiwa Dijangkarkan dan mencatat:

  • kunci = messageHash

  • nilai = 0x0

  • pengirim

  • blockNumber, txHash, timestamp

Untuk memverifikasi pesan sebelum pengiriman, relay memeriksa bahwa:

  • Sebuah peristiwa yang Dijangkarkan ada dengan kunci = messageHash

  • Nilai adalah tepat 0x0 (yaitu, bukan jangkar rantai peristiwa)

  • Pengirim cocok dengan penandatangan pesan (yaitu, dari alamat)

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

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

8. Perubahan Kontrak Ownable (CosmWasm)

Dengan migrasi menjauh dari LTO Layer 1 dan penghapusan penandatanganan peristiwa 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 peristiwa yang ditandatangani. Karena dompet Ethereum tidak mengungkapkan 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 mengirimkan peristiwa — 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 peristiwa cocok dengan penandatangan

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

Kecocokan CAIP-2 dan jaringan

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

  • event.network cocok dengan jaringan yang diharapkan

  • Bidang pemilik dalam peristiwa cocok dengan penandatangan (info.sender) di bawah namespace CAIP yang diberikan

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

Dampak

Perubahan ini menjadikan kontrak Ownable:

  • Sepenuhnya kompatibel dengan penandatanganan dan identitas native Ethereum

  • Independen dari infrastruktur kunci LTO

  • Kompatibel dengan rantai mana pun yang mendukung pemulihan berbasis alamat (mis. EVM)

Ownables yang ada, yang bergantung pada penandatanganan dan jangkar khusus 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 pergeseran dari penandatanganan kunci publik berbasis LTO ke otorisasi berbasis alamat gaya Ethereum dan jangkar Base.

Pembaruan kunci

  1. Penandatanganan peristiwa

  • Perbarui pembuatan peristiwa 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. Jangkar

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

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

  • Pastikan penjangkaran 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 jangkar cocok dengan hash peristiwa yang diharapkan dan bahwa pengirim cocok dengan alamat Ethereum penandatangan

  1. Penggunaan alamat

  • Ganti logika yang membandingkan atau menghasilkan alamat LTO

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

Kompatibilitas

SDK yang diperbarui tetap secara struktural mirip tetapi tidak lagi terikat pada perpustakaan @ltonetwork/lto-api.js atau layanan node LTO. Ini kompatibel dengan perpustakaan lapisan pribadi baru dan jangkar 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 titik akhir RPC publik

  1. Penandatanganan peristiwa dan pesan

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

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

  1. Jangkar

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

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

  1. Integrasi relay

  • Autentikasi melalui SIWE (Sign-In dengan Ethereum)

  • Simpan dan segarkan token akses sesuai kebutuhan

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

Fitur yang dihapus

  • Antarmuka penyewa 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 jangkar baru di Base, semua komponen inti protokol harus bermigrasi. Data warisan yang terikat pada infrastruktur LTO — termasuk jangkar, rantai peristiwa, dan pesan — tidak akan lagi valid.

Apa yang menjadi tidak valid

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

  • Jangkar yang dicatat di LTO L1 tidak dapat dipercaya atau ditanyakan ke depan.

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

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

Tindakan yang diperlukan

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

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

  3. Transisi dompet Pengguna perlu memperbarui Dompet Universal.

Tidak ada snapshot

Tidak akan ada snapshot, migrasi otomatis, atau lapisan kompatibilitas mundur. Setiap komponen (peristiwa, pesan, saldo token) harus dibangun kembali di Base melalui antarmuka yang tepat. Protokol baru bersih secara desain dan tidak mempertahankan keterikatan pada LTO L1.

#ETH