Para tokens de infraestrutura - que correspondem a uma rede de Camada 1 (ou uma parte adjacente da pilha de computação como a Camada 2) - os modelos econômicos estão bem desenvolvidos e compreendidos, enraizados na oferta e demanda por espaço de bloco. Mas para tokens de aplicação - protocolos de contratos inteligentes que oferecem serviços em cima das blockchains que transmitem direitos em 'negócios distribuídos' - os modelos econômicos ainda estão sendo resolvidos.

Os modelos de negócio de tokens de aplicativos devem ser tão expressivos quanto seu software subjacente. Para esse fim, introduzimos fluxos de caixa para tokens de aplicativos - uma abordagem que permite que os aplicativos criem modelos permissivos e flexíveis e os usuários escolham como são recompensados pelo valor que fornecem. Esse método cria taxas a partir de atividades legítimas que atendem aos requisitos regulatórios de diferentes jurisdições, incentivando uma maior conformidade. Ele também maximiza o valor que a protocolo acumula, enquanto incentiva...minimização da governança.

Os princípios que partilhamos aqui aplicam-se a todas as aplicações web3 — desde DeFi até às aplicações sociais descentralizadas, redes DePIN e em todos os lugares intermédios.

Desafios para modelos de tokens

Os tokens de infraestrutura estão sujeitos a oferta e demanda embutidas: à medida que a demanda aumenta, a oferta diminui e os mercados se ajustam de acordo. Esta base econômica nativa para muitos tokens de infraestrutura foi acelerada pela Proposta de Melhoria do Ethereum 1559EIP-1559), que implementou uma taxa base a ser queimada para todas as transações Ethereum. Mas apesar de tentativas dispersas de modelos de compra e queima, não há paralelo ao EIP-1559 para tokens de aplicativos.

As aplicações são utilizadores, não fornecedores, do espaço de bloco, por isso não podem depender da cobrança de taxas de gás de outros que utilizam o seu espaço de bloco. É por isso que precisam desenvolver seus próprios modelos econômicos.

Há alguns desafios legais aqui também: Os modelos econômicos de token de infraestrutura são mais isolados do risco legal, devido à natureza genérica das transações típicas de blockchain e aos mecanismos programáticos que usam. Mas para modelos econômicos de token de aplicação, as aplicações envolvidas podem depender da facilitação da atividade regulada e podem exigir intermediação por detentores de tokens de governança – tornando a economia mais complicada. Uma exchange descentralizada que facilita a negociação de derivativos, uma atividade altamente regulamentada nos EUA, é radicalmente diferente de, digamos, o Ethereum.

A combinação destes desafios intrínsecos e extrínsecos significa que os tokens de aplicação requerem um modelo econômico diferente. Com isso em mente, apresentamos uma possível solução: um método para projetar protocolos que compensam os detentores de tokens de aplicação por seus serviços, ao mesmo tempo que maximizam a receita do protocolo, incentivam a conformidade regulamentar e incorporamminimização da governança. Nosso objetivo é simples: dar aos tokens de aplicativos o mesmo embasamento econômico, através de fluxos de caixa, que muitos tokens de infraestrutura já possuem.

A nossa solução centra-se na resolução de três problemas que os tokens de aplicação enfrentam relacionados com:

1. Desafios com governança
2. Desafios com a distribuição de valor
3. Desafios com atividade regulamentada

1. Desafios com governança

Os tokens de aplicação normalmente têm direitos de governança, e a presença de uma Organização Autônoma Descentralizada (DAO) pode introduzir incerteza que os tokens de infraestrutura não enfrentam. Para DAOs com operações significativas nos EUA, riscos podem surgir se a DAO tiver controle sobre a receita do protocolo ou intermediar a atividade econômica do protocolo e tornar essa atividade programática. Para evitar esses riscos, os projetos podem eliminar o controle de uma DAO minimizando a governança. Para DAOs onde isso não é possível, o novo Wyoming Associação Descentralizada sem Fins Lucrativos Não Incorporada (DUNA)forneceumaentidade legal descentralizada que pode ajudar a mitigar esses riscos e cumprir as leis fiscais aplicáveis.

2. Desafios com a distribuição de valor

