Для токенів інфраструктури - які відповідають мережі рівня 1 (або суміжній частині стеку обчислення, такій як рівень 2) - економічні моделі добре розроблені й зрозумілі, кореняться вони в постачанні та попиті на блокпростір. Але для токенів додатків - протоколів розумних контрактів, що надають послуги на основі блокчейнів, що передають права в «розподілених бізнесах» - економічні моделі все ще вирішуються.

Бізнес-моделі токенів додатків повинні бути так само виразними, як їх базове програмне забезпечення. З цією метою ми запроваджуємо грошові потоки для токенів додатків - підхід, який дозволяє додаткам створювати дозволені, гнучкі моделі, а користувачам вибирати, як вони будуть винагороджуватися за надану ними цінність. Цей метод створює комісії з легітимних діяльностей відповідно до регуляторних вимог різних юрисдикцій, що сприяє більшій відповідності. Він також максимізує накопичення вартості протоколу, спонукаючи мінімізація управління.

Принципи, які ми ділимося тут, застосовуються до всіх веб-3 додатків - від DeFi до децентралізованих соціальних додатків, мереж DePIN та всюди посередині.

Виклики для моделей токенів

Токени інфраструктури підлягають вбудованому попиту та пропозиції: зі зростанням попиту пропозиція зменшується, і ринки відповідно адаптуються. Ця внутрішня економічна основа для багатьох токенів інфраструктури була прискорена за допомогою Пропозиції щодо покращення Ethereum 1559 (EIP-1559), який передбачає базову комісію для спалювання всіх транзакцій Ethereum. Але, незважаючи на розрізнені спроби моделей купівлі та спалювання, немає жодного аналогу EIP-1559 для токенів додатків.

Додатки є користувачами, а не постачальниками блок-простору, тому вони не можуть розраховувати на збір плати за газ від інших, які використовують їх блок-простір. Тому їм потрібно розробляти власні економічні моделі.

Тут також є деякі юридичні проблеми: економічні моделі інфраструктурних токенів більш ізольовані від юридичних ризиків через загальний характер типових блокчейн-транзакцій і програмних механізмів, які вони використовують. Але для економічних моделей токенів додатків залучені програми можуть залежати від полегшення регульованої діяльності та можуть вимагати посередництва власників токенів управління, що ускладнює економіку. Децентралізована біржа, яка полегшує торгівлю деривативами, що є суворо регульованою діяльністю в США, радикально відрізняється від, скажімо, Ethereum.

Поєднання цих внутрішніх та зовнішніх викликів означає, що токени додатків потребують іншої економічної моделі. З цим на увазі, ми пропонуємо один можливий розв'язок: метод для розробки протоколів, які компенсують власників токенів за їхні послуги, збільшуючи прибуток протоколу, стимулюючи дотримання регулятивних вимог та враховуючимінімізація управління. Наша мета проста: надати токени програм з тим же економічним забезпеченням, через грошові потоки, яке вже є у багатьох токенах інфраструктури.

Наше рішення спрямоване на вирішення трьох проблем, з якими стикаються токени додатків, пов'язаних з:

1. Виклики управління
2. Виклики з розподілом вартості
3. Проблеми з регульованою діяльністю

1. Проблеми з управлінням

Токени додатків, як правило, мають права управління, і наявність децентралізованої автономної організації (DAO) може внести невизначеність з якими не стикаються інфраструктурні токени. Для DAO зі значними операціями в США можуть виникнути ризики, якщо DAO контролює доходи протоколу або є посередником у економічній діяльності протоколу та робить таку діяльність програмною. Щоб уникнути цих ризиків, проєкти можуть усунути контроль, який має DAO, мінімізувавши управління. Для DAO, де це неможливо, новий Вайомінг Децентралізоване неприбуткове об'єднання без юридичної особи (DUNA)пропонуєадецентралізоване юридичне утворення, яке може допомогти зменшити ці ризики та відповідати вимогам податкового законодавства.

2. Проблеми з розподілом вартості

