Cara Memindahkan Token Antara TON dan Ethereum Tanpa Jembatan Tradisional
Memindahkan token antara TON dan Ethereum dulu sangat identik dengan satu arsitektur yang sudah familiar: menggunakan jembatan, mengunci aset di salah satu jaringan, menunggu sistem mengenali transaksi, lalu menerima representasi atau likuiditas yang dilepaskan di sisi lainnya.
Namun infrastruktur lintas-rantai telah berkembang.
Saat ini, pengguna dapat mendekati masalah yang sama dari arah yang berbeda: alih-alih bertanya, “Bagaimana cara saya mentransfer aset ini ke blockchain lain?”, mereka dapat bertanya, “Aset apa yang ingin saya terima di blockchain lain?”
Perbedaan itu ada di inti swap lintas-chain berbasis resolver.
Dengan arsitektur swap-first seperti Omniston, yang dikembangkan oleh STON.fi, tujuannya bukan sekadar memindahkan aset antara TON dan Ethereum. Sistem ini mengoordinasikan pertukaran antara aset di dua blockchain independen. Seorang resolver menyediakan likuiditas di sisi tujuan, sementara kontrak Hashed Timelock Contracts (HTLC) yang terhubung menghubungkan kedua sisi transaksi tersebut.
Hasil dirancang berdasarkan prinsip penting: swap harus menyelesaikan sesuai kondisi di kedua sisi atau mengembalikan dana yang dikunci melalui mekanisme timelock.
Mengapa Memindahkan Nilai Antara TON dan Ethereum?
Blockchain adalah lingkungan yang terisolasi. Ethereum tidak secara inheren mengetahui apa yang terjadi di TON dan TON juga tidak secara inheren mengetahui apa yang terjadi di Ethereum. Memindahkan nilai di antara keduanya karena itu membutuhkan suatu mekanisme untuk mengoordinasikan aktivitas lintas dua jaringan tersebut.
Alasan pengguna ingin koordinasi itu biasanya praktis.
Seorang pengguna yang memegang aset di Ethereum mungkin ingin akses ke DeFi berbasis TON, token asli TON, peluang likuiditas yang berbeda, atau kemungkinan biaya transaksi yang lebih rendah untuk aktivitas berikutnya. Sebaliknya, pengguna TON mungkin ingin akses ke likuiditas Ethereum, aplikasi berbasis EVM, atau aset yang terutama ada di ekosistem Ethereum.
Poin pentingnya adalah pengguna biasanya punya tujuan hasil di benak, bukan preferensi terhadap infrastrukturnya.
Seseorang mungkin memulai dengan USDT di Ethereum dan benar-benar ingin USDT di TON. Pengguna lain mungkin memegang aset di TON tetapi ingin token atau stablecoin berbasis Ethereum. Dalam kedua kasus, sekadar memindahkan representasi yang setara melintasi jaringan hanya sebagian dari masalah.
Di sinilah perbedaan antara arsitektur bridge-first dan swap-first menjadi penting.
Bridge First vs Swap First
Bridge tradisional terutama dirancang untuk memindahkan nilai dari satu blockchain ke blockchain lain.
Pada model lock-and-mint klasik, aset sumber dikunci dalam kontrak bridge. Jaringan tujuan kemudian menerima representasi wrapped atau mirrored. Arsitektur bridge lain bisa menggunakan likuiditas sisi tujuan alih-alih melakukan mint aset yang wrapped, tetapi tujuan utamanya tetap memindahkan nilai antar jaringan.
Alur bridge-first yang tipikal karenanya terlihat seperti:
Aset di Ethereum → bridge → representasi aset di TON → swap opsional → aset TON yang diinginkan
Pengguna menyelesaikan transfer lintas-chain terlebih dahulu, lalu menangani konversi apa pun yang diperlukan setelah kedatangan.
Pendekatan swap-first membalik perspektif:
Aset di Ethereum → penawaran lintas-chain → aset tujuan di TON
Alih-alih menjadikan representasi perantara sebagai kekhawatiran utama pengguna, rute dibangun di sekitar aset yang benar-benar ingin diterima pengguna.
Ini salah satu alasan mengapa produk lintas-chain modern terasa jauh berbeda dari alur kerja bridge tradisional. Swap lintas-chain menggabungkan perpindahan antar jaringan dengan proses pertukaran itu sendiri, sehingga aset tujuan akhir menjadi bagian dari pesanan awal.
Tidak satu pun arsitektur yang seharusnya dipahami hanya sebagai antarmuka yang berbeda. Keduanya membuat asumsi yang berbeda tentang custody, likuiditas, penyelesaian, dan apa yang diterima pengguna di akhir.
Bridge-first: transport pertama
Misalkan seorang pengguna memiliki aset di Ethereum dan ingin ikut serta dalam TON DeFi.
Sebuah bridge mungkin memindahkan nilai ke TON terlebih dahulu. Bergantung pada arsitektur bridge, pengguna bisa menerima token wrapped atau representasi lain yang didukung oleh bridge tersebut.
Prosesnya mungkin kemudian memerlukan swap lain ke token yang benar-benar dibutuhkan untuk aplikasi TON yang diinginkan.
Itu menciptakan tanggung jawab tambahan dalam manajemen rute. Pengguna harus memahami bukan hanya cara melewati batas jaringan, tetapi juga apakah token hasilnya diterima oleh protokol tujuan.
Swap-first: outcome pertama
Dengan swap lintas-chain, pengguna menentukan aset sumber dan aset tujuan.
Sebagai contoh:
Ethereum USDT → TON USDT
Sistem tidak perlu memberi pengguna representasi Ethereum yang dibungkus (wrapped) di TON lalu meminta mereka melakukan konversi lain. Sebaliknya, penyedia likuiditas sisi tujuan dapat menyediakan aset sisi TON yang diminta secara langsung.
Itulah gagasan arsitektural di balik Omniston.
Pertanyaan penting berubah dari:
“Bagaimana caranya saya memindahkan token ini ke seberang?”
kepada:
“Apa yang ingin saya terima di chain lainnya?”
Apa yang Sebenarnya Diterima Pengguna?
Ini adalah salah satu perbedaan paling penting untuk dipahami.
Sebuah bridge dapat memindahkan nilai sambil meninggalkan pengguna dengan representasi wrapped atau mirrored dari aset aslinya. Representasi itu mungkin sepenuhnya berguna, tetapi dapat menimbulkan pertimbangan lain: apakah protokol tujuan mendukung versi tertentu tersebut.
Arsitektur swap-first menargetkan aset tujuan secara langsung.
Misalnya, bayangkan seorang pengguna memulai dengan USDT di Ethereum dan meminta USDT di TON melalui rute yang didukung Omniston.
Hasil yang diinginkan bukan representasi USDT yang dibungkus (wrapped) di TON versi Ethereum. Resolver menyediakan aset sisi tujuan yang diminta, sehingga pengguna menerima token sisi TON yang sesuai secara langsung. STON.fi menyebut ini sebagai perbedaan praktis antara melakukan bridging ke wrapped Jetton dan melakukan swap atomik ke aset tujuan melalui Omniston.
Prinsip yang sama juga berlaku untuk arah sebaliknya.
Seorang pengguna mungkin memulai dengan aset TON dan meminta token Ethereum. Tujuan ditentukan oleh penawaran dan pesanan, bukan sekadar menyalin aset sumber pada chain lain.
Perbedaan itu membuat arsitektur ini sangat berguna untuk pengguna yang sudah tahu apa yang ingin mereka lakukan setelah transaksi lintas-chain tersebut.
Di Mana Eksekusi Berbasis Resolver Masuk
Pertanyaan berikutnya sudah jelas:
Jika tidak ada vault bridge tradisional yang menampung aset pengguna dan menerbitkan representasi wrapped, siapa yang menyediakan aset di chain lainnya?
Jawabannya adalah resolver.
Resolver adalah penyedia likuiditas yang berpartisipasi dalam jaringan Omniston. Ia mengevaluasi permintaan yang masuk, memberikan penawaran, dan berkomitmen pada likuiditas sisi tujuan ketika ia setuju untuk memenuhi perdagangan. Resolver dapat bersaing untuk permintaan, artinya transaksi lintas-chain bisa diperlakukan sebagai pasar likuiditas, bukan rute yang dikendalikan oleh satu bridge saja.
Bayangkan seorang pengguna ingin menukar Ethereum USDT menjadi TON USDT.
Pengguna membuat permintaan yang menentukan aset sumber, aset tujuan, dan jumlahnya.
Omniston mendistribusikan Permintaan untuk Penawaran, yang biasa disebut RFQ, kepada resolver yang berpartisipasi.
Resolver dapat merespons dengan syarat eksekusi yang mereka usulkan.
Resolver yang cocok dipilih, lalu kedua sisi transaksi dihubungkan melalui mekanisme penyelesaian.
Ini penting karena resolver tidak hanya sekadar menjanjikan:
“Saya akan mengirim token tujuan Anda nanti.”
Desain protokol mengharuskan resolver melakukan komitmen pada aset sisi tujuan melalui struktur penyelesaian yang sesuai.
Komitmen itulah yang memberi sistem koneksi kriptografis antara transaksi sumber dan transaksi tujuan.
Memahami HTLC Tanpa Jargon
Fondasi teknis di balik proses ini adalah Hashed Timelock Contract, atau HTLC.
Namanya terdengar rumit, tetapi tujuannya bisa dijelaskan melalui dua gagasan:
Sebuah rahasia
dan
sebuah tenggat.
Pertama, sebuah rahasia kriptografis dibuat.
Hash dari rahasia tersebut digunakan sebagai hashlock. Hash bisa dibagikan secara publik, tetapi rahasia asli tetap tersembunyi sampai tahap eksekusi yang tepat.
Komponen kedua adalah timelock.
Kontrak-kontrak menentukan kondisi waktu di mana transaksi bisa diselesaikan menggunakan rahasia atau di-refund setelah periode yang diperlukan berakhir.
Omniston menghubungkan dua HTLC:
Sebuah bid HTLC di blockchain sumber.
Sebuah ask HTLC di blockchain tujuan.
Dua kontrak menggunakan kondisi kriptografis yang sama.
Ini membentuk hubungan inti antara dua chain tersebut.
Aset sisi sumber pengguna dikunci di bid HTLC.
Aset sisi tujuan milik resolver dikunci di ask HTLC.
Rahasia yang sama menghubungkan keduanya.
Bagaimana Penyelesaian Atomik Bekerja
Pertimbangkan contoh sederhana Ethereum → TON.
Pengguna memiliki USDT di Ethereum dan menginginkan USDT di TON.
Langkah 1: Pesanan dibuat
Pengguna menentukan aset sumber dan aset tujuan serta menerima penawaran.
Sistem membuat kondisi kriptografis yang diperlukan untuk penyelesaian, dan dana sisi sumber pengguna menjadi tunduk pada HTLC sisi penawaran (bid-side).
Langkah 2: Resolver berkomitmen
Sebuah resolver menerima perdagangan dan berkomitmen untuk memenuhi sisi tujuan.
Resolver menyediakan aset sisi TON yang diminta.
Langkah 3: Sisi tujuan dikunci
Aset tujuan milik resolver ditempatkan ke HTLC yang sesuai di TON menggunakan hashlock yang sama.
Pada titik ini, sisi sumber dan sisi tujuan terhubung secara kriptografis.
Langkah 4: Rahasia diungkapkan
Ketika kondisi eksekusi terpenuhi, rahasia menjadi tersedia di-chain.
Pengguna dapat menggunakan rahasia untuk mengklaim aset tujuan dari HTLC yang diminta (ask HTLC).
Resolver dapat menggunakan rahasia yang sama untuk mengklaim aset sisi sumber dari bid HTLC.
Satu peristiwa kriptografis karena itu menghubungkan kedua penyelesaian.
Langkah 5: timelock menyediakan fallback
Apa yang terjadi jika swap tidak selesai?
Di sinilah bagian kedua dari arsitektur HTLC menjadi penting.
Jika rahasia tidak pernah diungkap dalam jendela waktu yang diperlukan, timelock memungkinkan aset yang dikunci menjadi dapat direfund ke pemilik aslinya.
Model Omniston yang didokumentasikan karenanya menjelaskan tiga kemungkinan hasil: penyelesaian sukses ketika rahasia diungkapkan, refund untuk pengguna ketika resolver gagal merespons, atau refund untuk resolver jika rahasia tidak pernah diungkap.
Inilah yang dimaksud protokol dengan penyelesaian all or nothing.
Tujuannya bukan sekadar membuat swap lintas-chain lebih cepat atau lebih sederhana. Logika penyelesaian dirancang agar kedua sisi transaksi tetap terhubung secara kriptografis.
Mengapa “Tanpa Bridge” Tidak Berarti “Tanpa Infrastruktur”
Perlu dijelaskan frasa tanpa bridge tradisional.
Ini tidak berarti blockchain tiba-tiba saling berkomunikasi secara langsung.
Itu tidak berarti tidak ada penyedia likuiditas.
Ini tidak berarti tidak ada smart contract.
Dan itu tidak berarti tidak ada infrastruktur eksekusi lintas chain.
Sebaliknya, ini berarti pengguna tidak bergantung pada pola bridge konvensional: memasukkan aset ke vault bridge bersama lalu menerima representasi wrapped di jaringan lainnya.
Omniston menggantikan model bridge-first itu dengan lapisan eksekusi berbasis resolver menggunakan HTLC yang terhubung. Dokumentasi STON.fi menjelaskan Omniston sebagai lapisan agregasi dan eksekusi yang dapat bekerja dengan sumber likuiditas dan resolver, sementara arsitektur lintas-chain saat ini menggunakan resolver dan penyelesaian berbasis HTLC untuk eksekusi lintas-chain.
Infrastrukturnya masih ada.
Ini semata-mata diorganisasi di sekitar eksekusi pertukaran, bukan pengangkutan melalui vault bersama.
Contoh Praktis dengan STON.fi dan Omniston
Sekarang pertimbangkan bagaimana arsitektur itu terlihat dari sudut pandang pengguna.
Misalkan Anda memiliki USDT di Ethereum dan ingin USDT di TON.
Alih-alih memulai dengan bridge terpisah, alur praktis melalui antarmuka lintas-chain berbasis STON.fi dapat dipahami sebagai:
Ethereum / USDT → Penawaran Omniston → TON / USDT
Persyaratan pertama adalah tujuan yang valid.
Anda memilih Ethereum sebagai jaringan sumber, USDT sebagai aset sumber, TON sebagai jaringan tujuan, dan aset sisi TON yang diinginkan.
Omniston kemudian mendapatkan penawaran melalui jaringan resolvernnya.
Penawaran dari resolver menentukan berapa banyak likuiditas sisi tujuan yang akan disediakan untuk jumlah di sisi sumber berdasarkan kondisi yang dikutip. Dokumentasi pengembang STON.fi juga menjelaskan integrasi Omniston sebagai penggunaan permintaan RFQ, streaming penawaran, konstruksi transaksi, dan pelacakan status perdagangan.
Dari sudut pandang pengguna, ini menyederhanakan apa yang seharusnya bisa menjadi alur kerja multi-tahap menjadi satu hasil yang memang diinginkan:
“Saya ingin aset ini ada di chain itu.”
Namun, di bawahnya, protokol mengoordinasikan berbagai operasi blockchain.
Itu adalah perbedaan penting.
Antarmuka yang sederhana tidak berarti arsitektur yang mendasarinya juga sederhana.
Pengguna melihat sebuah swap.
Protokol ini mengoordinasikan RFQ, likuiditas resolver, penyelesaian sisi sumber, penyelesaian sisi tujuan, kondisi kriptografis, dan pelacakan transaksi.
Mengapa Aset Tujuan Penting
Bayangkan dua rute yang mungkin untuk pengguna Ethereum yang masuk ke TON DeFi.
Route A
Ethereum USDT → Bridge → Wrapped USDT di TON → Swap → TON USDT
Route B
Ethereum USDT → Omniston → TON USDT
Kedua rute memiliki tujuan besar yang sama, tetapi pengalaman perantaranya berbeda.
Route A memperlakukan perpindahan lintas-chain sebagai operasi utama, sementara konversi token menjadi masalah terpisah.
Route B dimulai dari hasil akhir.
Ini sangat relevan ketika pengguna tahu persis aset apa yang dibutuhkan di TON.
Aplikasi tujuan mungkin mengharapkan Jetton TON tertentu, bukan representasi wrapped yang sewenang-wenang. Arsitektur swap first berupaya menyelesaikan kebutuhan itu sebelum dana tiba, alih-alih membiarkan pengguna mengurusnya setelahnya.
Itulah sebabnya STON.fi menggambarkan pendekatan Omniston berpusat pada aset tujuan, bukan hanya memindahkan aset sumber melintasi jaringan.
Peran Likuiditas RFQ
Komponen penting lainnya adalah mekanisme Request for Quote.
Sebuah AMM biasanya mengekspos likuiditas melalui pool.
Sistem berbasis resolver memperkenalkan sumber likuiditas lain: peserta pasar profesional yang dapat merespons permintaan individual dengan harga yang dapat dieksekusi.
Saat permintaan Omniston disiarkan, resolver yang memenuhi syarat dapat mengevaluasi perdagangan dan mengembalikan penawaran. Mereka membawa modal mereka sendiri dan bisa bersaing pada syarat eksekusi yang siap mereka tawarkan.
Ini menciptakan pasar untuk eksekusi lintas-chain.
Alih-alih mengandalkan satu pool permanen yang berisi representasi aset dari banyak chain, likuiditas sisi tujuan dapat disediakan oleh resolver saat pesanan spesifik perlu dipenuhi.
Bagi pengguna, manfaat praktisnya adalah rute lintas-chain dapat dibangun di sekitar penawaran tujuan yang benar-benar nyata.
Untuk infrastrukturnya, manfaatnya adalah likuiditas bisa dikoordinasikan di sekitar transaksi individual.
Apa yang Terjadi saat Swap Lebih Besar?
Pesanan besar tidak harus berperilaku sebagai satu transaksi yang tak terpisahkan.
Arsitektur Omniston yang dijelaskan oleh STON.fi mendukung partial fills dengan memecah pesanan yang lebih besar menjadi sub-swap terpisah. Setiap sub-swap dapat memiliki rahasia kriptografis, hashlock, dan pasangan HTLC-nya sendiri.
Secara konseptual, pesanan 1.000 unit bisa dibagi menjadi beberapa eksekusi yang lebih kecil.
Artinya satu sub-swap bisa terselesaikan sementara yang lain tetap tertunda atau akhirnya mengembalikan dana, tergantung pada kondisi eksekusinya.
Ini adalah perbedaan penting dari menganggap transaksi lintas-chain sebagai satu transfer raksasa.
Pada level protokol, sistem dapat mengoordinasikan beberapa unit penyelesaian.
Bridge Risk vs Resolver Based Settlement
Perbandingan arsitektur ini bukan sekadar soal kecepatan.
Ini juga tentang di mana kepercayaan dan risiko terkonsentrasi.
Sebuah bridge tradisional dapat mengonsentrasikan nilai yang signifikan di dalam kontrak atau infrastruktur yang bertanggung jawab untuk mewakili atau merilis aset di chain lain. Model keamanan karenanya sangat bergantung pada arsitektur bridge tersebut, operator, validator, kontrol multisig, atau mekanisme verifikasi lainnya.
Model resolver/HTLC mengambil pendekatan yang berbeda.
Alih-alih mempertahankan satu vault bersama yang berisi representasi tujuan pengguna, resolver independen menyediakan likuiditas sisi tujuan dan kontrak penyelesaian yang terhubung mengaitkan sisi sumber dan sisi tujuan.
Itu tidak berarti sistem tidak memiliki risiko. Pengguna tetap harus mempertimbangkan risiko smart contract, ketersediaan resolver, kondisi likuiditas, alamat yang salah, kondisi jaringan, dan keamanan aset itu sendiri.
Namun, arsitektur mengubah letak risiko.
Properti keamanan yang dituju diberlakukan oleh kondisi HTLC yang terhubung, bukan dengan mempercayai pihak terpusat untuk merilis sisi transfer lainnya secara manual.
Sebelum Anda Mengeksekusi Swap TON ↔ Ethereum
Bahkan ketika protokol dirancang untuk menyederhanakan eksekusi lintas chain, pengguna tetap tidak boleh menganggap proses itu sebagai “hubungkan wallet dan klik sembarangan.”
Pemeriksaan akhir tetap penting.
1. Periksa jaringan sumber
Pastikan aset tersebut benar-benar ada di jaringan yang Anda pilih.
USDT di Ethereum bukanlah objek on-chain yang sama dengan USDT di TON, meskipun keduanya memiliki ticker yang sama dan referensi moneter yang lebih luas.
Selalu verifikasi jaringan sebelum menandatangani.
2. Periksa jaringan tujuan
Konfirmasikan bahwa TON memang benar-benar menjadi tujuan jika di sanalah Anda berniat menerima dana.
Demikian pula, saat bergerak ke arah sebaliknya, verifikasi jaringan EVM yang spesifik.
Transaksi lintas-chain bersifat spesifik jaringan.
3. Periksa aset tujuan
Jangan fokus hanya pada jumlah.
Perhatikan baik-baik aset yang Anda terima.
Inti dari pendekatan swap-first adalah bahwa aset tujuan menjadi bagian dari hasil yang diminta.
4. Periksa alamat dompet
Alamat TON dan alamat EVM menggunakan format yang berbeda.
Alamat EVM umumnya diawali dengan 0x, sedangkan alamat TON memiliki struktur yang berbeda.
Alamat yang valid di satu jaringan tidak otomatis menjadi alamat tujuan yang valid di jaringan lainnya. STON.fi secara khusus merekomendasikan verifikasi chain tujuan, alamat token, dan kompatibilitas wallet sebelum eksekusi.
5. Tinjau penawaran
Jangan menganggap penawaran sebagai informasi dekoratif.
Periksa:
jumlah dikirim → jumlah diterima → jaringan → aset tujuan → biaya yang berlaku → kondisi yang dikutip
Sebuah penawaran seharusnya membuat hasil akhir dapat dipahami sebelum Anda menyetujui transaksi.
6. Periksa ketersediaan resolver
Seorang resolver harus tersedia untuk memenuhi permintaan.
Jika tidak ada resolver yang cocok merespons, pesanan mungkin tidak akan dimulai.
Ini tidak selalu berarti transaksi gagal. Bisa jadi hanya berarti tidak ada cukup likuiditas dari resolver untuk pasangan dan jumlah tertentu pada saat itu. Penjelasan STON.fi menyebutkan bahwa ketika tidak ada resolver yang merespons, tidak perlu ada HTLC yang dikunci dan pengguna tetap memegang dana aslinya.
7. Pastikan memiliki cukup gas jaringan
Eksekusi lintas chain tidak menghapus biaya transaksi blockchain.
Wallet sisi sumber tetap membutuhkan saldo asli jaringan yang cukup untuk mengeksekusi transaksi yang diperlukan.
Panduan STON.fi yang saat ini menekankan pentingnya menjaga TON yang cukup untuk transaksi yang melibatkan wallet TON.
8. Jangan mengirim ulang secara membabi buta
Transaksi yang terlihat tertunda sebaiknya terlebih dahulu diselidiki.
Periksa penjelajah blockchain (blockchain explorer) yang relevan serta status transaksi atau perdagangan sebelum membuat permintaan lain.
Mengirim pesanan yang sama berulang kali tanpa memahami transaksi pertama dapat membuat proses troubleshooting lebih rumit.
Dari Sudut Pandang Pengguna, Alurnya Terlihat Mudah
Pengalaman lengkap dapat diringkas menjadi beberapa tahap yang terlihat:
Pilih aset sumber.
Pilih jaringan tujuan.
Pilih aset tujuan.
Minta penawaran.
Tinjau jumlah, biaya, dan tujuan.
Setujui transaksi sumber.
Lacak eksekusi.
Di balik tindakan-tindakan itu, Omniston mengoordinasikan proses yang jauh lebih canggih yang melibatkan resolver, RFQ, HTLC, dan penyelesaian blockchain.
Perangkat pengembang STON.fi mengekspos pengambilan penawaran, konstruksi transaksi, dan pelacakan perdagangan ke aplikasi yang mengintegrasikan Omniston. Ini menunjukkan bahwa infrastruktur yang sama bisa berada di bawah wallet, aplikasi DeFi, dan antarmuka lain, bukan hanya menjadi pengalaman pengguna mandiri.
Gagasan Besar: Lintas-Chain sebagai sebuah Hasil
Makna yang lebih dalam dari eksekusi lintas-chain berbasis resolver bukan sekadar karena menghilangkan satu tombol dari antarmuka pengguna.
Ini mengubah cara transaksi lintas-chain dapat dirancang.
Model pikiran tradisionalnya adalah:
Pindahkan aset → tunggu sampai tiba → konversi → gunakan.
Model yang lebih baru adalah:
Tentukan aset yang Anda inginkan → dapatkan penawaran → selesaikan pertukaran lintas-chain.
Perbedaan itu terdengar kecil, tetapi secara arsitektur itu signifikan.
Model bridge-first terutama berfokus pada pemindahan nilai.
Model swap-first terutama berfokus pada penyampaian hasil yang diinginkan.
Omniston melangkah lebih jauh dengan menggabungkan likuiditas resolver berbasis RFQ dengan penyelesaian HTLC yang terhubung. Resolver menyediakan likuiditas sisi tujuan, sementara kondisi kriptografis bersama menghubungkan kaki sisi sumber dan sisi tujuan. Jika kondisi yang diperlukan terpenuhi, kedua sisi bisa menyelesaikan; jika tidak, mekanisme timelock menyediakan jalur refund yang dijelaskan protokol.
Pemikiran Akhir
Memindahkan token antara TON dan Ethereum tidak selalu mengharuskan pengguna memulai dengan bridge tradisional.
Perbedaan pentingnya adalah antara arsitektur outcome-first dan transport-first untuk lintas-chain.
Pendekatan bridge-first umumnya berfokus untuk memindahkan nilai dari satu blockchain ke blockchain lain, yang bisa saja membuat pengguna mendapatkan representasi tujuan yang dibungkus (wrapped) atau dicerminkan (mirrored), dan representasi itu mungkin memerlukan konversi lain.
Pendekatan swap-first dimulai dari aset tujuan yang diinginkan.
Itulah model yang ditunjukkan oleh Omniston.
Melalui jaringan resolver, pengguna dapat meminta penawaran yang berfokus pada tujuan sementara penyedia likuiditas independen menyediakan aset yang dibutuhkan di sisi lainnya. HTLC yang terhubung lalu menghubungkan transaksi sumber dan tujuan melalui kondisi kriptografis bersama serta timelock.
Untuk rute TON ↔ Ethereum yang praktis melalui STON.fi, prinsip pentingnya jadi sederhana:
Anda tidak hanya sekadar memindahkan token melewati batas blockchain. Anda meminta aset di chain tujuan dan membiarkan infrastruktur mengoordinasikan pertukaran yang membawa Anda sampai ke sana.
Itulah yang membuat eksekusi lintas-chain berbasis resolver berbeda dari workflow bridge-first tradisional.
Dan sebelum setiap swap, disiplin praktisnya tetap sama: verifikasi wallet, jaringan, aset tujuan, penawaran, biaya, dan status transaksi.
Antarmuka bisa membuat perpindahan lintas-chain terlihat seperti satu swap, tetapi memahami apa yang terjadi di bawahnya adalah yang memungkinkan pengguna memakai kesederhanaan tersebut secara cerdas.
Baca lebih lanjut tentang STONfi di sini: https://blog.ston.fi/omniston-explained-how-cross-chain-swaps-on-ton-work-without-a-bridge/