As aplicações também devem ter cautela ao projetar o mecanismo que distribui valor aos detentores de tokens. Combinando votação e direitos econômicospode levantar preocupações ao abrigo das leis de valores mobiliários dos EUA, especialmente com mecanismos simples e diretos como distribuições pro rata e compras e queima de tokens. Esses mecanismos parecem semelhantes a dividendos e recompras de ações, e podem minar argumentos de que os tokens merecem um quadro regulatório diferente do patrimônio líquido.

Os projetos devem, em vez disso, explorar o capitalismo das partes interessadas - recompensando os detentores de tokens pelas contribuições ao projeto de uma maneira que beneficie o projeto. Muitos projetos incentivaram a participação de soma positiva, incluindo a operação de um frontend (Liquity), participando do protocolo (Goldfinch) e oferecendo garantias como parte de um módulo de segurança (Aave. O espaço de design aqui está completamente aberto, mas um bom ponto de partida é mapear todas as partes interessadas em um projeto, determinar quais comportamentos devem ser incentivados de cada uma delas e decidir que valor abrangente o protocolo pode criar através dessa incentivização.

Para simplificar, neste post vamos assumir um modelo de compensação simples que recompensa os detentores de tokens pela participação na governança, embora existam outros esquemas.

3. Desafios com atividade regulamentada

Aplicações que facilitam atividades regulamentadas também devem ter cuidado ao projetar mecanismos de acúmulo de valor para detentores de tokens. Se tais mecanismos acumularem valor a partir de front-ends ou APIs que não estejam operando em conformidade com a lei aplicável, os detentores de tokens poderiam estar lucrando com atividades ilícitas.

A maioria das soluções propostas para este problema tem se concentrado em limitar a acumulação de valor à atividade permitida nos EUA — por exemplo, apenas ativando taxas de protocolo em relação a pools de liquidez que envolvem certos ativos. Isso sujeita os projetos ao denominador comum mais baixo das abordagens regulatórias e mina a proposta de valor dos protocolos de software autônomo globais. Também mina diretamente os esforços de minimização de governança. Determinar qual estratégia de taxa funciona do ponto de vista da conformidade regulatória não é uma tarefa apropriada para DAOs.

Num mundo ideal, os projetos seriam capazes de cobrar taxas de atividades em qualquer jurisdição em que essa atividade seja permitida, sem depender de DAOs para determinar o que é permitido. O soluçãonão é exigir conformidade regulatória ao nível do protocolo, mas garantir que as taxas geradas pelo protocolo sejam repassadas apenas se a interface ou API que as originou estiver seguindo as leis e regulamentos aplicáveis ​​onde a interface está localizada. Se os EUA tornarem ilegal a cobrança de taxas em determinado tipo de transação facilitada por um aplicativo, isso poderia levar o valor econômico do token desse aplicativo a zero, mesmo que a atividade seja totalmente permitida em todos os outros países do mundo. A flexibilidade quando se trata de acúmulo e distribuição de taxas equivale, em última análise, à resiliência diante das pressões regulatórias.

Uma questão central: Rastreando taxas

A rastreabilidade das taxas é fundamental para resolver os potenciais riscos decorrentes de interfaces não conformes sem introduzir riscos de censura ou tornar um protocolo com permissão. Com a rastreabilidade, um aplicativo pode garantir que quaisquer taxas que se acumulem para os detentores de tokens provenham apenas de interfaces que estejam em conformidade legal na jurisdição do detentor do token. Se as taxas forem inrastreáveis, não haverá maneira de isolar os detentores de tokens de acumular valor de interfaces não conformes (ou seja, taxas coletadas por interfaces não conformes), o que poderia expor os detentores de tokens a riscos.

Para tornar as taxas rastreáveis, um protocolo poderia usar um design de sistema de apostas de token de aplicativo em dois passos.

Passo 1: identificar qual frontend originou as taxas e

Passo 2: encaminhando as taxas para diferentes pools com base em uma lógica personalizada.

Mapeamento de frontends

A rastreabilidade das taxas requer uma correspondência um para um de um domínio para um par de chaves pública/privada. Sem essa correspondência, uma interface de usuário mal-intencionada poderia falsificar transações e fingir que elas foram enviadas de um domínio honesto. A criptografia nos permite "registrar" interfaces de usuário, registrando de forma imutável a correspondência do domínio com a chave pública, provando que o domínio realmente controla essa chave pública e assinando transações com a respectiva chave privada. Isso nos dá a capacidade de atribuir transações e, portanto, taxas, a um determinado domínio.

Taxas de roteamento

Uma vez que a origem das taxas seja rastreável, o protocolo pode determinar como distribuir essas taxas de forma a isolar os detentores de tokens de receber taxas de transações ilícitas, mas também não aumentar as obrigações de governança descentralizada da DAO. Para ajudar a ilustrar esse ponto, pense no espectro de possíveis projetos para o staking de tokens do aplicativo, variando de uma piscina de staking para cada frontend a uma piscina de staking para todos os frontends.

Na sua construção mais simples, as taxas de cada frontend poderiam ser encaminhadas para um módulo de staking específico do frontend. Ao selecionar quais frontends apostar, um detentor de tokens poderia decidir quais taxas está recebendo e evitar quaisquer taxas que coloquem o detentor de tokens em perigo legal. Por exemplo, um detentor de tokens poderia apenas apostar no módulo associado a um frontend que tenha recebido todas as aprovações regulatórias na Europa. Embora esse design pareça simples, na verdade é bastante complicado. Poderia haver 50 pools de staking para 50 frontends diferentes, e a diluição das taxas poderia ser prejudicial ao valor do token.

No extremo oposto do espectro, as taxas de cada interface poderiam ser agrupadas - mas isso vai contra o propósito da rastreabilidade das taxas. Se todas as taxas forem agrupadas, não há como diferenciar as taxas das interfaces compatíveis das não compatíveis - uma maçã podre estragaria o barril. Os detentores de tokens seriam obrigados a escolher entre não receber nenhuma taxa ou participar de um pool, onde se beneficiariam das atividades ilegais das interfaces não compatíveis em sua jurisdição - uma opção que poderia dissuadir muitos detentores de tokens de participar ou poderia reverter o sistema para designs subótimos atuais, onde um DAO tem que avaliar onde as taxas podem ser aplicadas.

Abordando a rastreabilidade de taxa por meio de curadoria

Essas complexidades podem ser resolvidas através da curadoria. Considere uma aplicação de protocolo de contrato inteligente sem permissão que possui uma taxa e um token. Qualquer pessoa pode criar uma interface para a aplicação e qualquer interface pode ter seu próprio módulo de staking. Vamos chamar uma interface para este protocolo de app.xyz.

App.xyz poderia seguir regras de conformidade específicas para a jurisdição em que está localizada. A atividade do aplicativo que se originou de app.xyz gera taxas de protocolo. App.xyz possui seu próprio módulo de stake e os detentores de tokens podem apostar seus tokens diretamente nesse módulo ou em um curador que queira selecionar individualmente um conjunto de frontends que considerem conformes. Esses apostadores de tokens ganhariam rendimentos na forma de taxas do conjunto de frontends em que apostam. Se um frontend gera $100 em taxas e 100 entidades estão apostando 1 token cada, então cada entidade tem direito a $1. Curadores podem cobrar inicialmente uma taxa por seus serviços. No futuro, os governos podem fazer atestações onchain sobre frontends que estejam em conformidade em sua jurisdição para ajudar a proteger os consumidores, com o benefício adicional sendo a automação da curadoria.

Um risco potencial neste modelo é que os frontends não conformes poderiam ser mais baratos de operar porque não possuem o custo administrativo dos frontends conformes. Eles também poderiam criar modelos para reciclar as taxas de frontend para os traders, a fim de incentivar ainda mais suas soluções alternativas. Dois fatores mitiGate este risco. Primeiro, a maioria dos utilizadores realmente quer frontends conformes para seguir as leis e regulamentos locais. Isto aplica-se especialmente a grandes instituições regulamentadas. Em segundo lugar, a governança poderia desempenhar um papel vital como último recurso ou “autoridade de veto” sobre os frontends não conformes que quebrem repetidamente as regras e ponham em perigo a viabilidade da aplicação, desencorajando comportamentos inadequados.

Finalmente, todas as taxas das transações que não são iniciadas através de um frontend registado seriam depositadas num único módulo de staking geral, permitindo ao protocolo capturar receitas das transações iniciadas por bots e outras interações diretas com os contratos inteligentes do protocolo.

Da teoria à implementação: Colocando o método em prática

Vamos revisitar a pilha de tokens de aplicativo com mais detalhes. Para um protocolo facilitar o staking de frontend, ele precisaria estabelecer um contrato inteligente de registro com o qual os frontends precisariam se registrar.

1. Cada frontend ou API pode adicionar um registro TXT especial ao registro DNS de seu domínio, como o Integração ENS DNS. Este registro TXT contém a chave pública de um par de chaves que o frontend gera uma vez, chamado o certificado.

1. O cliente da interface pode, então, chamar a função register() e provar que possui o seu nome de domínio. Um mapeamento do domínio para a chave pública do certificado, e vice-versa, é armazenado.
2. Quando as transações são criadas através do cliente, ele também assina a carga útil da transação com sua chave pública de certificado. Estes são passados para os smart contracts da aplicação em um pacote.
3. Os contratos inteligentes do aplicativo validam o certificado, verificam se ele corresponde ao corpo correto da transação e se foi registrado. Se sim, a transação é processada. As taxas geradas pela transação são então enviadas para um contrato de Coletor de Taxas juntamente com o nome de domínio (do registro).
4. O FeeCollector permite que curadores, utilizadores, validadores e outros, apostem tokens diretamente num domínio ou num conjunto de domínios. Estes contratos devem manter o registo da quantidade de tokens apostados em cada domínio, a quota de cada endereço nessa aposta e o tempo durante o qual estiveram apostados. Implementações populares de mineração de liquidez podem ser usadas como ponto de partida para esta lógica de contrato.
5. Os usuários que apostaram em curadores (ou diretamente nos contratos de Gerenciamento de Taxas) podem então retirar a parcela proporcional da taxa de acordo com a quantidade de token do aplicativo apostado no domínio. A arquitetura pode ser semelhante a MetaMorpho/Azul Morpho.

Isso pode ser introduzido sem aumentar a carga de governança do DAO de um aplicativo. Na verdade, as responsabilidades de governança podem ser reduzidas, já que a chave de taxa pode ser ativada permanentemente para todas as transações facilitadas pelo protocolo, removendo assim qualquer controle do DAO sobre o modelo econômico do protocolo.

Considerações adicionais com base no tipo de aplicação

Embora esses princípios se apliquem amplamente aos modelos econômicos de tokens de aplicativos, pode haver outras considerações de taxas com base no tipo de aplicativo: aplicativos construídos em Layer 1s ou Layer 2s, app-chains e aplicativos construídos usando rollups.

Considerações para aplicações L1/ L2

Aplicações em blockchains de Camada 1 ou Camada 2 têm contratos inteligentes implantados diretamente onchain. As taxas seriam cobradas quando os usuários interagem com os contratos inteligentes das aplicações. Normalmente, isso ocorre através de um frontend fácil de usar (como um aplicativo ou site) que serve como uma interface entre um usuário comum e os contratos inteligentes subjacentes. Nesse caso, quaisquer taxas teriam origem nesse frontend. O exemplo acima sobre app.xyz ilustra como um sistema de taxas poderia funcionar para um aplicativo de Camada 1.

Em vez de depender de curadores para filtrar as taxas de interface, os aplicativos também poderiam adotar uma abordagem de lista branca ou lista negra para as interfaces que contribuem para as taxas de rede. Novamente, o objetivo aqui seria garantir que os detentores de tokens e o protocolo em geral não estejam lucrando ou se beneficiando de atividades ilícitas e estejam seguindo as leis e regulamentos específicos da jurisdição.

Na abordagem da lista de permissões, o aplicativo publicaria um conjunto de regras para as interfaces, criaria um registro das interfaces que seguem as regras, emitiria um certificado para as interfaces que optarem por participar e exigiria que as interfaces apostassem tokens para receber uma parte das taxas do aplicativo. Se as interfaces não seguissem essas regras, elas seriam penalizadas e seu certificado de contribuições de taxas seria removido.

Na abordagem da lista negra, os aplicativos não precisariam criar regras, mas o lançamento de uma interface para o aplicativo não seria sem permissão. Em vez disso, o aplicativo exigiria que qualquer interface entregasse uma opinião de um escritório de advocacia de que a interface está em conformidade com sua jurisdição antes de permitir que a interface use o aplicativo. Uma vez recebida a opinião, o aplicativo emitiria um certificado para a interface para contribuições de taxa que só seriam removidas se o aplicativo receber um aviso de um regulador de que a interface não está em conformidade.

O pipeline de taxas refletiria os exemplos fornecidos nas seções anteriores.

Ambos esses enfoques aumentam significativamente o fardo da governança descentralizada, exigindo que as DAOs estabeleçam e mantenham um conjunto de regras ou avaliem pareceres legais sobre conformidade. Em alguns casos, isso pode ser aceitável, mas na maioria das vezes, a terceirização desse fardo de conformidade para um curador seria preferível.

Considerações para appchains

As Appchains são blockchains específicas de aplicativos com validadores que funcionam apenas para esse aplicativo.

Em troca do seu trabalho, esses validadores recebem pagamento. Ao contrário das blockchains de Camada 1, onde os validadores são frequentemente recompensados através da emissão inflacionária de tokens, algumas appchains (dYdX) repassam as taxas dos clientes para os validadores.

Neste modelo, os detentores de tokens devem apostar nos validadores para receber recompensas. Os validadores tornam-se os módulos de aposta selecionados.

Este conjunto de trabalho é diferente de um validador da Camada 1. Os validadores do Appchain liquidam transações específicas de uma aplicação específica. Devido a essa diferença, os validadores do Appchain podem ter um maior grau de risco legal em relação à atividade subjacente que estão facilitando. Como resultado, os protocolos devem conceder aos validadores a liberdade de realizar o trabalho que podem realizar de acordo com as leis de sua jurisdição e seu próprio nível de conforto. Importante, isso pode ser feito sem comprometer a permissão do Appchain ou sujeitá-lo a um risco significativo de censura, desde que seu conjunto de validadores seja descentralizado geograficamente.

A arquitetura para appchains que desejam aproveitar os benefícios da rastreabilidade de taxas seria semelhante às aplicações da Camada 1 até o pipeline de taxas. No entanto, os validadores seriam capazes de usar o mapeamento de frontend para determinar de quais frontends desejam processar transações. As taxas para qualquer transação específica iriam para o conjunto ativo de validadores, com validadores inativos que optaram por não participar perdendo essas taxas. Do ponto de vista das taxas, o validador desempenha a mesma função que os curadores do módulo de apostas discutidos acima, e os apostadores desses validadores podem garantir que não estejam recebendo receita de qualquer atividade ilícita. Os validadores também poderiam eleger um curador para determinar quais frontends estão em conformidade com a jurisdição.

Considerações para rollups de aplicação

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 que é responsável por sequenciar e incluir transações, embora as transações possam ser enviadas diretamente para a Camada 1 através de um processo chamado "forced-inclusão.”

Se estes rollups forem específicos da aplicação e consagrarem o seu sequenciador como o único validador, as taxas geradas a partir das transações incluídas por esse sequenciador podem ser dispersas para os stakers com base no conjunto selecionado de frontends compatíveis ou como um pool geral.

Se os rollups descentralizarem seu conjunto de sequenciadores, os sequenciadores se tornarão os módulos de staking com curadoria de fato e o pipeline de taxas refletiria o de appchains. Os sequenciadores substituem os validadores para a distribuição de taxas, e cada sequenciador pode tomar suas próprias decisões sobre quais frontends aceitar taxas.

Embora haja muitos modelos possíveis para tokens de aplicação, fornecer pools de participação selecionadas é um caminho a seguir que ajuda a superar os desafios extrínsecos únicos das aplicações. Ao reconhecer os desafios intrínsecos e extrínsecos enfrentados pelas apps, os fundadores podem projetar melhor os modelos de token de aplicação desde o início para o seu projeto.

Aviso Legal:

1. Este artigo é reproduzido de [a16zcrypto]. Todos os direitos autorais pertencem ao autor original [Mason HallPorter SmithMiles Jennings and Ross Shuel]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.