Applications must also exercise caution in designing the mechanism that distributes value to tokenholders. Combining голосування та економічні праваможе викликати обурення згідно з законами США про цінні папери, особливо з простими та прямими механізмами, такими як пропорційні розподіли та викуп токенів. Ці механізми схожі на дивіденди та викуп акцій, і можуть підірвати аргументи про те, що токени заслуговують на відмінну регулятивну рамку від акцій.

Проекти замість цього повинні досліджувати стейкхолдерський капіталізм — винагороджуючи власників токенів за внесок у проект таким чином, що приносить користь проекту. Багато проектів сприяли позитивній участі, включаючи роботу фронтенду (Liquity) , беручи участь в протоколі ( Золотий в'яз), і застава в якості складової частини модуля безпеки (Aave). Простір дизайну тут широкий, але хороше місце для початку - це складання картки всіх зацікавлених сторін у проекті, визначення, які поведінки слід сприяти від кожного з них, і вирішення, яке загальне значення може створити протокол через цю стимуляцію.

Для спрощення, у цьому дописі ми будемо вважати просту модель компенсації, яка винагороджує володарів токенів за участь у управлінні, хоча існують інші схеми.

3. Виклики з регульованою діяльністю

Додатки, які полегшують регулювання діяльності, також повинні бути обережними при розробці механізмів накопичення вартості для власників токенів. Якщо такі механізми накопичують вартість з фронтендів або API, які не працюють у відповідності до чинного законодавства, власники токенів можуть отримувати прибуток з незаконної діяльності.

Більшість запропонованих рішень щодо цієї проблеми спрямовані на обмеження накопичення вартості для діяльності, яка допустима в США, наприклад, увімкнення комісійного збору лише щодо ліквідності, яка стосується певних активів. Це піддає проекти найнижчому загальному рівню регулювання та підірвує вартісну пропозицію глобальних автономних програмних протоколів. Це також безпосередньо підірвує зусилля щодо мінімізації управління. Визначення стратегії комісійного збору, яка працює з точки зору відповідності регулятивним вимогам, не є відповідним завданням для DAO.

У ідеальному світі проекти змогли б збирати комісію з активності в будь-якій юрисдикції, де така активність дозволена, не покладаючись на DAO для визначення дозволеного.рішенняне вимагати дотримання регулятивних вимог на рівні протоколу, але забезпечити, що збори, зібрані за допомогою протоколу, передаються лише в тому випадку, якщо фронтенд або API, які їх створили, дотримуються відповідних законів та регуляцій, де знаходиться фронтенд. Якщо в США зробити незаконними збори за певний тип транзакції, яку сприяє програма, це може знизити економічну вартість токена цієї програми до нуля, навіть якщо така діяльність абсолютно дозволена в усіх інших країнах світу. Гнучкість у плані нарахування та розподілу зборів в кінцевому підсумку дорівнює стійкості в умовах регуляторного тиску.

Одна з головних проблем: відстеження комісій

Трасовість комісій є критичною для вирішення потенційних ризиків, що виникають внаслідок невідповідних фронтендів без введення ризику цензури або зроблення протоколу дозволеним. З трасовістю програма може гарантувати, що будь-які комісії, які надходять від володарів токенів, походять лише з фронтендів, які мають законну згоду в юрисдикції володаря токена. Якщо комісії не можуть бути прослідковані, не буде способу захистити володарів токенів від набуття вартості від невідповідних фронтендів (тобто комісій, зібраних невідповідними фронтендами), що може поставити володарів токенів під ризик.

Щоб зробити комісії відстежуваними, протокол може використовувати двоступеневий дизайн системи ставок на токени за додатком.

Крок 1: визначення, з якого фронтенду походять комісії, і

Крок 2: маршрутизація комісій до різних пулів на основі власної логіки.

Відображення фронтендів

Відстеження комісій вимагає відображення з домену на пару публічного / приватного ключа. Без цього відображення зловживний фронтенд може підробити транзакції та претендувати на те, що вони були подані з чесного домену. Криптографія дозволяє нам «реєструвати» фронтенди, незмінно записуючи відображення домену на публічний ключ, доводячи, що домен фактично контролює цей публічний ключ, і підписуючи транзакції вказаним приватним ключем. Це дозволяє нам приписувати транзакції, а отже, комісії, певному домену.

Плата за маршрутизацію

Після того, як джерело комісій буде відстежено, протокол може визначити, як розподілити ці комісії таким чином, щоб захистити власників токенів від отримання комісій від незаконних транзакцій, але це також не збільшує тягар децентралізованого управління DAO. Щоб проілюструвати цю думку, подумайте про спектр можливих варіантів стейкінгу токенів додатків, починаючи від одного пулу стейкінгу для кожного фронтенду і закінчуючи одним пулом стейкінгу для всіх фронтендів.

У своїй найпростішій конструкції, комісії кожного фронтенду можуть бути направлені до окремого фронтенд-специфічного модуля стейкінгу. Вибираючи, до яких фронтендів ставити стейк, володар токена зможе вирішити, які комісії він отримує і уникнути будь-яких комісій, які можуть наставити на володара токена правову небезпеку. Наприклад, володар токена може ставити стейк тільки на модуль, пов'язаний з фронтендом, який отримав усі регулюючі дозволи в Європі. Хоча цей дизайн звучить просто, насправді він досить складний. Може бути 50 пулів стейкінгу для 50 різних фронтендів, і розбавлення комісій може бути негативним для вартості токена.

На протилежному кінці спектра можна об'єднати комісії з кожного фронтенду, але це скасовує мету відстеження комісій. Якщо всі комісії об'єднуються, немає способу відрізнити комісії від сумісних фронтендів від несумісних — одне погане яблуко зіпсує весь бочонок. Власники токенів змушені вибирати між тим, щоб не отримувати жодних комісій або ставати у пул, де вони б отримували користь від нелегальної діяльності несумісних фронтендів у своїй юрисдикції — варіант, який може відлякати багатьох власників токенів від участі або може повернути систему до поточних неоптимальних конструкцій, де DAO повинен оцінювати, де можуть бути застосовані комісії.

Вирішення проблеми відстеження комісії через курацію

Ці складнощі можна вирішити за допомогою курації. Розгляньте додаток протоколу дозволеної мінливості розумного контракту, який має плату та токен. Будь-хто може створити фронтенд для додатку, і у кожного фронтенда може бути власний модуль стейкінгу. Давайте назвемо один фронтенд для цього протоколу app.xyz.

App.xyz міг би дотримуватися конкретних правил відповідності для юрисдикції, в якій він знаходиться. Активність програми, яка походить від app.xyz, генерує плату за протокол. App.xyz має власний модуль стейкінгу, і власники токенів можуть здійснювати стейкінг своїх токенів безпосередньо цьому модулю або куратору, який хоче індивідуально вибрати кошик інтерфейсів, які вони вважають сумісними. Ці стейкери токенів отримуватимуть дохід у вигляді комісій від набору фронтендів, на які вони здійснюють стейкінг. Якщо фронтенд генерує 100$ комісії, а 100 організацій здійснюють стейкінг по 1 токену, то кожна організація має право на 1$. Куратори спочатку могли стягувати плату за свої послуги. У майбутньому уряди можуть засвідчити відповідність фронтендів у своїй юрисдикції, щоб допомогти захистити споживачів, а додатковою перевагою буде автоматизація кураторства.

Один потенційний ризик цієї моделі полягає в тому, що невідповідні фронтенди можуть бути дешевшими в управлінні, оскільки вони не мають адміністративних витрат, які притаманні відповідним фронтендам. Вони також можуть вигадати моделі для повторного використання комісійних від фронтендів для трейдерів, щоб подальше стимулювати їх обхідні дії. Два фактори, які пом'якшують цей ризик. По-перше, більшість користувачів фактично хочуть, щоб відповідні фронтенди дотримувалися місцевих законів та регуляцій. Це особливо стосується великих, регульованих установ. По-друге, управління може відігравати важливу роль як останнє засіб або «право вето» щодо невідповідних фронтендів, які систематично порушують правила та загрожують життєздатності додатку, що стримує небажану поведінку.

На кінець, всі збори з транзакцій, які не ініціюються через зареєстрований фронтенд, будуть депонуватися в єдиному загальному модулі стейкінгу, що дозволяє протоколу отримувати дохід від транзакцій, ініційованих ботами та іншими безпосередніми взаємодіями з розумними контрактами протоколу.

Від теорії до втілення: Покладення методу на практику

Давайте детальніше розглянемо стек токенів додатків. Щоб протокол міг забезпечити фронтенд-стейкінг, йому потрібно буде створити реєстр розумного контракту, з яким фронтенди повинні будуть зареєструватися.

1. Кожний фронтенд або API може додати спеціальний запис TXT до DNS-запису свого домену, такого як Gate.Інтеграція ENS DNS. Цей запис TXT містить публічний ключ пари ключів, яку фронтенд генерує один раз, його називають сертифікатом.

1. Frontend-клієнт може викликати функцію register() та підтвердити, що він володіє своїм доменним ім'ям. Відображення домену на відкритий ключ сертифіката та навпаки зберігаються.
2. Коли операції створюються через клієнта, він також підписує навантаження операції своїм сертифікатом з відкритим ключем. Ці дані передаються у розумні контракти додатків в пакеті.
3. Спеціальні угоди додатка перевіряють сертифікат, перевіряють, що він відповідає правильному тілу tx, і був зареєстрований. Якщо так, транзакція обробляється. Збори, зібрані транзакцією, потім надсилаються контракту FeeCollector разом з доменним ім'ям (з реєстру).
4. FeeCollector дозволяє кураторам, користувачам, валідаторам та іншим укладати токени безпосередньо на домен або набір доменів. Ці контракти повинні вести облік кількості укладених токенів на кожному домені, частку цього ставки для кожної адреси та тривалість укладання. Популярні реалізації майнінгу ліквідності можуть бути використані як вихідна точка для логіки цього контракту.
5. Користувачі, які вклалися в кураторів (або безпосередньо в контракти управління комісіями), можуть відтягнути пропорційну частку комісії в залежності від обсягу токена додатків, який був вкладений в домен. Архітектура може бути подібною до Gate.MetaMorpho/Morpho Blue.

Це можна було б ввести, не збільшуючи бремена управління DAO додатку. Насправді, обов'язки управління можна було б зменшити, оскільки перемикач платежів може бути постійно включено для всіх транзакцій, які здійснюються за допомогою протоколу, тим самим вилучаючи будь-який контроль DAO над економічною моделлю протоколу.

Додаткові врахування на основі типу додатку

Хоча ці принципи застосовуються широко до економічних моделей токенів програм, можуть бути інші витрати, пов'язані з типом програми: програми, побудовані на Layer 1 або Layer 2, ланцюжки програм і програми, побудовані за допомогою rollups.

Питання для заявок L1/L2

Додатки на блокчейнах рівня 1 або рівня 2 мають розумні контракти, розгорнуті безпосередньо на ланцюжку. Збором плати займається при взаємодії користувачів з розумними контрактами додатків. Зазвичай це відбувається через простий у використанні фронтенд (наприклад, додаток або веб-сайт), який виступає інтерфейсом між роздрібним користувачем та базовими розумними контрактами. У цьому випадку будь-які збори походять від цього фронтенду. Вищенаведений приклад про app.xyz ілюструє, як може працювати система збору плати для додатка рівня 1.

Замість того, щоб покладатися на кураторів для фільтрації комісій за фронтенд, додатки також можуть використовувати підхід до білого або чорного списку до фронтендів, які вносять свій внесок у мережеві збори. Знову ж таки, мета тут полягатиме в тому, щоб гарантувати, що власники токенів і протокол в цілому не отримують прибутку або вигоди від незаконної діяльності та дотримуються законів і правил, специфічних для юрисдикції.

У підхіді з білого списку додаток буде публікувати набір правил для фронтендів, створювати реєстр тих фронтендів, які дотримуються правил, виписувати сертифікат фронтендам, які вибрали опцію участі, та вимагати від фронтендів заставити токени для отримання частини зборів за додаток. Якщо фронтенди не дотримуються цих правил, їм буде зменшено винагороду, а їх сертифікат для внесків у збори буде скасовано.

У підхіді з чорним списком додатки не мусили б створювати жодних правил, але запуск фронтенду для додатка не був би безперешкодним. Замість цього додаток потребував би, щоб будь-який фронтенд надіслав висновок юридичної фірми про те, що фронтенд відповідає її юрисдикції, перш ніж дозволити цьому фронтенду використовувати додаток. Після отримання висновку додаток видав би сертифікат фронтенду за внесок, який можна було б вилучити тільки в разі отримання повідомлення від регулятора про те, що фронтенд не відповідає вимогам.

Платіжний конвеєр буде відображати приклади, наведені в попередніх розділах.

Обидва цих підходу значно збільшують тягар децентралізованого управління, вимагають встановлення та підтримки набору правил або оцінки юридичних думок щодо виконання. У деяких випадках це може бути прийнятно, але в більшості випадків найкращим варіантом було б передати цей тягар дотримання куратору.

Розгляди для ланцюжків додатків

Appchains - це спеціалізовані блокчейни додатків з валідаторами, які працюють тільки для цього додатка.

У відповідь за їхню роботу ці валідатори отримують оплату. На відміну від блокчейнів рівня 1, де валідатори часто винагороджуються шляхом інфляційного видачі токенів, деякі appchains (dYdX) натомість передають комісії від клієнтів валідаторам.

У цій моделі власники токенів повинні здійснювати стейкінг до валідаторів, щоб отримати винагороду. Валідатори стають модулями курирування стейкінгу.

Цей набір робіт відрізняється від валідатора Layer 1. Валідатори Appchain вирішують конкретні транзакції з певного додатку. Через цю різницю валідатори Appchain можуть нести більшу правову ризику щодо діяльності, яку вони сприяють. В результаті протоколи повинні надавати валідаторам можливість виконувати роботу, яку вони можуть виконувати відповідно до законів своєї юрисдикції та власного рівня комфорту. Важливо, що це можна зробити, не піддаючи дозвіллю Appchain чи не піддаючи його значному ризику цензури, за умови, що його набір валідаторів є географічно децентралізованим.

Архітектура для апчейнів, які бажають скористатися перевагами відстеження комісій, буде схожа на додатки рівня 1 до конвеєра комісій. Але валідатори зможуть використовувати відображення інтерфейсу, щоб визначити, з яких фронтендів вони хочуть обробляти транзакції. Комісії за будь-яку транзакцію потім надходитимуть до активного набору валідаторів, а неактивні валідатори, які вирішили не брати участь, втрачають такі комісії. З точки зору комісії, валідатор виконує ту саму функцію, що й куратори модулів стейкінгу, про які йшлося вище, і стейкери цих валідаторів можуть гарантувати, що вони не отримують доходу від будь-якої незаконної діяльності. Валідатори також можуть обрати куратора, щоб визначити, які фронтенди відповідають вимогам для кожної юрисдикції.

Розгляди щодо застосування ролапів

Роллапи мають власний блоковий простір, але можуть успадкувати безпеку іншого ланцюга. Більшість зведень сьогодні мають єдиний секвенсор, який відповідає за секвенування та включення транзакцій, хоча транзакції можуть бути надіслані безпосередньо на рівень 1 за допомогою процесу, який називається «примусове включення.”

Якщо ці зведення є специфічними для конкретних додатків і закріплюють свій секвенсер як єдиний валідатор, комісії, отримані від транзакцій, включених цим секвенсором, можуть бути розподілені між стейкерами на основі підібраного набору сумісних інтерфейсів або у вигляді загального пулу.

Якщо rollups децентралізують свій набір послідовників, послідовники стануть де-факто курованими модулями стейкінгу, а конвеєр платежів буде відображати те, що зроблено для appchains. Послідовники заміняють валідаторів для розподілу платежів, і кожен послідовник може приймати власні рішення щодо того, з яких фронтендів приймати платежі.

Хоча існує багато можливих моделей для токенів додатків, надання кураторських пулів стейкінгу - це один із шляхів, який допомагає вирішити проблеми, пов'язані зі зовнішніми викликами, властивими додаткам. Розпізнавши внутрішні та зовнішні виклики, з якими стикаються додатки, засновники можуть краще розробити моделі токенів додатків з самого початку для своїх проектів.

Disclaimer:

1. Ця стаття перепублікована з [ a16zcrypto]. Усі авторські права належать оригінальному автору [Mason HallPorter SmithMiles Jennings і Ross Shuel]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно його вирішать.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіат перекладених статей заборонені.