Autor: a16z

Compilado por: Félix, PANews

Para tokens de infraestrutura (como L1 ou L2), o modelo económico foi totalmente desenvolvido e compreendido, enraizado na oferta e procura de espaço em bloco. Mas para os tokens de aplicação (protocolos de contratos inteligentes que implementam serviços na blockchain), o modelo económico ainda está a ser refinado.

O modelo de negócios de um token de aplicação deve ser tão expressivo quanto o software subjacente. Para tanto, este artigo apresenta o conceito de fluxo de caixa dos tokens de aplicação. Essa abordagem permite que os aplicativos criem modelos flexíveis e flexíveis onde os usuários podem escolher como serão recompensados ​​pelo valor que fornecem. Esta abordagem incentiva uma maior conformidade ao incorrer em taxas por atividades legítimas sujeitas a requisitos regulamentares em diferentes jurisdições. Além disso, o valor do protocolo pode ser maximizado ao mesmo tempo que se incentiva uma governação mínima.

Os princípios compartilhados neste artigo se aplicam a todos os aplicativos Web3 – desde DeFi até aplicativos sociais descentralizados, redes DePIN e tudo mais.

Desafios enfrentados pelo modelo de token

Os tokens de infraestrutura estão sujeitos à oferta e à demanda inerentes: à medida que a demanda aumenta, a oferta diminui e o mercado se ajusta de acordo. Esta base econômica nativa para muitos tokens de infraestrutura é acelerada pela Proposta de Melhoria Ethereum 1559 (EIP-1559), que implementa um mecanismo de queima para todas as transações Ethereum. Embora existam tentativas esporádicas de compra e queima de modelos, não existe um modelo semelhante ao EIP-1559 para tokens de aplicação.

Os aplicativos são usuários do espaço de bloco, não provedores, portanto, não podem contar com o recebimento de taxas de gás de terceiros que usam seu espaço de bloco. É por isso que precisam de desenvolver o seu próprio modelo económico.

Existem também alguns desafios jurídicos aqui: devido à natureza genérica das transações típicas de blockchain e aos mecanismos de programação que utilizam, os modelos económicos de tokens de infraestrutura são menos suscetíveis a riscos jurídicos. Mas para modelos económicos de tokens de aplicação, as aplicações envolvidas podem depender de atividades regulatórias e podem exigir intermediários para governar os detentores de tokens – tornando a economia mais complexa. Por exemplo, uma bolsa descentralizada que facilita a negociação de derivados (uma actividade altamente regulamentada nos Estados Unidos) é completamente diferente de, digamos, Ethereum.

Estes desafios internos e externos significam que os tokens de aplicação requerem modelos económicos diferentes. Com isso em mente, este artigo propõe uma solução possível: uma maneira de projetar protocolos que compensem os detentores de tokens de aplicação e, ao mesmo tempo, maximizem a receita do protocolo, incentivem a conformidade regulatória e incorporem serviços de minimização de governança. O objetivo é simples: fornecer aos tokens de aplicação a mesma base econômica por meio do fluxo de caixa que muitos tokens de infraestrutura já possuem.

A solução se concentra em resolver três problemas enfrentados pelos tokens de aplicação:

  • Desafios de governança

  • Desafio de distribuição de valor

  • desafios regulatórios

Desafios de governança

Os tokens de aplicação geralmente têm direitos de governança, e a existência de um DAO pode trazer incertezas que os tokens de infraestrutura não enfrentam. Para DAOs com operações significativas nos Estados Unidos, podem surgir riscos se o DAO controlar as receitas do protocolo ou atuar como intermediário para atividades econômicas do protocolo e programar tais atividades. Para evitar estes riscos, os projetos podem eliminar o controlo do DAO minimizando a governação. Para os DAOs incapazes de fazer isso, a recém-formada Associação Descentralizada Não Incorporada sem Fins Lucrativos (DUNA) do Wyoming fornece uma entidade legal descentralizada que pode ajudar a mitigar esses riscos e cumprir as leis fiscais aplicáveis.

