“Pajak Tak Terlihat” di Solana

Bertahun-tahun lalu, artikel “Payment for Order Flow on Solana” mengungkap sisi gelap pasar biaya Solana dan memicu diskusi luas di komunitas crypto Twitter berbahasa Inggris.

Payment for Order Flow (PFOF) merupakan model yang telah mapan dalam keuangan tradisional. Robinhood dikenal sebagai pelopor “zero-commission trading” dengan mengadopsi PFOF, sehingga mampu melampaui broker-broker lama. Strategi ini tidak hanya menghasilkan keuntungan besar bagi Robinhood, tetapi juga memaksa pemain utama seperti Charles Schwab dan E-Trade untuk meniru pendekatan serupa, yang pada akhirnya mengubah secara mendasar lanskap broker ritel di Amerika Serikat.

Pada tahun 2021 saja, Robinhood meraih hampir USD 1 miliar dari pendapatan PFOF, yang menyumbang sekitar setengah dari pendapatan tahunan mereka. Bahkan hingga 2025, pendapatan PFOF Robinhood per kuartal masih mencapai ratusan juta dolar, menegaskan betapa menguntungkannya model bisnis ini.

Market maker di keuangan tradisional sangat mengutamakan order ritel. Hal ini karena order ritel dianggap “non-toxic”—umumnya didorong oleh emosi atau kebutuhan sesaat dan tidak mewakili prediksi harga masa depan yang akurat. Dengan menyerap order seperti ini, market maker dapat secara konsisten memperoleh spread bid-ask tanpa harus menghadapi risiko melawan institusi yang berinformasi.

Untuk memaksimalkan peluang ini, broker seperti Robinhood mengemas arus order ritel dan menjualnya secara grosir kepada market maker besar seperti Citadel, serta memperoleh rebate yang signifikan.

Regulasi di keuangan tradisional memberikan perlindungan bagi investor ritel. Regulation NMS dari SEC mengharuskan order yang dibundel tetap dieksekusi pada harga terbaik yang berlaku di pasar.

Namun, lingkungan on-chain yang tidak diatur memungkinkan aplikasi memanfaatkan asimetri informasi. Mereka mendorong pengguna membayar priority fee dan tip jauh di atas kebutuhan jaringan, lalu mengambil selisihnya secara diam-diam. Praktik ini pada dasarnya merupakan “pajak tak kasat mata” yang mahal bagi pengguna tanpa mereka sadari.

Monetisasi Aliran Pengguna

Bagi aplikasi yang mengendalikan titik akses pengguna, strategi monetisasi jauh lebih kompleks daripada yang banyak orang kira.

Aplikasi front-end dan wallet menentukan ke mana transaksi pengguna dikirim, bagaimana transaksi diproses, dan seberapa cepat transaksi masuk ke blockchain. Setiap tahapan dalam siklus transaksi menjadi peluang untuk mengambil nilai dari pengguna.

Menjual Akses Pengguna kepada Market Maker

Seperti Robinhood, aplikasi Solana juga dapat menjual “hak akses” kepada market maker.

Model Request for Quote (RFQ) merupakan contoh nyata. Berbeda dengan AMM tradisional, RFQ memungkinkan pengguna atau aplikasi meminta penawaran harga dan bertransaksi langsung dengan market maker tertentu. Di Solana, aggregator seperti Jupiter telah mengimplementasikan model ini (JupiterZ). Pada skema ini, aplikasi dapat mengenakan biaya koneksi kepada market maker atau secara langsung membundel dan menjual arus order ritel. Seiring spread on-chain makin tipis, model “user brokerage” ini akan semakin lazim.

Selain itu, kolaborasi antara DEX dan aggregator juga mulai berkembang. AMM dan DEX milik sendiri sangat bergantung pada trafik dari aggregator, sementara aggregator dapat membebankan biaya kepada liquidity provider dan membagikan sebagian keuntungan ke aplikasi front-end.

Contohnya, ketika wallet Phantom mengarahkan order pengguna ke Jupiter, liquidity provider seperti HumidiFi atau Meteora dapat membayar Jupiter untuk hak mengeksekusi order tersebut. Jupiter, setelah memungut “channel fee”, kemudian membagikan sebagian kepada Phantom.

