Mengapa Agregasi Lintas-DEX Bisa Membuat Rute yang Tidak Akan Anda Susun Secara Manual
Agregator seperti Omniston kadang merutekan sebuah swap melalui jalur yang tidak akan pernah dipikirkan oleh trader manusia untuk dibangun secara manual — dan memahami alasannya mengungkap sesuatu yang benar-benar menarik tentang bagaimana likuiditas yang terfragmentasi sebenarnya berperilaku.
Jika Anda bertanya kepada kebanyakan orang tentang bagaimana sebuah swap berpindah dari Token A ke Token B, mereka akan menjelaskan sesuatu yang intuitif: temukan pool yang berisi A dan B, lakukan perdagangan langsung, selesai. Model pemikiran itu bekerja dengan baik untuk pasangan besar dengan likuiditas yang dalam. Namun, semuanya berantakan begitu Anda berurusan dengan token yang lebih jarang, ukuran transaksi yang besar, atau ketika likuiditas di seluruh ekosistem ternyata tidak terdistribusi secara merata — dan tepat di situlah agregasi berubah dari “sekadar tambahan yang bagus” menjadi menghasilkan rute yang, sekilas, terlihat hampir tidak rasional. STON.fi, melalui lapisan agregasinya yang bernama Omniston, adalah tempat yang benar-benar baik untuk menyaksikan hal ini terjadi, karena ia tidak hanya merutekan melalui pool miliknya sendiri — ia menarik likuiditas dan kutipan (quotes) dari berbagai pihak yang bersaing di seluruh ekosistem TON yang lebih luas.
Saya ingin benar-benar menggali kenapa hal itu bisa terjadi, karena "agregator menemukan rute yang lebih baik" adalah jenis penjelasan yang terdengar memuaskan tanpa benar-benar menjelaskan apa pun. Jawaban sebenarnya melibatkan beberapa ide yang benar-benar elegan tentang bagaimana likuiditas yang terfragmentasi berperilaku, kenapa memecah trade bisa mengalahkan jalur mana pun, dan kenapa rute yang terlihat tidak perlu rumit di atas kertas tetap bisa menjadi jawaban yang benar secara matematis.
Pertama kali saya melihat rute melalui tiga hop, bukan pool langsung yang jelas, reaksi naluriah saya adalah "itu terlihat tidak efisien." Lalu saya cek angka output-nya, dan ternyata tidak tidak efisien sama sekali. Intuisi saya saja yang keliru.
🧩 Mengapa Likuiditas Terfragmentasi Justru Terjadi dari Awal
Sebelum membahas bagaimana agregasi memecahkan masalah tersebut, penting untuk memperjelas dulu apa sebenarnya masalahnya, karena "fragmentasi likuiditas" sering dilempar sebagai buzzword tanpa banyak penjelasan tentang mekanisme di baliknya.
Di ekosistem DeFi mana pun yang aktif, likuiditas untuk pasangan token tertentu tidak berada di satu tempat tunggal yang terintegrasi. Likuiditas tersebar di banyak pool — DEX yang berbeda, tier fee yang berbeda, desain pool yang berbeda — masing-masing memegang cadangan (reserves) terpisah dan menetapkan harga transaksi secara independen berdasarkan pasokan dan permintaan lokalnya sendiri. Sebuah token bisa punya likuiditas yang dalam terhadap USDT di satu DEX dan hampir tidak ada di DEX lain, sementara token yang sama sekali berbeda memiliki pola kebalikannya. Tidak ada yang mengoordinasikan pool-pool ini satu sama lain; masing-masing pool hanya mencerminkan modal yang memang disetor ke pool tersebut secara spesifik.
Fragmentasi ini bukan bug atau kegagalan ekosistem — ini adalah hasil yang wajar dan diharapkan dari sistem terbuka tanpa izin, di mana siapa pun dapat membuat pool untuk pasangan apa pun kapan saja. Tapi ini berarti "harga terbaik untuk perdagangan ini" jarang sekali berada di satu tempat yang jelas, dan menemukannya secara manual berarti harus memeriksa setiap pool satu per satu, tugas yang skalanya memburuk begitu Anda berhadapan dengan apa pun di luar dua atau tiga venue yang paling jelas.
Likuiditas untuk pasangan yang sama bisa berbeda sangat besar antar-pool, bahkan di dalam ekosistem yang sama
Tidak ada satu pun pool yang memiliki visibilitas tentang apa yang ditawarkan pool lain saat ini
Trader yang mengecek pool secara manual secara realistis hanya bisa memeriksa beberapa saja sebelum menyerah lalu memilih salah satu
Inilah lanskap di mana pool milik STON.fi berada. Bahkan jika dibatasi hanya pada likuiditas milik STON.fi sendiri, puluhan pool dengan kedalaman yang sangat berbeda hidup berdampingan — dan itulah tepatnya mengapa STON.fi merutekan permintaan swap melalui Omniston, bukan mengasumsikan bahwa "pool yang jelas" untuk suatu pasangan otomatis adalah yang terbaik.
🔀 Kenapa Memecah Trade Mengalahkan Jalur Mana Pun
Ini ide pertama yang benar-benar kontra-intuitif untuk direnungkan: untuk trade yang cukup besar, memecahnya ke beberapa pool dapat menghasilkan output total yang lebih baik daripada merutekan seluruh jumlah melalui bahkan satu pool terbaik berdasarkan harga yang tersedia. Inilah mekanisme yang paling bertanggung jawab atas rute yang tampak aneh bagi trader manual.
Penyebabnya ada pada cara kerja penetapan harga AMM. Setiap pool mengalami dampak harga sebagai fungsi dari ukuran trade dibanding kedalamannya sendiri — semakin besar trade Anda relatif terhadap cadangan pool, semakin buruk harga efektif yang Anda dapat saat Anda mengonsumsi lebih banyak likuiditas yang tersedia pada kurva spesifik itu. Pool yang memberi harga bagus untuk trade $100 mungkin memberi harga yang jauh lebih buruk untuk trade $10.000, semata-mata karena Anda kini bergerak lebih jauh di sepanjang kurva penetapan harganya.
Agregator menyelesaikan ini dengan memperlakukan "rute" sebagai masalah portofolio, bukan masalah satu jalur. Alih-alih bertanya "pool tunggal mana yang punya harga terbaik," ia bertanya "kombinasi trade parsial di beberapa pool mana yang meminimalkan total dampak harga untuk ukuran tertentu." Matematikanya benar-benar elegan: saat Anda mendorong volume lebih besar ke salah satu pool, harga marginal menjadi semakin buruk. Jadi pada titik tertentu, secara matematis lebih baik mengalihkan sebagian berikutnya dari trade Anda ke pool kedua yang sedikit lebih buruk harganya, daripada terus mengunyah lebih dalam ke kurva pool pertama.
Awalnya saya merasa splitting sebagai kompleksitas yang tidak perlu — lebih banyak transaksi, lebih banyak komponen bergerak; kenapa tidak saja pilih pool terbaik dan selesai? Lalu saya benar-benar memodelkan trade besar terhadap satu pool yang dalam dibanding memecahnya menjadi tiga, dan versi split ternyata unggul dengan selisih yang terlalu besar untuk dianggap sekadar kesalahan pembulatan.
Seorang manusia yang mencoba menirukan ini perlu mengetahui kurva kedalaman yang tepat dari setiap pool relevan secara bersamaan dan menyelesaikan masalah optimasi di kepala — yang tidak dilakukan siapa pun, karena tidak bisa. Itulah tepatnya jenis perhitungan yang routing STON.fi hadirkan untuk diotomatisasi demi keuntungan trader.
🌉 Mengapa Rute Multi-Hop Kadang Mengalahkan Pasangan Langsung
Pola kedua yang kontra-intuitif: rute yang melewati Token A → Token C → Token B kadang bisa memberi hasil lebih baik daripada pool langsung A → B, bahkan ketika pool langsung itu ada dan tampak berfungsi sempurna di permukaan.
Ini terjadi karena kedalaman likuiditas tidak terbagi rata di setiap pasangan yang mungkin. Pool langsung A/B bisa saja tipis — mungkin pool yang lebih baru, atau sekadar kurang populer — sementara pool A/C dan C/B sama-sama dalam dan sangat sering diperdagangkan, sering kali karena C adalah aset utama seperti stablecoin atau TON itu sendiri yang secara alami mengumpulkan likuiditas di banyak pasangan. Merutekan melalui aset perantara yang sangat likuid itu bisa menghasilkan dampak harga kumulatif yang lebih kecil daripada memaksa seluruh trade lewat satu pool langsung yang tipis, meski jalur multi-hop melibatkan lebih banyak langkah individual.
Pool langsung yang tipis bisa memiliki dampak harga yang sangat besar untuk ukuran trade yang mungkin hampir tidak terasa pada pool perantara yang dalam
Aset unggulan yang dipasangkan secara luas (stablecoin, native token) cenderung mengumpulkan likuiditas terdalam di sebagian besar pasangan, sehingga menjadikannya hub routing yang natural
Dua hop lewat pool yang dalam sering kali mengalahkan satu hop lewat pool yang dangkal, bahkan dengan memperhitungkan fee tambahan yang diambil pada tiap hop
Ini benar-benar tidak intuitif kalau Anda berpikir seperti trader manusia yang melihat peta pool yang tersedia lalu secara naluriah lebih memilih jalur terpendek. Logika routing STON.fi tidak punya insting seperti itu — ia memiliki data kedalaman yang nyata untuk setiap pool relevan dan menghitung dampak harga kumulatif di setiap jalur yang mungkin, alih-alih default ke "jumlah hop paling sedikit" sebagai proksi untuk "hasil terbaik."
⚔️ Kenapa Sumber yang Bersaing Mengubah Perhitungan Secara Total
Lapisan Omniston milik STON.fi menambah lapisan lagi di atas logika routing murni berbasis pool: alih-alih hanya menghitung rute di seluruh pool milik STON.fi sendiri, ia menyebarkan permintaan ke kumpulan resolver dan sumber likuiditas yang lebih luas, yang bersaing langsung dengan penawaran yang bisa dieksekusi. Ini mengubah pemilihan rute dari "menyelesaikan masalah optimasi berdasarkan data pool statis yang diketahui" menjadi "menyelesaikan masalah optimasi berdasarkan data pool ditambah penawaran bid yang sedang berjalan dan kompetitif dari peserta pasar independen."
Perbedaan ini penting karena resolver tidak terbatas hanya mengutip apa pun yang dikatakan kurva pool publik saat ini. Sebuah resolver mungkin memiliki akses ke persediaan (inventory), jalur lintas-protokol, atau hubungan penetapan harga yang tidak sepenuhnya tergambar dalam kedalaman yang terlihat pada satu pool mana pun — artinya, penawaran terbaik kadang datang dari sumber yang logika internalnya bahkan tidak sepenuhnya terlihat dari luar, hanya kutipan kompetitif akhirnya. Akibatnya, rute yang dihasilkan dapat merefleksikan informasi yang sama sekali tidak bisa diakses oleh algoritma routing berbasis pool semata, apalagi oleh manusia yang membandingkan beberapa antarmuka DEX secara manual.
Ini bagian yang benar-benar mengejutkan saya: bukan hanya algoritmanya lebih baik dalam matematika daripada manusia. Kadang algoritma itu punya akses ke informasi penetapan harga yang sama sekali tidak terlihat di mana pun yang bisa dicari langsung oleh manusia.
📊 Ilustrasi Konkret untuk Routing yang Tidak Jelas
Mari kita lihat contoh yang disederhanakan dan ilustratif supaya lebih konkret, bukan sekadar abstrak. Misalkan Anda ingin menukar jumlah bermakna Token X menjadi USDT di STON.fi, dan ini kira-kira seperti apa lanskap likuiditas yang terfragmentasi itu:
Pool X/USDT langsung: kedalaman sedang, harga cukup baik untuk trade kecil, tapi dampak harga terlihat setelah ukuran trade membesar
Pool X/TON: cukup dalam, diperdagangkan besar-besaran, dampak harga minimal bahkan untuk trade yang lebih besar
Pool TON/USDT: sangat dalam, bisa dibilang pasangan likuiditas terterbaik di seluruh ekosistem, dampak harga nyaris tidak ada
Seorang trader manual yang melihat pool X/USDT langsung ada biasanya akan memakainya — kenapa dibuat rumit kalau rute langsung sudah ada di sana. Tapi agregator yang mengevaluasi data kedalaman yang nyata mungkin memutuskan untuk merutekan X → TON → USDT, meski membutuhkan dua hop dan dua kali pembayaran fee, karena menghasilkan dampak harga kumulatif yang jauh lebih kecil dibanding memaksa seluruh trade lewat pool langsung yang lebih dangkal. Untuk trade yang cukup besar, biaya fee dari hop tambahan bisa lebih kecil daripada dampak harga yang dihemat karena menghindari kedalaman dangkal pool langsung — dan agregator juga bisa memecah trade lagi: sebagian langsung dan sebagian melalui TON, lalu menggabungkan kedua jalur itu untuk mendapatkan rata-rata tertimbang yang lebih baik.
Tidak ada hal ini yang bisa dibuat secara manual oleh trader yang hanya mengecek dua antarmuka dan melihat-lihat harga — bukan karena mereka tidak pandai matematika, tetapi karena melakukannya dengan benar membutuhkan data kedalaman yang sedang berjalan untuk setiap pool relevan secara bersamaan, ditambah perhitungan optimasi yang benar-benar nyata — persis jenis pekerjaan yang komputer dibuat untuk, sementara manusia secara struktur tidak.
⚠️ Di Mana Kompleksitas Ini Memiliki Trade-Off
Akan tidak jujur jika menyajikan routing multi-hop dan split sebagai peningkatan yang benar-benar gratis tanpa biaya dibanding swap langsung sederhana, karena memang ada trade-off nyata yang layak dipahami, bukan diabaikan begitu saja.
Setiap hop tambahan dalam sebuah rute berarti fee tambahan yang dikenakan di sepanjang segmen itu, dan titik tambahan di mana slippage secara teori bisa terjadi antara kuotasi dan eksekusi. Rute yang benar-benar dioptimasi memperhitungkan ini — agregator tidak memilih lebih banyak hop demi tujuan itu sendiri, ia memilihnya karena hasil bersihnya, setelah semua fee dan dampak difaktorkan, tetap keluar lebih baik. Tapi ini juga berarti rute dengan langkah lebih banyak tidak otomatis lebih mudah dipahami atau diverifikasi secara manual, dan kompleksitas tambahan itulah alasan mengapa mengecek output kuotasi akhir, bukan sekadar mengagumi kecerdikan jalurnya, tetap menjadi metrik yang benar-benar penting.
Semakin banyak hop berarti semakin banyak biaya fee individual yang dikenakan di sepanjang rute
Setiap hop tambahan adalah titik lain di mana eksekusi secara teori bisa menyimpang dari kuotasi
Satu-satunya angka yang benar-benar penting pada akhirnya adalah total output yang diterima setelah semua biaya, bukan keindahan jalurnya sendiri
Saya akui kompleksitasnya membuat kita ingin benar-benar memverifikasi output, bukan sekadar percaya "algoritmanya pasti tahu yang terbaik." Biasanya memang begitu. Tapi "biasanya" adalah kata yang tepat yang membuat pengecekan tetap penting.
🧭 Apa Artinya untuk Cara Anda Harus Trading
Tidak ada yang mengharuskan Anda memahami algoritma routing secara pribadi untuk mendapat manfaat darinya — justru itulah inti keberadaan agregasi sejak awal. Namun memahami mengapa sebuah rute terlihat seperti itu mengubah cara Anda mengevaluasi kuotasi, dan menggeser hal yang sebenarnya layak dicek dua kali sebelum Anda menyetujuinya.
Jangan menilai suatu rute hanya dari jumlah hop — rute tiga hop yang mengalahkan rute satu hop bukanlah bug, melainkan sering kali jawaban yang benar secara matematis untuk ukuran perdagangan tertentu dan lanskap likuiditas pada trade tersebut
Fokus pada output akhir yang benar-benar diterima dibandingkan biaya, bukan pada kesederhanaan visual dari jalur yang ditempuh
Untuk trade yang benar-benar besar, harapkan pemecahan (splitting) dan routing multi-hop akan menjadi lebih berpengaruh, karena dampak harga pada setiap pool tertentu meningkat secara tidak proporsional dengan ukuran trade
Lebih percaya pada proses kompetitif daripada harga yang terlihat dari satu pool yang dipublikasikan, karena harga terbaik sebenarnya mungkin datang dari sumber yang tidak pernah Anda cek secara manual
Pelajaran yang lebih luas dari semuanya ini adalah bahwa likuiditas terfragmentasi sebenarnya bukan masalah yang benar-benar selesai begitu jumlah pool cukup banyak — ini adalah masalah optimasi yang berkelanjutan dan sangat diuntungkan oleh routing yang terotomasi serta terus diperbarui, bukan perbandingan statis yang dicek manual. Seorang manusia yang membandingkan dua atau tiga antarmuka DEX hanya melakukan perkiraan kasar dari apa yang agregator lakukan secara matematis dan terus-menerus, dengan jauh lebih banyak sumber daripada yang siapa pun bisa cek sendiri secara realistis.
🧩 Pikiran Akhir
Rute yang terlihat aneh pada pandangan pertama — jalur multi-hop, trade yang dipecah ke beberapa pool, jalur yang sepenuhnya melewati pool langsung yang jelas — biasanya tidak aneh sama sekali begitu Anda memahami masalah apa yang sebenarnya sedang diselesaikannya. Di STON.fi khususnya, itulah seluruh pekerjaan yang dilakukan Omniston di balik antarmuka: menemukan jawaban yang benar secara matematis untuk pertanyaan optimasi yang memang kompleks, yang timbul dari likuiditas terfragmentasi sejak sifat dasarnya, dan yang tidak bisa diselesaikan sebaik itu oleh trader manual yang hanya mengecek segelintir antarmuka, karena skala perhitungan melebihi apa yang praktis dilakukan dengan tangan. Kompleksitas bukan sekadar hiasan. Itu pekerjaan nyata untuk mencari harga terbaik di lanskap yang memang tidak akan menaruh harga terbaiknya di satu tempat yang jelas dan nyaman sejak awal.
❓ Pertanyaan yang Sering Diajukan
Kenapa sebuah agregator merutekan swap saya melalui lebih banyak hop daripada langsung ke satu pool? Karena kedalaman likuiditas sangat berbeda antar-pool. Rute multi-hop lewat pool perantara yang lebih dalam dapat menghasilkan dampak harga kumulatif yang lebih kecil daripada memaksa perdagangan melewati pool langsung yang lebih dangkal, meskipun sudah memperhitungkan biaya tambahan pada setiap hop.
Apakah rute dengan langkah lebih banyak otomatis lebih buruk? Tidak. Jumlah hop bukan metrik yang relevan — metrik yang relevan adalah total output yang benar-benar diterima setelah semua fee dan dampak harga. Rute dengan lebih banyak langkah masih bisa mengungguli yang lebih sederhana jika ia menghindari dampak harga yang signifikan pada pool yang tipis.
Kenapa memecah suatu trade ke beberapa pool kadang menghasilkan hasil yang lebih baik? Karena dampak harga di dalam satu pool meningkat secara tidak proporsional terhadap ukuran trade. Memecah trade besar ke beberapa pool bisa menjaga setiap bagiannya tetap berada pada rentang di mana dampak harga lebih rendah, sehingga menghasilkan rata-rata tertimbang yang lebih baik dibandingkan merutekan semuanya melalui satu pool.
Haruskah saya memeriksa harga secara manual di beberapa DEX sebelum trading? Untuk trade kecil pada pasangan besar, perbandingan manual sering kali cukup. Untuk trade yang lebih besar atau token yang kurang umum, agregator seperti Omniston bisa mengakses jauh lebih banyak kombinasi routing dan kuotasi kompetitif dibandingkan yang realistis untuk dilakukan hanya dengan cek manual.
$SOL