Desafio de distribuição de valor

Os aplicativos devem projetar cuidadosamente mecanismos para distribuir valor aos detentores de tokens. A combinação de direitos económicos e de voto pode suscitar preocupações ao abrigo das leis de valores mobiliários dos EUA, especialmente mecanismos simples e diretos, como o rateio e a compra e queima de tokens. Estes mecanismos são semelhantes aos dividendos e às recompras de ações e podem minar os argumentos de que os tokens deveriam estar sujeitos a um quadro regulamentar diferente do das ações.

Os projetos devem explorar modelos de partes interessadas – recompensando os detentores de tokens pelas suas contribuições de uma forma que beneficie o projeto. Muitos projetos estão incentivando a participação ativa, incluindo frontends operacionais (Liquity), participação em protocolos (Pintassilgo) e garantia de garantia como parte de módulos de segurança (como Aave). O espaço de design aqui é aberto, mas um bom ponto de partida é mapear todos os intervenientes no projeto, determinar quais os comportamentos que cada um deles deve ser encorajado a adotar e decidir que valor global o protocolo pode criar através deste incentivo.

Para simplificar, este artigo assumirá um modelo de remuneração simples que recompensa os detentores de tokens por participarem da governança.

desafios regulatórios

As aplicações que facilitam atividades regulamentadas também devem ser cautelosas ao projetar mecanismos de agregação de valor para detentores de tokens. Se tais mecanismos obtiverem valor de um front-end ou API que não cumpra as leis aplicáveis, os detentores de tokens poderão lucrar com atividades ilegais.

A maioria das soluções propostas para este problema centra-se na limitação da adição de valor às actividades permitidas nos Estados Unidos – por exemplo, cobrando taxas de protocolo apenas para conjuntos de liquidez que envolvam determinados activos. Isto submete os projetos a abordagens regulatórias e prejudica a proposta de valor dos protocolos globais de software autônomo. Também prejudica directamente os esforços para minimizar a governação. Não é apropriado que um DAO determine qual estratégia de taxas é eficaz do ponto de vista da conformidade regulatória.

Num mundo ideal, os projetos seriam capazes de cobrar taxas em qualquer jurisdição que permita tal atividade sem ter que depender de um DAO para determinar o que é permitido. A solução não é exigir conformidade no nível do protocolo, mas garantir que as taxas incorridas por um protocolo só sejam repassadas se o front-end ou API que gera essas taxas estiver em conformidade com as leis e regulamentos aplicáveis ​​na região onde o front-end está localizado. Se os Estados Unidos proibirem taxas para uma determinada transação facilitada por um aplicativo, isso poderá reduzir o valor econômico do token do aplicativo a zero, mesmo que tal atividade seja permitida em outros países ao redor do mundo. A flexibilidade na acumulação e atribuição de taxas equivale, em última análise, à resiliência face às pressões regulamentares.

Uma questão central: taxas retroativas

A rastreabilidade das taxas é fundamental para abordar os riscos potenciais decorrentes do incumprimento inicial, sem introduzir risco de escrutínio ou licenciamento do acordo. Com a rastreabilidade, os aplicativos podem garantir que quaisquer taxas que os detentores de tokens recebam venham apenas de front-ends legais e compatíveis dentro da jurisdição do detentor do token. Se as taxas não forem rastreáveis, não há como proteger os detentores de tokens da acumulação de valor num front-end não conforme, o que poderia colocar em risco os detentores de tokens.

Para tornar as despesas rastreáveis, os protocolos podem ser elaborados em duas etapas:

  • Etapa 1: identificar quais custos de front-end incorreram

  • Etapa 2: rotear taxas para diferentes pools com base na lógica personalizada

Interface de mapeamento

A rastreabilidade das taxas requer um mapeamento individual de domínios para pares de chaves públicas/privadas. Sem esse mapeamento, um front-end malicioso poderia falsificar transações e fingir ser enviado de um domínio honesto. A criptografia permite que um frontend "registrado" registre imutavelmente um mapeamento de domínio para chave pública, prove que o domínio realmente controla essa chave pública e use a referida chave privada para assinar transações. Isto permite-nos atribuir transações (e, portanto, taxas) a um determinado domínio.