Walaupun praktik ini belum dikonfirmasi secara terbuka, penulis yakin bahwa dengan adanya insentif finansial, mekanisme bagi hasil semacam ini hampir pasti terjadi di industri ini.

Predatory Market Orders

Saat pengguna menekan “Konfirmasi” dan menandatangani transaksi di wallet, pada dasarnya mereka membuat market order dengan parameter slippage.

Aplikasi memiliki dua opsi utama untuk menangani order ini:

Konstruktif: Menjual peluang “backrun” (arbitrase susulan) kepada perusahaan trading profesional dan membagi keuntungan. Backrun terjadi ketika order beli pengguna di DEX1 menaikkan harga token, lalu bot arbitrase segera membeli di DEX2 pada blok yang sama (tanpa mempengaruhi harga eksekusi pengguna di DEX1), lalu menjual kembali di DEX1.

Eksploitatif: Berkolaborasi dengan sandwich attacker untuk mengeksploitasi pengguna mereka sendiri, sehingga harga eksekusi meningkat secara artifisial.

Bahkan jika memilih jalur konstruktif, aplikasi belum tentu bertindak demi kepentingan pengguna. Demi memaksimalkan nilai backrun, aplikasi bisa saja sengaja menunda pengiriman transaksi. Demi keuntungan, mereka juga bisa mengarahkan pengguna ke pool likuiditas rendah, menciptakan volatilitas harga lebih besar dan peluang arbitrase tambahan.

Laporan menunjukkan beberapa aplikasi front-end Solana terkemuka melakukan praktik seperti ini.

Siapa yang Mengambil Tip Anda?

Jika strategi sebelumnya bersifat teknis, manipulasi “transaction fee” sering kali dilakukan secara terang-terangan.

Di Solana, biaya pengguna terdiri dari dua bagian:

• Priority Fee: Biaya protokol yang dibayarkan langsung ke validator.
• Transaction Tip: Pembayaran dalam SOL ke alamat tertentu, biasanya ke “landing service provider” seperti Jito. Penyedia ini kemudian menentukan berapa bagian yang diberikan ke validator dan berapa yang direbat ke aplikasi.

Mengapa menggunakan landing service provider? Saat jaringan padat, transaksi standar berisiko gagal. Landing service provider berfungsi sebagai “saluran VIP,” mengoptimalkan rute dan memastikan transaksi pengguna berhasil masuk ke jaringan.

Pola builder market yang kompleks dan sistem routing yang terfragmentasi di Solana mendorong peran ini, sehingga aplikasi mendapatkan peluang rent-seeking. Aplikasi sering kali meminta pengguna membayar tip tinggi demi “jaminan inclusion,” lalu membagi premi tersebut dengan landing service provider.

Alur Transaksi dan Lanskap Biaya

Berdasarkan data, antara 1–8 Desember 2025, Solana memproses 450 juta transaksi di seluruh jaringan.

Layanan landing Jito menangani 80 juta transaksi di antaranya, menguasai 93,5% pangsa pasar builder. Sebagian besar transaksi ini melibatkan swap, update oracle, dan market making.

Dalam volume tinggi ini, pengguna kerap membayar biaya tinggi demi percepatan inclusion. Namun, apakah biaya tersebut benar-benar diperlukan?

Tidak selalu. Data menunjukkan wallet beraktivitas rendah—utamanya pengguna ritel—membayar priority fee jauh lebih tinggi secara proporsional. Karena blok tidak penuh saat itu, jelas mereka kelebihan bayar.

Aplikasi memanfaatkan kekhawatiran pengguna akan kegagalan transaksi, mendorong mereka menetapkan tip berlebihan. Melalui kesepakatan dengan landing service provider, aplikasi mengambil premi tersebut.

Axiom: Contoh Negatif

Untuk menggambarkan model “ekstraksi” ini, penulis melakukan studi kasus pada Axiom, salah satu aplikasi utama di Solana.

Axiom menghasilkan biaya transaksi tertinggi di jaringan, bukan sekadar karena basis penggunanya besar, melainkan juga karena praktik biaya yang agresif.

