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

Модели бизнеса токенов приложений должны быть такими же выразительными, как их базовое программное обеспечение. В этой связи мы представляем денежные потоки для токенов приложений - подход, который позволяет приложениям создавать разрешительные, гибкие модели, а пользователям выбирать, как они будут вознаграждены за создаваемое ими значение. Этот метод создает сборы с законных деятельностей в различных юрисдикциях, соответствуя их регуляторным требованиям, стимулируя большее соблюдение. Он также максимизирует создание стоимости для протокола, одновременно поощряя управление минимизацией.

Принципы, которыми мы делимся здесь, применимы ко всем веб-приложениям web3 — от DeFi до децентрализованных социальных приложений, сетей DePIN и всего, что находится между ними.

Проблемы моделей токенов

Токены инфраструктуры подвержены встроенному спросу и предложению: по мере увеличения спроса уменьшается предложение, и рынки соответственно корректируются. Эта внутренняя экономическая основа для многих токенов инфраструктуры была ускорена Предложением по Улучшению Ethereum 1559 (EIP-1559)EIP-1559) , который реализовал базовую комиссию для сжигания всех транзакций Ethereum. Но несмотря на изолированные попытки моделей покупки и сжигания, нет параллели с EIP-1559 для токенов приложений.

Приложения - это пользователи, а не поставщики места в блоке, поэтому они не могут полагаться на сбор газовых сборов от других, использующих их блок-пространство. Вот почему им нужно разрабатывать свои собственные экономические модели.

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

Комбинация внутренних и внешних проблем означает, что токены приложений требуют другой экономической модели. Имея это в виду, мы представляем одно возможное решение: метод проектирования протоколов, который компенсирует владельцам токенов приложений за их услуги, максимизирует доход протокола, стимулирует соответствие нормативным требованиям и интегрирует минимизация управления. Наша цель проста: дать токенам приложений ту же экономическую основу, через денежные потоки, которую уже имеют многие инфраструктурные токены.

Наше решение направлено на решение трех проблем, с которыми сталкиваются токены приложений, связанные с:

1. Проблемы с управлением
2. Проблемы с распределением ценности
3. Проблемы с регулируемой деятельностью

1. Проблемы с управлением

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

2. Проблемы с распределением ценности

Приложения также должны проявлять осторожность при разработке механизма распределения стоимости среди держателей токенов. Комбинирование права на голосование и экономические праваможет вызывать опасения с точки зрения законодательства США о ценных бумагах, особенно с простыми и прямыми механизмами, такими как пропорциональное распределение и покупка и сжигание токенов. Эти механизмы выглядят похожими на дивиденды и выкуп акций, и могут подорвать аргументы о том, что токены заслуживают отдельной регулятивной рамки от акций.