Taxas de roteamento

Uma vez rastreável a fonte das taxas, o protocolo pode determinar como distribuir essas taxas para que os detentores de tokens não sejam cobrados por transações ilegais e não aumentem a carga de governança descentralizada do DAO. Para ajudar a ilustrar isso, podemos considerar vários designs possíveis para a aplicação de piquetagem de token, desde um pool de piquetagem por frontend até um pool de piquetagem único compartilhado por todos os frontends.

Em sua configuração mais simples, as taxas de cada frontend podem ser roteadas para um módulo de piquetagem separado específico do frontend. Ao escolher em qual interface apostar, os detentores de tokens poderão decidir quais taxas cobrar e evitar quaisquer taxas que os coloquem em risco legal. Por exemplo, os detentores de tokens podem apostar apenas em módulos relacionados com front-ends que tenham sido aprovados por todas as autoridades reguladoras na Europa. Embora esse design pareça simples, na verdade é bastante complexo. Com 50 frontends diferentes tendo potencialmente 50 pools de staking, a diluição das taxas pode afetar negativamente o valor do token.

Por outro lado, as taxas para cada front-end podem ser agrupadas – mas isso vai contra o propósito da rastreabilidade das taxas. Se todos os custos forem agrupados, não há como diferenciar entre os custos de um front-end compatível e de um front-end não conforme. Os detentores de tokens serão forçados a escolher entre não cobrar quaisquer taxas e manter uma participação em um pool onde se beneficiarão das atividades ilegais de front-ends não conformes em sua jurisdição — — Esta opção pode impedir a participação de muitos detentores de tokens, ou poderia reverter o sistema ao seu atual design abaixo do ideal, onde o DAO precisa avaliar onde as taxas podem ser aplicadas.

Resolva problemas de rastreabilidade de despesas por meio do gerenciamento

Essas complexidades podem ser abordadas por meio do gerenciamento. Considere um aplicativo de protocolo de contrato inteligente sem permissão com taxas e tokens, qualquer pessoa pode criar um frontend para o aplicativo e qualquer frontend pode ter seu próprio módulo de piquetagem, um frontend para este protocolo é chamado App.xyz.

App.xyz pode seguir regras de conformidade específicas nas jurisdições em que está localizado. A atividade do aplicativo originada de app.xyz incorre em cobranças de protocolo. App.xyz tem seu próprio módulo de piquetagem, no qual os detentores de tokens podem apostar seus tokens diretamente ou para gerentes que desejam fazer a curadoria individual de uma cesta de front-ends que consideram compatíveis. Esses tokens stakers receberão benefícios na forma de taxas do conjunto de frontends que apostam. Se um frontend gerar US$ 100 em taxas e 100 entidades apostarem 1 token cada, cada entidade terá direito a US$ 1. O administrador pode inicialmente cobrar uma taxa de serviço. No futuro, os governos poderão certificar a conformidade inicial nas suas jurisdições em cadeia para ajudar a proteger os consumidores, com o benefício secundário de automatizar a administração.

Um risco potencial deste modelo é que os front-ends não conformes podem ter custos operacionais mais baixos porque não têm a sobrecarga administrativa dos front-ends compatíveis. Eles também podem projetar modelos para recuperar taxas iniciais para os comerciantes. Dois fatores atenuam esse risco. Primeiro, a maioria dos usuários realmente deseja um front-end de conformidade para cumprir as leis e regulamentações locais, especialmente para grandes instituições regulamentadas. Em segundo lugar, para front-ends não conformes que violam repetidamente as regras e colocam em risco a viabilidade da aplicação, a governação pode servir como último recurso ou exercer “poder de veto” para dissuadir o mau comportamento.