Data menunjukkan pengguna Axiom membayar median (p50) priority fee sebesar 1.005.000 lamport. Sebagai perbandingan, wallet high-frequency trading hanya membayar 5.000–6.000 lamport—selisih 200 kali lipat.

Hal yang sama berlaku pada tip.

Pengguna Axiom membayar tip pada landing service seperti Nozomi dan Zero Slot jauh di atas rata-rata pasar. Aplikasi memanfaatkan sensitivitas pengguna terhadap kecepatan, sehingga mereka membayar dua kali tanpa ada keluhan.

Penulis menegaskan, “Sebagian besar biaya transaksi yang dibayar pengguna Axiom pada akhirnya masuk ke kantong tim Axiom.”

Mengembalikan Kekuatan Penetapan Biaya

Ketimpangan insentif antara pengguna dan aplikasi menjadi akar masalah utama. Pengguna tidak tahu berapa biaya yang wajar, dan aplikasi memiliki insentif untuk membiarkan mereka tetap tidak tahu.

Untuk mengatasinya, struktur pasar perlu direformasi. Penerapan Multiple Concurrent Proposers (MCP), Priority Ordering, dan mekanisme dynamic base fee di Solana—yang diperkirakan hadir sekitar 2026—diharapkan menjadi solusi.

Multiple Concurrent Proposers (MCP)

Model single-proposer Solana saat ini rentan terhadap monopoli sementara, di mana aplikasi dapat menguasai jaringan dengan memengaruhi leader. MCP memperkenalkan beberapa proposer yang berjalan paralel di tiap slot, sehingga biaya serangan dan monopoli meningkat signifikan, resistensi terhadap sensor lebih kuat, dan aplikasi sulit memojokkan pengguna dengan menguasai satu node.

Priority Ordering

Dengan pengurutan transaksi berdasarkan priority fee di tingkat protokol, elemen acak (jitter) dalam urutan transaksi dihilangkan. Hal ini mengurangi ketergantungan pengguna pada saluran akselerasi privat seperti Jito untuk inclusion. Untuk transaksi standar, pengguna cukup membayar sesuai protokol agar validator memprioritaskan transaksi mereka secara deterministik tanpa menebak tip.

Dynamic Base Fee

Inilah reformasi paling penting. Solana tengah mengembangkan model dynamic base fee yang mirip dengan Ethereum.

Pengguna tidak lagi memberi tip sembarangan; mereka akan menginstruksikan protokol, “Saya bersedia membayar hingga X lamport agar transaksi ini masuk.”

Protokol akan menentukan biaya secara otomatis sesuai tingkat kepadatan jaringan secara real-time. Jika jaringan tidak padat, biaya rendah; jika padat, biaya naik. Mekanisme ini mengalihkan kekuatan penetapan biaya dari aplikasi dan perantara ke algoritma protokol yang transparan.

Memecoin memang membawa pertumbuhan pesat ke Solana, namun juga menanamkan budaya spekulasi. Agar Solana bisa mewujudkan visi ICM, aplikasi pengendali trafik pengguna dan protokol pengelola infrastruktur harus dicegah berkolusi tanpa pengawasan.

Seperti pepatah, “Bersihkan rumah sebelum mengundang tamu.” Hanya dengan memperkuat arsitektur teknis, menghapus praktik rent-seeking, dan membangun pasar yang adil serta transparan yang mengutamakan kepentingan pengguna, Solana dapat benar-benar bersaing dan berintegrasi ke sistem keuangan tradisional.

Pernyataan:

1. Artikel ini diterbitkan ulang dari [BlockBeats], dengan hak cipta milik penulis asli [SpecialistXBT]. Untuk urusan hak cipta, hubungi tim Gate Learn untuk penyelesaian sesuai prosedur yang berlaku.
2. Disclaimer: Seluruh pandangan dan opini merupakan milik penulis dan tidak menjadi saran investasi.
3. Versi bahasa lain diterjemahkan oleh tim Gate Learn. Kecuali Gate disebutkan, artikel terjemahan tidak boleh disalin, didistribusikan, atau dijiplak.