Penulis: Mason Hall, Porter Smith, Miles Jennings, Ross Shuel
Disusun oleh: Deep Wave TechFlow
Untuk token infrastruktur, seperti jaringan Layer1 (atau bagian tumpukan komputasi yang berdekatan, seperti Layer2), model ekonominya relatif matang dan mudah dipahami, terutama berdasarkan pasokan dan permintaan ruang blok. Namun, untuk token aplikasi, protokol kontrak pintar yang menyebarkan layanan di blockchain yang memberikan hak dalam "perdagangan terdistribusi", model ekonominya masih dieksplorasi.
Model bisnis token aplikasi harus sama ekspresifnya dengan perangkat lunak yang mendasarinya. Untuk tujuan ini, kami mengusulkan model arus kas untuk token aplikasi - sebuah metode yang memungkinkan aplikasi menciptakan model ekonomi yang fleksibel dan permisif sambil membiarkan pengguna memilih bagaimana mereka diberi imbalan berdasarkan nilai yang diberikan. Pendekatan ini mendorong kepatuhan yang lebih besar dengan memberikan biaya untuk kegiatan hukum berdasarkan persyaratan peraturan di yurisdiksi yang berbeda. Pada saat yang sama, hal ini juga memaksimalkan nilai yang dikumpulkan oleh protokol dan mendorong tata kelola yang minimal.
Prinsip yang kami bagikan di sini berlaku untuk semua aplikasi Web3—mulai dari keuangan terdesentralisasi (DeFi) hingga aplikasi sosial terdesentralisasi, jaringan infrastruktur fisik terdesentralisasi (DePIN), dan bidang terkait lainnya.
Tantangan yang dihadapi model token
Token infrastruktur tunduk pada pasokan dan permintaan yang tertanam: ketika permintaan meningkat, pasokan menurun, dan pasar pun menyesuaikannya. Fondasi ekonomi ini telah diperkuat di banyak token infrastruktur, terutama melalui Ethereum Improvement Proposal 1559 (EIP-1559), yang menerapkan mekanisme pembakaran biaya yang mendasari semua transaksi Ethereum. Namun meskipun ada beberapa upaya pada model beli dan bakar, token aplikasi tidak memiliki mekanisme yang sebanding dengan EIP-1559.
Aplikasi adalah pengguna ruang blok, bukan penyedia, sehingga mereka tidak dapat mengandalkan pengumpulan biaya bahan bakar dari pengguna lain ruang blok mereka. Inilah sebabnya mengapa mereka perlu mengembangkan model ekonomi mereka sendiri.
Ada beberapa tantangan hukum juga di sini: model ekonomi token infrastruktur relatif kebal terhadap risiko hukum karena sifat umum dari transaksi blockchain dan mekanisme terprogram yang mereka gunakan. Namun untuk model ekonomi dari token penerapan, penerapan yang terlibat mungkin bergantung pada promosi aktivitas yang diatur dan mungkin memerlukan peran perantara dari pemegang token tata kelola – sehingga membuat model ekonomi menjadi lebih kompleks. Pertukaran terdesentralisasi yang memfasilitasi perdagangan derivatif adalah aktivitas yang sangat diatur di Amerika Serikat, yang secara fundamental berbeda dari proyek seperti Ethereum.
Kombinasi tantangan intrinsik dan ekstrinsik ini berarti bahwa penerapan token memerlukan model ekonomi yang berbeda. Dengan mengingat hal ini, kami mengusulkan solusi yang mungkin: pendekatan untuk merancang protokol yang bertujuan untuk memberi kompensasi kepada pemegang token aplikasi atas layanan mereka sambil memaksimalkan pendapatan protokol, memberi insentif pada kepatuhan, dan menggabungkan minimalisasi tata kelola. Tujuan kami sederhana: menyediakan token aplikasi dengan landasan ekonomi yang sama dengan banyak token infrastruktur melalui arus kas.
Solusi kami berfokus pada penyelesaian tiga masalah yang dihadapi oleh token aplikasi:
Tantangan terkait tata kelola
Tantangan terkait distribusi nilai
Tantangan terkait aktivitas yang diatur
1. Tantangan terkait tata kelola
Token aplikasi sering kali memiliki hak tata kelola, dan keberadaan organisasi otonom terdesentralisasi (DAO) dapat menimbulkan ketidakpastian yang tidak dihadapi oleh token infrastruktur. Untuk DAO dengan operasi signifikan di AS, risiko mungkin timbul jika DAO mengontrol pendapatan protokol atau menjadi perantara aktivitas ekonomi protokol dan secara terprogram mengontrol aktivitas tersebut. Untuk menghindari risiko ini, proyek dapat menghilangkan kendali atas DAO dengan meminimalkan tata kelola. Bagi DAO yang tidak mampu melakukan hal ini, Asosiasi Nirlaba Baru Terdesentralisasi (DUNA) di Wyoming menyediakan badan hukum terdesentralisasi yang dapat membantu memitigasi risiko ini dan mematuhi undang-undang perpajakan yang berlaku.
2. Tantangan terkait distribusi nilai
Aplikasi juga harus berhati-hati saat merancang mekanisme nilai yang dialokasikan kepada pemegang token. Menggabungkan hak suara dengan hak ekonomi dapat menimbulkan kekhawatiran berdasarkan undang-undang sekuritas AS, terutama untuk mekanisme yang sederhana dan mudah seperti pro-rata dan pembelian dan pembakaran token. Mekanisme ini terlihat mirip dengan dividen dan pembelian kembali saham, sehingga berpotensi melemahkan argumen bahwa token berhak mendapatkan kerangka peraturan yang berbeda dari ekuitas.
Proyek harus mengeksplorasi kapitalisme pemangku kepentingan – memberikan penghargaan kepada pemegang token atas kontribusi mereka terhadap proyek dengan cara yang menguntungkan proyek. Banyak proyek yang mendorong partisipasi aktif, termasuk mengoperasikan front-end (seperti Likuiditas), berpartisipasi dalam protokol (seperti Goldfinch), dan menjaminkan jaminan sebagai bagian dari modul keamanan (seperti Aave). Ruang desain di sini sangat luas, namun titik awal yang baik adalah memetakan seluruh pemangku kepentingan dalam proyek, menentukan perilaku mana yang harus didorong, dan memutuskan nilai keseluruhan yang dapat diciptakan oleh protokol melalui insentif ini.
Demi kesederhanaan, dalam artikel ini kita akan mengasumsikan model kompensasi sederhana yang memberikan penghargaan kepada pemegang token karena berpartisipasi dalam tata kelola, meskipun ada skema lain.
3. Tantangan terkait aktivitas yang diatur
Aplikasi yang memfasilitasi aktivitas yang diatur juga harus berhati-hati saat merancang mekanisme akumulasi nilai bagi pemegang token. Sejauh mekanisme ini menghasilkan nilai dari front-end atau API yang tidak beroperasi sesuai dengan hukum yang berlaku, pemegang token mungkin mendapat untung dari aktivitas ilegal.
Sebagian besar solusi yang diusulkan untuk masalah ini berfokus pada membatasi akumulasi nilai pada aktivitas yang diizinkan di Amerika Serikat—misalnya, hanya mengenakan biaya protokol pada kumpulan likuiditas yang melibatkan aset tertentu. Hal ini menjadikan pendekatan tata kelola umum minimum dan melemahkan proposisi nilai protokol perangkat lunak otonom global. Hal ini juga secara langsung melemahkan upaya minimalisasi tata kelola. Menentukan strategi biaya mana yang efektif dari perspektif kepatuhan terhadap peraturan bukanlah tugas yang tepat untuk DAO.
Idealnya, proyek harus dapat memungut biaya dari yurisdiksi mana pun yang mengizinkan aktivitas tersebut tanpa harus bergantung pada DAO untuk menentukan apa yang diperbolehkan. Solusinya bukan dengan mewajibkan kepatuhan di tingkat protokol, namun memastikan bahwa biaya yang dihasilkan oleh protokol hanya disalurkan sesuai dengan hukum dan peraturan yang berlaku di front end atau asal API. Jika Amerika Serikat melarang membebankan biaya untuk transaksi yang difasilitasi oleh suatu aplikasi, hal ini dapat mengurangi nilai ekonomi token aplikasi menjadi nol, meskipun aktivitas tersebut sepenuhnya legal di negara lain di seluruh dunia. Fleksibilitas dalam hal akumulasi dan alokasi biaya pada akhirnya berarti ketahanan dalam menghadapi tekanan peraturan.
Permasalahan inti: ketertelusuran pengeluaran
Ketertelusuran biaya sangat penting untuk mengatasi potensi risiko dari ketidakpatuhan tanpa menimbulkan risiko peninjauan atau membuat perjanjian memerlukan lisensi. Melalui ketertelusuran, aplikasi dapat memastikan bahwa biaya apa pun yang dibebankan kepada pemegang token hanya berasal dari front-end yang legal dan patuh pada yurisdiksi tempat pemegang token berada. Jika biaya tidak dapat dilacak, tidak ada cara untuk mengisolasi pemegang token dari nilai yang diperoleh dari front-end yang tidak patuh (yaitu biaya yang dibebankan oleh front-end yang tidak patuh), yang dapat membahayakan pemegang token.
Agar biaya dapat dilacak, protokol dapat mengadopsi desain sistem staking token aplikasi dua langkah:
Langkah 1: Identifikasi sumber pengeluaran front-end
Bagian 2: Menetapkan biaya ke kumpulan yang berbeda berdasarkan logika khusus
Memetakan bagian depan
Ketertelusuran biaya memerlukan pemetaan dari nama domain ke pasangan kunci publik/pribadi. Tanpa pemetaan ini, frontend jahat dapat memalsukan transaksi, berpura-pura bahwa transaksi tersebut dikirimkan dari domain yang jujur. Kriptografi memungkinkan kita untuk "mendaftarkan" bagian depan, mencatat secara permanen pemetaan nama domain ke kunci publik, membuktikan bahwa nama domain benar-benar mengontrol kunci publik tersebut, dan menggunakan kunci pribadi tersebut untuk menandatangani transaksi. Hal ini memungkinkan kami untuk mengatribusikan transaksi (dan juga biaya) ke domain tertentu.
Biaya perutean
Setelah sumber biaya dapat dilacak, protokol dapat memutuskan bagaimana mendistribusikan biaya tersebut untuk melindungi pemegang token dari biaya transaksi ilegal tanpa meningkatkan beban tata kelola DAO yang terdesentralisasi. Untuk membantu mengilustrasikan hal ini, pertimbangkan untuk menerapkan cakupan desain staking token, dari satu staking pool per frontend ke satu staking pool untuk semua frontend.
Dalam konstruksi paling sederhana, biaya setiap frontend dapat dialihkan ke modul staking khusus frontend yang terpisah. Dengan memilih frontend mana yang akan dipertaruhkan, pemegang token akan dapat memutuskan biaya apa yang mereka terima dan menghindari biaya apa pun yang dapat menempatkan mereka pada risiko hukum. Misalnya, pemegang token hanya dapat melakukan staking pada modul yang terkait dengan frontend yang telah menerima semua persetujuan peraturan di Eropa. Meskipun desain ini terdengar sederhana, sebenarnya cukup rumit. Mungkin ada 50 staking pool untuk 50 frontend yang berbeda, dan pengenceran biaya dapat berdampak buruk pada nilai token.
Di sisi lain spektrum desain, pengeluaran dari masing-masing front end dapat digabungkan – namun hal ini menggagalkan tujuan penelusuran biaya. Jika semua pengeluaran digabungkan, tidak akan ada cara untuk membedakan antara pengeluaran dari front end yang patuh dan pengeluaran dari front end yang tidak patuh, dan hanya satu apel buruk akan merusak keseluruhan biaya. Pemegang token akan dipaksa untuk memilih antara tidak menerima biaya atau melakukan staking di pool di mana mereka akan mendapatkan keuntungan dari aktivitas ilegal front-end yang tidak patuh di yurisdiksi mereka — —Opsi ini dapat membuat banyak pemegang token enggan berpartisipasi, atau dapat mengembalikan token sistem ke desain sub-optimal saat ini, di mana DAO harus mengevaluasi di mana biaya dapat diterapkan.
Memecahkan ketertelusuran biaya melalui kurasi
Kompleksitas ini dapat diatasi melalui kurasi. Pertimbangkan aplikasi protokol kontrak pintar tanpa izin dengan biaya dan token. Siapa pun dapat membuat frontend untuk aplikasi tersebut, dan setiap frontend dapat memiliki modul stakingnya sendiri. Kami menyebut ujung depan protokol ini App.xyz.
App.xyz dapat mematuhi aturan kepatuhan khusus di yurisdiksi tempatnya beroperasi. Aktivitas aplikasi dari App.xyz dikenakan biaya perjanjian. App.xyz memiliki modul stakingnya sendiri, di mana pemegang token dapat mempertaruhkan tokennya secara langsung, atau kepada kurator yang ingin memilih secara individual sekumpulan frontend yang mereka anggap patuh. Para pemegang token ini akan menerima pendapatan dalam bentuk biaya yang dihasilkan oleh front-end yang mereka pertaruhkan. Jika frontend menghasilkan biaya $100 dan 100 entitas masing-masing mempertaruhkan 1 token, setiap entitas berhak atas $1. Kurator pada awalnya dapat mengenakan biaya untuk layanan mereka. Di masa depan, pemerintah dapat melakukan sertifikasi kepatuhan secara on-chain dalam yurisdiksi mereka untuk membantu melindungi konsumen sekaligus mewujudkan manfaat tambahan dari kurasi otomatis.
Salah satu risiko potensial dalam model ini adalah front-end yang tidak patuh mungkin memiliki biaya operasional yang lebih rendah karena tidak memiliki biaya administratif dibandingkan front-end yang patuh. Mereka juga dapat merancang model yang mengembalikan biaya front-end kepada pedagang untuk lebih memberikan insentif dalam penyelesaian masalah. Ada dua faktor yang dapat mengurangi risiko ini. Pertama, sebagian besar pengguna sebenarnya menginginkan kepatuhan front-end untuk mengikuti undang-undang dan peraturan setempat, yang terutama berlaku untuk lembaga-lembaga besar yang memiliki regulasi. Kedua, tata kelola dapat memainkan peran penting sebagai upaya terakhir atau “hak veto” untuk mengekang perilaku buruk terhadap pihak-pihak yang tidak patuh yang berulang kali melanggar peraturan dan membahayakan kelangsungan penerapannya.
Terakhir, semua biaya transaksi yang tidak dimulai melalui frontend terdaftar akan disimpan ke dalam satu modul staking terintegrasi, memungkinkan protokol untuk memperoleh pendapatan yang dihasilkan oleh bot dan transaksi lain yang berinteraksi langsung dengan kontrak pintar protokol.
Dari teori hingga implementasi: mempraktikkan metode
Mari kita tinjau tumpukan token aplikasi secara lebih detail. Untuk memfasilitasi staking front-end, protokol perlu membuat kontrak pintar pendaftaran di mana front-end perlu mendaftar.
Setiap frontend atau API dapat menambahkan data TXT khusus ke data DNS untuk nama domainnya, seperti integrasi DNS ENS. Catatan TXT ini berisi kunci publik dari sepasang kunci yang dihasilkan oleh front end, yang disebut sertifikat.
Klien front-end dapat memanggil fungsi register() dan membuktikan bahwa ia memiliki nama domainnya. Pemetaan nama domain ke kunci publik sertifikat, serta pemetaan terbalik, akan disimpan.
Ketika transaksi dibuat melalui klien, klien juga menandatangani muatan transaksi dengan kunci publik sertifikatnya. Ini dikemas dan diteruskan ke kontrak pintar aplikasi.
Kontrak pintar yang diterapkan memverifikasi sertifikat, memeriksa apakah sertifikat tersebut sesuai dengan subjek transaksi yang benar dan terdaftar. Jika sudah maka transaksi diproses. Biaya yang dihasilkan dari transaksi tersebut kemudian dikirim ke kontrak FeeCollector bersama dengan nama domain (dari registri).
FeeCollector memungkinkan kurator, pengguna, validator, dan lainnya untuk secara langsung mempertaruhkan token pada domain atau kumpulan domain. Kontrak ini harus melacak jumlah token yang dipertaruhkan di setiap domain, bagian masing-masing alamat dalam kepemilikan tersebut, dan waktu dipertaruhkan. Implementasi penambangan likuiditas yang populer dapat menjadi titik awal untuk logika kontrak ini. Pengguna yang telah berjanji kepada kurator (atau secara langsung berjanji pada kontrak manajemen biaya) dapat menarik bagian biaya yang sesuai berdasarkan jumlah token aplikasi yang dijanjikan ke domain. Arsitekturnya mungkin mirip dengan MetaMorpho/Morpho Blue.
Solusi ini dapat diperkenalkan tanpa menambah beban tata kelola aplikasi DAO. Faktanya, tanggung jawab tata kelola dapat dikurangi karena peralihan biaya dapat diaktifkan secara permanen, berlaku untuk semua transaksi yang difasilitasi oleh protokol, sehingga menghilangkan kendali apa pun yang dimiliki DAO atas model ekonomi protokol.
Pertimbangan tambahan berdasarkan jenis aplikasi
Meskipun prinsip-prinsip ini berlaku secara luas pada model ekonomi token aplikasi, mungkin ada pertimbangan biaya tambahan tergantung pada jenis aplikasi (seperti aplikasi yang dibangun pada Layer1 atau Layer2, rantai aplikasi, dan aplikasi yang dibangun menggunakan Rollup).
Pertimbangan Aplikasi L1/L2
Aplikasi pada blockchain Lapisan 1 atau Lapisan 2 menerapkan kontrak pintar langsung pada rantai tersebut. Biaya dibebankan saat pengguna berinteraksi dengan kontrak pintar aplikasi. Biasanya, interaksi ini terjadi melalui front end yang mudah digunakan (seperti aplikasi atau situs web) yang bertindak sebagai antarmuka antara pengguna ritel dan kontrak pintar yang mendasarinya. Dalam hal ini, biaya apa pun akan berasal dari front-end tersebut. Contoh di app.xyz di atas menggambarkan cara kerja sistem pengeluaran di aplikasi Layer1.
Aplikasi juga dapat menggunakan pendekatan daftar putih atau daftar hitam untuk memfilter biaya front-end, daripada mengandalkan kurator. Tujuannya di sini adalah untuk memastikan bahwa baik pemegang token maupun seluruh protokol tidak mendapat untung atau manfaat dari aktivitas ilegal dan mematuhi hukum dan peraturan yurisdiksi tertentu.
Dalam pendekatan daftar putih, aplikasi menerbitkan serangkaian aturan frontend, membuat registri frontend yang mengikuti aturan tersebut, menerbitkan sertifikat ke frontend yang ikut serta, dan mengharuskan frontend untuk mempertaruhkan token guna menerima sebagian dari biaya aplikasi. Jika front-end tidak mengikuti aturan ini, kontribusi biayanya akan dikurangi dan sertifikatnya akan dicabut.
Dalam pendekatan daftar hitam, aplikasi tidak perlu membuat aturan apa pun, namun proses peluncuran frontend untuk aplikasi tidak akan dilakukan tanpa izin. Sebaliknya, aplikasi memerlukan front-end mana pun untuk memberikan pendapat dari firma hukum yang menyatakan bahwa front-end tersebut mematuhi peraturan yurisdiksinya sebelum diaktifkan. Setelah komentar diterima, aplikasi akan mengeluarkan sertifikat kontribusi biaya ke frontend, yang hanya akan dicabut jika aplikasi menerima pemberitahuan dari regulator bahwa frontend tidak patuh.
Jalur biaya akan serupa dengan contoh yang diberikan di bagian sebelumnya.
Kedua pendekatan ini secara signifikan meningkatkan beban tata kelola yang terdesentralisasi, yang mengharuskan DAO untuk menetapkan dan memelihara serangkaian aturan atau mengevaluasi pendapat hukum mengenai kepatuhan. Dalam beberapa kasus, hal ini mungkin dapat diterima, namun dalam banyak kasus, akan lebih baik jika beban kepatuhan diserahkan kepada kurator.
Pertimbangan rantai aplikasi
Rantai aplikasi adalah blockchain untuk aplikasi tertentu, dan validator hanya berfungsi untuk aplikasi tersebut.
Sebagai imbalan atas pekerjaan mereka, validator ini dibayar. Tidak seperti blockchain Lapisan 1, di mana validator biasanya diberi imbalan melalui penerbitan token inflasi, beberapa rantai aplikasi (seperti dYdX) membebankan biaya klien kepada validator.
Dalam model ini, pemegang token harus mempertaruhkan validator untuk menerima hadiah. Validator menjadi modul staking yang dikurasi.
Set kerja ini berbeda dari validator Layer1. Validator rantai aplikasi memproses transaksi tertentu dari aplikasi tertentu. Karena perbedaan ini, validator Lisk mungkin menghadapi risiko hukum yang lebih besar karena sifat aktivitas yang mereka fasilitasi. Oleh karena itu, protokol harus memberikan kebebasan kepada validator untuk melakukan pekerjaan mereka sesuai dengan hukum yurisdiksi mereka dan kenyamanan mereka sendiri. Yang penting, hal ini dapat dicapai tanpa mengorbankan sifat rantai aplikasi yang tidak memiliki izin atau memaparkannya pada risiko sensor yang signifikan, selama distribusi geografis validator didesentralisasi.
Arsitektur rantai aplikasi yang ingin memanfaatkan manfaat keterlacakan pengeluaran akan serupa dengan aplikasi Layer1, hingga ke saluran pengeluaran. Namun validator akan dapat menggunakan pemetaan frontend untuk menentukan frontend mana yang ingin mereka kerjakan. Biaya untuk setiap transaksi tertentu akan didistribusikan ke kumpulan validator aktif, sedangkan validator tidak aktif yang memilih untuk tidak berpartisipasi akan kehilangan biaya ini. Dari sudut pandang biaya, validator berfungsi sama dengan kurator modul staking yang dibahas di atas, dan para pemangku kepentingan yang melakukan staking pada validator ini dijamin bahwa mereka tidak akan menerima pendapatan dari aktivitas ilegal apa pun. Validator juga dapat memilih kurator untuk menentukan frontend mana yang patuh di yurisdiksinya masing-masing.
Pertimbangan untuk menerapkan Rollup
Rollup memiliki ruang bloknya sendiri tetapi dapat mewarisi keamanan rantai lain. Kebanyakan rollup saat ini memiliki satu sequencer yang bertanggung jawab untuk memesan dan memasukkan transaksi, meskipun transaksi dapat dikirimkan langsung ke Layer1 melalui proses yang disebut "inklusi paksa".
Jika rollup ini khusus untuk aplikasi dan memperlakukan pemesannya sebagai satu-satunya validator, biaya yang dihasilkan oleh transaksi yang termasuk dalam pemesan tersebut dapat didistribusikan ke pemangku kepentingan berdasarkan serangkaian frontend yang sesuai atau sebagai kumpulan umum.
Jika Rollup mendesentralisasikan kumpulan pemesannya, pemesan tersebut akan menjadi modul staking yang dikurasi secara de facto dan jalur biaya akan serupa dengan rantai aplikasi. Sequencer menggantikan validator untuk distribusi biaya, dan setiap sequencer dapat memutuskan front-end mana yang menerima biaya.
Meskipun ada banyak kemungkinan model untuk token aplikasi, menawarkan staking pool yang dikurasi adalah jalan ke depan yang membantu memecahkan tantangan eksternal unik aplikasi. Dengan mengenali tantangan intrinsik dan ekstrinsik yang dihadapi oleh aplikasi, para pendiri dapat merancang model token aplikasi dengan lebih baik untuk proyek mereka dari awal.