Finalmente, todas as taxas de transação não iniciadas através do frontend registrado serão depositadas em um único módulo de staking abrangente, permitindo que o protocolo gere receita a partir de transações iniciadas por bot e outras interações diretas com os contratos inteligentes do protocolo.

Da teoria à implementação: colocando métodos em prática

Uma revisão detalhada da pilha de tokens do aplicativo. Para que um protocolo facilite o staking front-end, é necessário o estabelecimento de um contrato inteligente de registro que o front-end precisa registrar.

Cada front-end ou API pode adicionar registros TXT especiais aos registros DNS de seu domínio, como a integração DNS do ENS. Este registro TXT contém a chave pública do par de chaves gerado uma vez pelo front end, denominado certificado.

O cliente front-end pode então chamar a função Register() e provar que possui seu nome de domínio. O sistema armazena o mapeamento de domínios para certificar chaves públicas e vice-versa.

Quando uma transação é criada através do cliente, ele também assina a carga útil da transação usando sua chave pública de certificado. Eles serão repassados ​​ao contrato inteligente do aplicativo na forma de um pacote.

O contrato inteligente do aplicativo verifica o certificado, verifica se ele corresponde ao principal tx correto e está registrado. Nesse caso, a transação é processada. As taxas geradas pela transação são então enviadas para o contrato FeeCollector junto com o nome de domínio (do registro).

FeeCollector permite que gerentes, usuários, validadores, etc. apostem tokens diretamente em um único domínio ou conjunto de domínios. Esses contratos devem rastrear o número de tokens apostados em cada domínio, a parcela apostada de cada endereço e a duração da aposta. Implementações populares de mineração de liquidez podem ser usadas como ponto de partida para esta lógica de contrato.

Os usuários que apostaram no administrador (ou diretamente no próprio contrato de gerenciamento de taxas) podem sacar uma parcela proporcional das taxas com base no número de tokens de aplicação prometidos ao domínio. A arquitetura pode ser semelhante à MetaMorpho/Morpho Blue.

A introdução desse recurso não aumentará a carga de governança do aplicativo DAO. Na verdade, as responsabilidades de governação podem ser reduzidas porque a mudança de taxas pode ser permanentemente activada para todas as transacções facilitadas pelo protocolo, eliminando assim qualquer controlo que o DAO tenha sobre o modelo económico do protocolo.

Considerações adicionais com base no tipo de aplicativo

Embora esses princípios se apliquem amplamente aos modelos econômicos de tokens de aplicativos, há outras taxas que podem ser consideradas dependendo do tipo de aplicação: aplicações construídas dentro ou fora de L2, cadeias de aplicações e aplicações construídas usando rollups.

Aplicações L1/L2

As aplicações na blockchain L1/L2 implantam contratos inteligentes diretamente na cadeia. As taxas são cobradas quando os usuários interagem com o contrato inteligente do aplicativo. Normalmente, isso acontece por meio de um front-end fácil de usar (como um aplicativo ou site) que atua como uma interface entre os investidores de varejo e o contrato inteligente subjacente. Nesse caso, quaisquer cobranças serão originadas desse front-end. O exemplo acima em app.xyz ilustra como funciona o sistema de taxas para aplicativos L1.

Além de depender de gerentes para filtrar as cobranças de front-end, os aplicativos também podem empregar uma abordagem de lista branca ou de lista negra para filtrar front-ends que aumentam as tarifas de rede. Novamente, o objetivo aqui é garantir que os detentores de tokens e todo o protocolo não lucrem com atividades ilegais e cumpram as leis e regulamentos da jurisdição específica.

Na abordagem de lista de permissões, o aplicativo publicará um conjunto de regras para front-ends, criará um registro de front-ends que cumpram as regras, emitirá certificados para front-ends que aceitarem e exigirá que os front-ends façam stake de tokens para receber uma parte de as taxas de inscrição. Se um front-end não cumprir as regras, ele será cortado e seu certificado de contribuição será removido.

