Untuk token infrastruktur - yang sesuai dengan jaringan Layer 1 (atau bagian terkait dari stack komputasi seperti Layer 2) - model ekonomi telah dikembangkan dengan baik dan dipahami, berakar pada penawaran dan permintaan ruang blok. Tetapi untuk token aplikasi - protokol kontrak pintar yang menerapkan layanan di atas blockchain yang meneruskan hak dalam 'bisnis terdistribusi' - model ekonomi masih sedang dipecahkan.

Model bisnis token aplikasi harus seberani perangkat lunak yang mendasarinya. Untuk itu, kami memperkenalkan aliran kas untuk token aplikasi - pendekatan yang memungkinkan aplikasi untuk membuat model yang memungkinkan dan fleksibel dan pengguna untuk memilih bagaimana mereka dibalas atas nilai yang mereka berikan. Metode ini menciptakan biaya dari aktivitas yang sah di berbagai persyaratan regulasi yurisdiksi yang berbeda, mendorong kepatuhan yang lebih besar. Ini juga memaksimalkan nilai yang mengalir ke protokol sambil mendorong pengurangan tata kelola.

Prinsip-prinsip yang kami bagikan di sini berlaku untuk semua aplikasi web3 — dari DeFi hingga aplikasi sosial terdesentralisasi, jaringan DePIN, dan di mana pun di antaranya.

Tantangan untuk model token

Token infrastruktur tunduk pada pasokan dan permintaan yang tertanam: Saat permintaan meningkat, pasokan menurun, dan pasar menyesuaikan secara tepat. Dasar ekonomi asli untuk banyak token infrastruktur ini dipercepat oleh Ethereum Improvement Proposal 1559 (EIP-1559).EIP-1559) yang menerapkan biaya dasar yang harus dibakar untuk semua transaksi Ethereum. Tetapi meskipun upaya tersebar untuk model beli-dan-bakar, tidak ada paralel dengan EIP-1559 untuk token aplikasi.

Aplikasi adalah pengguna, bukan penyedia, dari ruang blok, sehingga mereka tidak dapat mengandalkan pengumpulan biaya gas dari orang lain yang menggunakan ruang blok mereka. Inilah sebabnya mengapa mereka perlu mengembangkan model ekonomi mereka sendiri.

Terdapat beberapa tantangan hukum di sini juga: model ekonomi token infrastruktur lebih terisolasi dari risiko hukum, karena sifat generik dari transaksi blockchain yang tipikal dan mekanisme programatik yang mereka gunakan. Namun, untuk model ekonomi token aplikasi, aplikasi yang terlibat mungkin bergantung pada fasilitasi aktivitas yang diatur dan mungkin memerlukan intermediasi oleh pemegang token tata kelola - membuat ekonomi lebih rumit. Bursa terdesentralisasi yang memfasilitasi perdagangan derivatif, aktivitas yang sangat diatur di AS, sangat berbeda dengan, katakanlah, Ethereum.

Kombinasi tantangan intrinsik dan ekstrinsik ini berarti bahwa token aplikasi memerlukan model ekonomi yang berbeda. Dengan itu diingat, kami menyajikan satu solusi yang mungkin: metode untuk merancang protokol yang mengganti pemegang token aplikasi untuk layanan mereka sambil memaksimalkan pendapatan protokol, mendorong kepatuhan regulasi, dan menggabungkanpemangkasan tata kelolaTujuan kami sederhana: memberikan token aplikasi dasar ekonomi yang sama, melalui aliran kas, yang sudah dimiliki oleh banyak token infrastruktur.

Solusi kami berfokus pada memecahkan tiga masalah yang dihadapi oleh token aplikasi terkait:

1. Tantangan dengan tata kelola
2. Tantangan dengan distribusi nilai
3. Tantangan dengan aktivitas yang diatur

1. Tantangan dalam tata kelola