Проектам следует вместо этого исследовать капитализм заинтересованных сторон - вознаграждение владельцев токенов за вклад в проект таким образом, чтобы это было полезно для проекта. Многие проекты поощряют позитивное участие, включая работу с пользовательским интерфейсом (Liquity) участвует в протоколе (Goldfinch) и предоставление залога в качестве части модуля безопасности (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 своего домена, напримерИнтеграция ENS DNSЭта запись TXT содержит открытый ключ пары ключей, которую генерирует фронтэнд один раз, называемый сертификатом.

1. Затем клиентский интерфейс может вызвать функцию register() и доказать, что он владеет своим доменным именем. Отображение домена на открытый ключ сертификата и наоборот хранится.
2. Когда транзакции создаются через клиент, он также подписывает полезную нагрузку транзакции своим открытым ключом сертификата. Они передаются в умные контракты приложения в пакете.
3. Смарт-контракты приложения проверяют сертификат, проверяют, соответствует ли он правильному телу транзакции и был ли зарегистрирован. Если да, транзакция обрабатывается. Сборы, полученные от транзакции, затем отправляются в контракт FeeCollector вместе с именем домена (из реестра).
4. FeeCollector позволяет кураторам, пользователям, валидаторам и другим застейкать токены напрямую на домен или набор доменов. Эти контракты должны отслеживать количество застейканных токенов на каждом домене, долю этого стейка для каждого адреса и время, в течение которого они были застейканы. Популярные реализации добычи ликвидности могут быть использованы в качестве отправной точки для логики этого контракта.
5. Пользователи, которые зарекомендовались кураторам (или непосредственно контрактам управления комиссиями), могут затем вывести пропорциональную долю комиссии в соответствии с количеством токенов приложения, зарекомендованных домену. Архитектура может быть похожа на.MetaMorpho/Morpho Blue.

Это можно было бы ввести, не увеличивая бремя управления DAO приложения. Фактически, обязанности по управлению могут быть сокращены, так как переключатель комиссии может быть включен постоянно для всех операций, осуществляемых протоколом, тем самым удаляя контроль DAO над экономической моделью протокола.

Дополнительные соображения на основе типа приложения

В то время как эти принципы широко применимы к экономическим моделям токенов приложений, могут существовать и другие рассмотрения платы на основе типа приложения: приложения, построенные на Layer 1 или Layer 2, app-цепочки и приложения, построенные с использованием роллапов.

Рассмотрение заявок на L1/L2 приложения

Приложения на блокчейнах уровня 1 или уровня 2 имеют умные контракты, развернутые напрямую onchain. Сбор сборов происходит при взаимодействии пользователей с умными контрактами приложений. Обычно это происходит через простой в использовании фронтенд (например, приложение или веб-сайт), который служит интерфейсом между розничным пользователем и основными умными контрактами. В этом случае любые сборы происходят с этого фронтенда. Приведенный выше пример о приложении app.xyz показывает, как может работать система сбора сборов для приложения уровня 1.

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

При подходе к белому списку приложение опубликует набор правил для фронтендов, создаст реестр тех фронтендов, которые следуют правилам, выдаст сертификат фронтендам, которые согласятся, и потребует от фронтендов заложить токены, чтобы получить часть сборов за приложение. Если фронтенды не следуют этим правилам, их накажут, и их сертификат для взносов в сборы будет аннулирован.

При использовании черного списка приложениям не нужно создавать правила, но запуск фронтенда для приложения не будет разрешен без разрешения. Вместо этого, приложение потребует, чтобы любой фронтенд предоставил мнение юридической фирмы о соответствии фронтенда его юрисдикции, прежде чем разрешить использование приложения этим фронтендом. После получения мнения приложение выдаст сертификат фронтенду за взносы, которые будут удалены только в случае получения приложением уведомления от регулятора о том, что фронтенд не соответствует правилам.

Пайплайн комиссий будет дублировать примеры, представленные в предыдущих разделах.

Оба этих подхода значительно увеличивают бремя децентрализованного управления, требуя от DAO либо установить и поддерживать набор правил, либо оценивать юридические мнения о соответствии. В некоторых случаях это может быть приемлемо, но в большинстве случаев предпочтительнее будет передать это бремя соответствия куратору.

Рассмотрение приложений

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

В замен на свою работу эти валидаторы получают оплату. В отличие от блокчейнов уровня 1, где валидаторы часто получают вознаграждение за счет инфляционного выпуска токенов, некоторые приложения (dYdX) передают комиссии клиентов валидаторам.

В этой модели токенхолдеры должны ставить у валидаторов, чтобы получать вознаграждение. Валидаторы становятся отборочными модулями стейкинга.

Этот рабочий набор отличается от валидатора уровня 1. Валидаторы Appchain проводят расчеты по конкретным транзакциям из конкретного приложения. Из-за этой разницы валидаторы аппчейна могут нести большую степень юридического риска в отношении основной деятельности, которой они способствуют. В результате, протоколы должны предоставлять валидаторам свободу выполнять работу, которую они могут выполнять в соответствии с законами своей юрисдикции и собственным уровнем комфорта. Важно отметить, что это можно сделать, не ставя под угрозу отсутствие разрешений аппчейна и не подвергая его значительному риску цензуры, при условии, что его набор валидаторов географически децентрализован.

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

Рассмотрение приложений в Rollups

У роллапсов есть свое собственное пространство блоков, но они могут наследовать безопасность другой цепочки. Большинство роллапсов сегодня имеют единственный секвенсор, который отвечает за упорядочивание и включение транзакций, хотя транзакции могут быть отправлены непосредственно в Layer 1 через процесс, называемый “принудительное включение.”

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

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

Несмотря на то, что существует множество возможных моделей для токенов приложений, предоставление курируемых пулов ставок — это один из путей вперед, который помогает решить внешние проблемы, уникальные для приложений. Признавая внутренние и внешние проблемы, с которыми сталкиваются приложения, основатели могут лучше разрабатывать модели токенов приложений с нуля для своего проекта.

Disclaimer：

1. Эта статья перепечатана из [a16zcrypto]. Все авторские права принадлежат оригинальному автору [Мэйсон ХоллПортер СмитМайлс Дженнингс и Росс Шуэл]. Если есть возражения против данной репродукции, пожалуйста, свяжитесь с Gate Learnкоманда, и они оперативно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиатство переведенных статей запрещено.