Na abordagem de lista negra, o aplicativo não precisa criar nenhuma regra, mas o lançamento do front-end do aplicativo não ocorre sem permissão. Em vez disso, o aplicativo exigirá que qualquer front-end forneça uma opinião de um escritório de advocacia certificando que o front-end está em conformidade com sua jurisdição antes de permitir que o front-end use o aplicativo. Assim que os comentários forem recebidos, a aplicação emitirá um certificado de contribuição de taxa para o frontend, que só será removido se a aplicação receber notificação do regulador de que o frontend não está em conformidade.

O canal de despesas é semelhante aos exemplos fornecidos nas seções anteriores.

Ambas as abordagens aumentam significativamente o fardo da governação descentralizada, exigindo que o DAO estabeleça e mantenha um conjunto de regras ou avalie pareceres jurídicos relativamente ao cumprimento. Em alguns casos isto pode ser aceitável, mas na maioria dos casos é melhor subcontratar esta carga de conformidade aos gestores.

cadeia de aplicativos

Uma cadeia de aplicativos é um blockchain específico de um aplicativo cujos validadores são específicos para esse aplicativo.

Em troca do seu trabalho, esses validadores recebem uma remuneração. Ao contrário dos blockchains L1, onde os validadores são normalmente recompensados ​​através da inflação pela emissão de tokens, algumas cadeias de aplicativos (dYdX) repassam taxas de clientes aos validadores.

Neste modelo, os detentores de tokens devem apostar em validadores para receber recompensas. Os validadores tornam-se módulos de staking com curadoria.

Este conjunto de trabalho é diferente do verificador L1. Os validadores da cadeia de aplicativos processam transações específicas de aplicativos específicos. Devido a esta diferença, os validadores Lisk podem assumir um maior grau de risco legal relacionado com as atividades subjacentes que facilitam. Portanto, o protocolo deve conceder aos validadores a liberdade de realizar o trabalho que podem realizar de acordo com as leis da sua jurisdição e com a sua própria vontade. É importante ressaltar que isso pode ser feito sem comprometer a natureza sem permissão do blockchain ou expô-lo a um risco significativo de censura, desde que seu conjunto de validadores esteja geograficamente disperso.

A arquitetura das cadeias de aplicações que desejam aproveitar a rastreabilidade de despesas será semelhante à das aplicações L1. Mas os validadores poderão usar o mapeamento de frontend para determinar de qual frontend eles desejam que as transações sejam processadas. As taxas para qualquer transação irão para o conjunto de validadores ativos, enquanto os validadores inativos que optarem por não participar perderão tais taxas. Do ponto de vista das taxas, os validadores desempenham as mesmas funções que os gestores de módulos de staking discutidos acima, e os stakers destes validadores têm a garantia de que não recebem rendimentos de qualquer atividade ilegal. Os validadores também podem eleger um administrador para determinar quais front-ends estão em conformidade em cada jurisdição.

Rollups

Os rollups têm seu próprio espaço de bloco, mas podem herdar a segurança de outra cadeia. A maioria dos Rollups hoje tem um único sequenciador. Se esses Rollups forem específicos da aplicação e tiverem seu ordenante como único validador, as taxas geradas pelas transações incluídas nesse ordenante poderão ser distribuídas aos stakers com base em um conjunto selecionado de front-ends compatíveis ou como um pool geral.

Se o Rollups descentralizar seu conjunto de ordenadores, os ordenadores se tornarão os módulos de piquetagem de fato apresentados e os canais de cobrança serão os mesmos da cadeia de aplicativos. Os solicitantes substituem os validadores para distribuição de taxas, e cada solicitante pode decidir por si mesmo de qual frontend aceitar taxas.

Embora existam muitos modelos possíveis para tokens de aplicativos, fornecer pools de piquetagem selecionados pode ajudar a enfrentar desafios externos exclusivos dos aplicativos. Ao reconhecer os desafios internos e externos enfrentados pelos aplicativos, os fundadores podem projetar melhor modelos de tokens de aplicativos para seus projetos desde o início.

Leitura relacionada: Entrevista exclusiva com pesquisador 1kx: A maneira correta de abrir o design do token Web3