Token aplikasi biasanya memiliki hak governance, dan keberadaan Organisasi Otonom Terdesentralisasi (DAO) bisa memperkenalkan ketidakpastiantoken infrastruktur tidak menghadapi. Untuk DAO dengan operasi U.S. yang signifikan, risiko dapat timbul jika DAO memiliki kontrol atas pendapatan protokol atau menjadi perantara aktivitas ekonomi protokol dan membuat aktivitas tersebut menjadi programatik. Untuk menghindari risiko-risiko ini, proyek-proyek dapat menghilangkan kontrol yang dimiliki DAO dengan meminimalkan tata kelola. Untuk DAO di mana hal itu tidak mungkin, negara bagian Wyoming yang baruAsosiasi Nonprofit Tidak Terinkorporasi Terdesentralisasi (DUNA)menyediakansatuentitas hukum terdesentralisasi yang dapat membantu meredakan risiko ini dan mematuhi undang-undang pajak yang berlaku.

2. Tantangan dengan distribusi nilai

Aplikasi juga harus berhati-hati dalam merancang mekanisme distribusi nilai kepada pemegang token. Menggabungkan hak pilih dan hak ekonomimungkin menimbulkan kekhawatiran di bawah hukum sekuritas AS, terutama dengan mekanisme yang sederhana dan langsung seperti distribusi pro rata dan pembelian dan pembakaran token. Mekanisme ini mirip dengan dividen dan pembelian saham kembali, dan dapat merusak argumen bahwa token layak mendapatkan kerangka regulasi yang berbeda dari ekuitas.

Proyek sebaliknya harus mengeksplorasi kapitalisme pemangku kepentingan – memberi penghargaan kepada pemegang token atas kontribusi pada proyek dengan cara yang menguntungkan proyek. Banyak proyek telah mendorong partisipasi positif, termasuk mengoperasikan frontend (Liquity) , berpartisipasi dalam protokol ( Goldfinch) dan menyerahkan jaminan sebagai bagian dari modul keamanan (Aave. Ruang desain di sini terbuka lebar, tetapi tempat yang baik untuk memulai adalah memetakan semua pemangku kepentingan dalam sebuah proyek, menentukan perilaku apa yang harus didorong dari masing-masing dari mereka, dan memutuskan nilai utama apa yang dapat diciptakan protokol melalui insentivasi tersebut.

Untuk kesederhanaan, dalam posting ini kami akan mengasumsikan model kompensasi sederhana yang memberikan imbalan kepada pemegang token atas partisipasi dalam tata kelola, meskipun skema lain ada.

3. Tantangan dengan kegiatan yang diatur

Aplikasi yang memfasilitasi kegiatan yang diatur juga harus berhati-hati saat merancang mekanisme akumulasi nilai untuk pemegang token. Jika mekanisme tersebut mengakumulasi nilai dari frontend atau API yang tidak dioperasikan sesuai dengan hukum yang berlaku, pemegang token dapat memperoleh keuntungan dari kegiatan ilegal.

Sebagian besar solusi yang diusulkan untuk masalah ini telah difokuskan pada membatasi akumulasi nilai ke aktivitas yang diperbolehkan di AS — misalnya, hanya mengaktifkan biaya protokol sehubungan dengan kolam likuiditas yang melibatkan aset tertentu. Hal ini membuat proyek-proyek tunduk pada pendekatan regulasi yang paling rendah dan merusak proposisi nilai dari protokol perangkat lunak otonom global. Hal ini juga secara langsung merusak upaya minimisasi tata kelola. Menentukan strategi biaya mana yang cocok dari perspektif kepatuhan regulasi bukanlah tugas yang tepat untuk DAOs.

Dalam dunia yang ideal, proyek-proyek akan dapat mengumpulkan biaya dari aktivitas di setiap yurisdiksi di mana aktivitas tersebut diperbolehkan, tanpa harus mengandalkan DAO untuk menentukan apa yang diperbolehkan. solusitidak mengharuskan kepatuhan regulasi pada tingkat protokol tetapi untuk memastikan bahwa biaya yang dihasilkan oleh protokol hanya akan diteruskan jika frontend atau API yang menghasilkannya mengikuti hukum dan regulasi yang berlaku di tempat frontend tersebut berada. Jika Amerika Serikat membuatnya ilegal untuk mengumpulkan biaya pada jenis transaksi tertentu yang difasilitasi oleh aplikasi, ini dapat mengurangi nilai ekonomi token aplikasi tersebut menjadi nol, meskipun kegiatan tersebut sepenuhnya diizinkan di negara lain di dunia. Fleksibilitas dalam hal pengumpulan biaya dan distribusi akhirnya menciptakan ketahanan dalam menghadapi tekanan regulasi.

Satu isu inti: Pelacakan biaya

Pelacakan biaya sangat penting untuk mengatasi risiko potensial yang timbul dari frontend yang tidak sesuai dengan persyaratan tanpa memperkenalkan risiko sensor atau membuat protokol berizin. Dengan pelacakan, sebuah aplikasi dapat memastikan bahwa setiap biaya yang diperoleh oleh pemegang token hanya berasal dari frontend yang sesuai dengan hukum di yurisdiksi pemegang token. Jika biaya tidak dapat dilacak, tidak akan ada cara untuk melindungi pemegang token dari nilai yang diperoleh dari frontend yang tidak sesuai dengan persyaratan (misalnya, biaya yang dikumpulkan oleh frontend yang tidak sesuai dengan persyaratan), yang dapat menghadapkan pemegang token pada risiko.

Untuk membuat biaya terlacak, sebuah protokol dapat menggunakan desain sistem staking token aplikasi dua langkah.

Langkah 1: mengidentifikasi frontend mana yang berasal dari biaya, dan

Langkah 2: mengalihkan biaya ke berbagai kolam berdasarkan logika kustom.

Mapping frontends

Jejak biaya membutuhkan pemetaan satu-satu dari domain ke pasangan kunci publik/privat. Tanpa pemetaan ini, frontend yang jahat dapat memalsukan transaksi dan berpura-pura bahwa mereka dikirimkan dari domain yang jujur. Kriptografi memungkinkan kita untuk 'mendaftarkan' frontend, merekam domain ke pemetaan kunci publik secara tak tergoyahkan, membuktikan bahwa domain tersebut benar-benar mengontrol kunci publik tersebut, dan menandatangani transaksi dengan kunci privat tersebut. Hal ini memberikan kita kemampuan untuk mengatribusikan transaksi, dan dengan demikian biaya, ke suatu domain yang diberikan.

Biaya routing

Setelah sumber biaya dapat dilacak, protokol dapat menentukan bagaimana mendistribusikan biaya tersebut dengan cara yang melindungi pemegang token dari menerima biaya dari transaksi ilegal, namun juga tidak meningkatkan beban pengelolaan terdesentralisasi dari DAO. Untuk membantu menggambarkan hal ini, bayangkan spektrum desain yang mungkin untuk staking token aplikasi, mulai dari satu kolam pengeposan untuk setiap frontend hingga satu kolam pengeposan untuk semua frontend.

Dalam konstruksi paling sederhana, biaya dari setiap frontend dapat diarahkan ke modul staking khusus frontend yang berbeda. Dengan memilih frontends mana yang akan dipertaruhkan, pemegang token akan dapat memutuskan biaya mana yang diterimanya dan menghindari biaya apa pun yang menempatkan pemegang token dalam bahaya hukum. Sebagai contoh, pemegang token hanya dapat mempertaruhkan modul yang terkait dengan frontend yang telah menerima semua persetujuan regulasi di Eropa. Meskipun desain ini terdengar sederhana, sebenarnya cukup rumit. Bisa jadi ada 50 kolam staking untuk 50 frontend yang berbeda, dan dilusi biaya bisa merugikan nilai token.

Di ujung spektrum yang berlawanan, biaya dari setiap antarmuka depan dapat digabungkan bersama — tetapi ini mengalahkan tujuan pelacakan biaya. Jika semua biaya digabungkan bersama, tidak ada cara untuk membedakan biaya dari antarmuka depan yang mematuhi peraturan dengan yang tidak mematuhi — satu apel busuk akan merusak seluruh tong. Pemegang token akan dipaksa untuk memilih antara tidak menerima biaya atau kepemilikan saham dalam sebuah pool di mana mereka akan mendapatkan keuntungan dari aktivitas ilegal antarmuka depan yang tidak mematuhi peraturan di yurisdiksi mereka — pilihan yang dapat menahan banyak pemegang token dari berpartisipasi atau dapat membuat sistem kembali ke desain suboptimal saat ini, di mana DAO harus menilai di mana biaya dapat diterapkan.

Mengatasi keterlacakan biaya melalui kurasi

Kompleksitas-kompleksitas ini dapat diatasi melalui kurasi. Pertimbangkan aplikasi protokol kontrak pintar tanpa izin yang memiliki biaya dan token. Siapa pun dapat membuat frontend untuk aplikasi dan setiap frontend dapat memiliki modul stakingnya sendiri. Mari kita sebut salah satu frontend untuk aplikasi protokol ini app.xyz.

App.xyz dapat mengikuti aturan kepatuhan tertentu untuk yurisdiksi tempatnya berada. Aktivitas aplikasi yang berasal dari app.xyz menghasilkan biaya protokol. App.xyz memiliki modul staking sendiri, dan pemegang token dapat melakukan staking token mereka ke modul tersebut secara langsung atau ke kurator yang ingin memilih secara individual keranjang frontend yang mereka anggap patuh. Stakeholder token ini akan mendapatkan hasil dalam bentuk biaya dari kumpulan frontend yang mereka staking. Jika sebuah frontend menghasilkan $100 dalam biaya, dan 100 entitas masing-masing melakukan staking 1 token, maka setiap entitas berhak atas $1. Kurator awalnya dapat membebankan biaya untuk layanan mereka. Di masa depan, pemerintah dapat membuat penegasan onchain tentang ketaatan frontend di yurisdiksi mereka untuk membantu melindungi konsumen, dengan manfaat tambahan yaitu otomatisasi kurasi.

Salah satu risiko potensial dalam model ini adalah bahwa frontend yang tidak patuh bisa lebih murah untuk dioperasikan karena mereka tidak memiliki overhead administratif frontend yang sesuai. Mereka juga dapat merancang model untuk mendaur ulang biaya frontend kepada pedagang untuk lebih memberi insentif pada solusi mereka. Dua faktor mitiGate risiko ini. Pertama, sebagian besar pengguna benar-benar ingin frontend yang sesuai untuk mengikuti hukum dan peraturan setempat mereka. Ini berlaku terutama untuk lembaga besar yang diatur. Kedua, tata kelola dapat memainkan peran penting sebagai upaya terakhir atau "otoritas veto" pada frontend yang tidak patuh yang berulang kali melanggar aturan dan membahayakan kelangsungan hidup aplikasi, mencegah perilaku buruk.

Akhirnya, semua biaya dari transaksi yang tidak dimulai melalui frontend terdaftar akan disimpan dalam modul staking catchall tunggal, memungkinkan protokol untuk mendapatkan pendapatan dari transaksi yang dimulai oleh bot dan interaksi langsung lainnya dengan kontrak pintar protokol.

Dari teori ke implementasi: Mengaplikasikan metode ke dalam praktik

Mari kita ulang tumpukan token aplikasi dengan lebih detail. Untuk sebuah protokol untuk memfasilitasi staking frontend, protokol tersebut perlu membuat kontrak pintar registri yang front-end perlu mendaftar.

1. Setiap frontend atau API dapat menambahkan catatan TXT khusus ke catatan DNS domain mereka seperti Integrasi ENS DNS. Rekam TXT ini berisi kunci publik dari pasangan kunci yang dihasilkan oleh frontend sekali, yang disebut sertifikat.

1. Klien frontend kemudian dapat memanggil fungsi register() dan membuktikan bahwa ia memiliki nama domainnya. Pemetaan domain ke kunci publik sertifikat, dan sebaliknya, disimpan.
2. Ketika transaksi dibuat melalui klien, itu juga menandatangani muatan transaksi dengan kunci publik sertifikatnya. Ini dilewatkan ke kontrak pintar aplikasi dalam bundel.
3. Smart contract dari aplikasi memvalidasi sertifikat, memeriksa apakah sertifikat tersebut sesuai dengan body transaksi yang benar dan sudah terdaftar. Jika iya, transaksi akan diproses. Biaya yang dihasilkan dari transaksi kemudian dikirim ke kontrak FeeCollector bersama dengan nama domain (dari registry).
4. FeeCollector memungkinkan kurator, pengguna, validator, dan orang lain untuk mempertaruhkan token secara langsung ke domain atau set domain. Kontrak-kontrak ini harus melacak jumlah token yang dipertaruhkan pada setiap domain, bagian dari taruhan setiap alamat, dan jumlah waktu token tersebut dipertaruhkan. Implementasi populer dari penambangan likuiditas dapat digunakan sebagai titik awal untuk logika kontrak ini.
5. Pengguna yang telah melakukan staking ke kurator (atau langsung ke kontrak Manajemen Biaya itu sendiri) kemudian dapat menarik bagian proporsional dari biaya sesuai dengan jumlah token aplikasi yang dipertaruhkan ke domain. Arsitekturnya bisa mirip dengan MetaMorpho/Biru Morpho.

Ini dapat diperkenalkan tanpa meningkatkan beban pengelolaan dari DAO aplikasi. Bahkan, tanggung jawab pengelolaan dapat dikurangi karena peralihan biaya dapat diaktifkan secara permanen untuk semua transaksi yang difasilitasi oleh protokol, dengan demikian menghilangkan kendali DAO terhadap model ekonomi protokol.

Pertimbangan tambahan berdasarkan jenis aplikasi

Sementara prinsip-prinsip ini berlaku secara umum untuk model ekonomi token aplikasi, ada pertimbangan biaya lain berdasarkan jenis aplikasi: aplikasi yang dibangun pada Layer 1 atau Layer 2, rantai aplikasi, dan aplikasi yang dibangun menggunakan rollups.

Pertimbangan untuk aplikasi L1/ L2

Aplikasi di blockchain Layer 1 atau Layer 2 memiliki kontrak pintar yang diterapkan langsung onchain. Biaya akan dikumpulkan ketika pengguna berinteraksi dengan kontrak pintar aplikasi tersebut. Biasanya hal ini terjadi melalui antarmuka yang mudah digunakan (seperti aplikasi atau situs web) yang berfungsi sebagai antarmuka antara pengguna ritel dan kontrak pintar yang mendasarinya. Dalam hal ini, biaya apapun berasal dari antarmuka tersebut. Contoh di atas tentang app.xyz menggambarkan bagaimana sistem biaya dapat berfungsi untuk aplikasi Layer 1.

Alih-alih bergantung pada kurator untuk menyaring biaya frontend, aplikasi juga bisa mengambil pendekatan daftar putih atau daftar hitam terhadap frontend yang berkontribusi pada biaya jaringan. Sekali lagi, tujuan di sini adalah untuk memastikan bahwa pemegang token, dan protokol secara umum, tidak mengambil keuntungan atau mendapat manfaat dari aktivitas ilegal dan mematuhi hukum dan regulasi yang spesifik untuk yurisdiksi tersebut.

Dalam pendekatan daftar putih, aplikasi akan mempublikasikan sekumpulan aturan untuk frontends, membuat registri frontends yang mengikuti aturan tersebut, mengeluarkan sertifikat kepada frontends yang memilih masuk, dan meminta frontends untuk mempertaruhkan token untuk menerima bagian dari biaya aplikasi. Jika frontends tidak mengikuti aturan ini, mereka akan dipangkas, dan sertifikat mereka untuk sumbangan biaya akan dihapus.

Dalam pendekatan daftar hitam, aplikasi tidak perlu membuat aturan apa pun, tetapi peluncuran frontend untuk aplikasi tidak akan bersifat tanpa izin. Sebaliknya, aplikasi akan memerlukan bahwa setiap frontend memberikan pendapat dari firma hukum bahwa frontend tersebut sesuai dengan yurisdiksinya sebelum memungkinkan frontend tersebut menggunakan aplikasi. Setelah pendapat diterima, aplikasi akan mengeluarkan sertifikat kepada frontend untuk kontribusi biaya yang hanya akan dihapus jika aplikasi menerima pemberitahuan dari regulator bahwa frontend tersebut tidak sesuai.

Saluran biaya akan mencerminkan contoh yang diberikan di bagian sebelumnya.

Kedua pendekatan ini secara signifikan meningkatkan beban tata kelola terdesentralisasi, yang memerlukan DAO untuk menetapkan dan mempertahankan seperangkat aturan atau menilai pendapat hukum tentang kepatuhan. Dalam beberapa kasus, hal ini mungkin dapat diterima, tetapi dalam kebanyakan kasus, menyerahkan beban kepatuhan ini kepada seorang kurator akan lebih disukai.

Pertimbangan untuk appchains

Appchains adalah blockchain khusus aplikasi dengan validator yang bekerja hanya untuk aplikasi tersebut.

Sebagai imbalan atas kerja mereka, para validator menerima pembayaran. Berbeda dengan blockchain Layer 1 di mana para validator sering kali mendapat imbalan melalui penerbitan token yang mengalami inflasi, beberapa appchains (dYdX) justru meneruskan biaya pelanggan kepada validator.

Dalam model ini, pemegang token harus bertaruh kepada validator untuk menerima imbalan. Para validator menjadi modul staking yang dikurasi.

Set kerja ini berbeda dari validator Layer 1. Validator Appchain menyelesaikan transaksi tertentu dari aplikasi tertentu. Karena perbedaan ini, validator Appchain dapat menanggung tingkat risiko hukum yang lebih besar terkait dengan aktivitas mendasar yang mereka fasilitasi. Sebagai hasilnya, protokol harus memberikan kebebasan kepada validator untuk melakukan pekerjaan yang dapat mereka lakukan sesuai dengan hukum yurisdiksi mereka dan tingkat kenyamanan mereka sendiri. Yang penting, ini dapat dilakukan tanpa mengancam keterbukaan izin dari Appchain atau menghadapkan risiko sensor yang signifikan asalkan set validatornya terdesentralisasi secara geografis.

Arsitektur untuk appchains yang ingin memanfaatkan manfaat jejak biaya akan mirip dengan aplikasi Layer 1 hingga pipa biaya. Namun validator akan dapat menggunakan pemetaan frontend untuk menentukan frontend mana yang ingin mereka proses transaksi dari. Biaya untuk transaksi tertentu kemudian akan diberikan ke set validator aktif, dengan validator tidak aktif yang memilih untuk tidak berpartisipasi kehilangan biaya tersebut. Dari perspektif biaya, validator melakukan fungsi yang sama seperti kurator modul staking yang dibahas di atas dan pemilik saham kepada validator tersebut dapat memastikan bahwa mereka tidak menerima pendapatan dari kegiatan ilegal. Validator juga dapat memilih kurator untuk menentukan frontend mana yang sesuai sesuai yurisdiksi.

Pertimbangan untuk aplikasi rollups

Rollup memiliki blockspace sendiri tetapi dapat mewarisi keamanan rantai lain. Sebagian besar rollup saat ini memiliki sequencer tunggal yang bertanggung jawab untuk mengurutkan dan termasuk transaksi, meskipun transaksi dapat dikirimkan langsung ke Layer 1 melalui proses yang disebut "forced-inclusion.”

Jika rollups ini khusus untuk aplikasi dan mengabadikan penyusunnya sebagai validator tunggal, biaya yang dihasilkan dari transaksi yang disertakan oleh penyusun tersebut dapat didistribusikan kepada staker berdasarkan kumpulan frontend yang patuh atau sebagai kolam umum yang disusun.

Jika rollups mendekentralisasi set pengurutan mereka, pengurut menjadi modul staking yang dikuratori dan saluran biaya akan mencerminkan appchains. Pengurut menggantikan validator untuk distribusi biaya, dan setiap pengurut dapat membuat keputusan sendiri tentang frontend mana yang menerima biaya.

Sementara ada banyak model yang mungkin untuk token aplikasi, menyediakan kolam penjatahan yang disaring adalah salah satu langkah maju yang membantu menyelesaikan masalah-masalah ekstrinsik yang unik bagi aplikasi. Dengan mengakui tantangan intrinsik dan ekstrinsik yang dihadapi oleh aplikasi, para pendiri dapat merancang model token aplikasi yang lebih baik dari awal untuk proyek mereka.

Penafian:

1. Artikel ini dicetak ulang dari [a16zcrypto]. Semua hak cipta dimiliki oleh penulis asli [Mason HallPorter SmithMiles Jennings dan Ross Shuel]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini sepenuhnya milik penulis dan tidak merupakan nasihat investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau melakukan plagiarisme terhadap artikel yang diterjemahkan dilarang.