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 aplicativos — protocolos de contratos inteligentes que implantam 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ócios de tokens de aplicativos devem ser tão expressivos quanto seu software subjacente. Para esse fim, apresentamos fluxos de caixa para tokens de aplicativos - uma abordagem que permite que aplicativos criem modelos permissivos e flexíveis e que os usuários escolham como são recompensados pelo valor que fornecem. Esse método cria taxas a partir de atividades legítimas de acordo com os requisitos regulatórios de diferentes jurisdições, incentivando maior conformidade. Também maximiza o valor que se acumula no protocolo enquanto incentiva...minimização de governança.

Os princípios que compartilhamos aqui se aplicam a todas as aplicações web3 - desde DeFi até aplicativos sociais descentralizados, redes DePIN e em todos os lugares entre eles.

Desafios para modelos de token

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 adequadamente. Essa base econômica nativa para muitos tokens de infraestrutura foi acelerada pela Proposta de Melhoria Ethereum 1559 (EIP-1559), que implementou uma taxa base a ser queimada para todas as transações Ethereum. Mas, apesar das tentativas dispersas de modelos de compra e queima, não há paralelo com o EIP-1559 para tokens de aplicativos.

As aplicações são usuários, e não provedores, de espaço em bloco, portanto, não podem contar com a coleta de taxas de gás de outros que usam seu espaço em bloco. É por isso que precisam desenvolver seus próprios modelos econômicos.

Há também alguns desafios legais aqui: os modelos econômicos de tokens de infraestrutura estão mais protegidos do risco legal, devido à natureza genérica das transações típicas de blockchain e aos mecanismos programáticos que utilizam. Mas para modelos econômicos de tokens de aplicativos, os aplicativos envolvidos podem depender da facilitação de atividades regulamentadas e podem exigir a intermediação pelos 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, por exemplo, do Ethereum.

A combinação desses desafios intrínsecos e extrínsecos significa que os tokens de aplicativos exigem um modelo econômico diferente. Com isso em mente, apresentamos uma possível solução: um método para projetar protocolos que compensem os detentores de tokens de aplicativos por seus serviços, ao mesmo tempo que maximizam a receita do protocolo, incentivam a conformidade regulatória e incorporamminimização da governança. Nosso objetivo é simples: dar aos tokens de aplicativos a mesma base econômica, por meio de fluxos de caixa, que muitos tokens de infraestrutura já possuem.

Nossa solução se concentra em resolver três problemas que os tokens de aplicativos enfrentam em relação a:

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 geralmente possuem direitos de governança e a presença de uma Organização Autônoma Descentralizada (DAO) pode introduzirincertezaque tokens de infraestrutura não enfrentam. Para DAOs com operações significativas nos EUA, os 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 que uma DAO tem ao minimizar a governança. Para DAOs onde isso não é possível, o novo Associação Descentralizada sem Fins Lucrativos (DUNA)forneceumentidade jurídica 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 direitos de voto e econômicospode levantar preocupações sob as leis de valores mobiliários dos EUA, especialmente com mecanismos simples e diretos como distribuições proporcionais e compra e queima de tokens. Esses mecanismos se assemelham a dividendos e recompras de ações e podem minar os argumentos de que os tokens merecem um arcabouço regulatório diferente do patrimônio.

Os projetos devem, em vez disso, explorar o capitalismo das partes interessadas - recompensando os detentores de tokens por contribuições ao projeto de uma maneira que beneficie o projeto. Muitos projetos incentivaram a participação positiva, incluindo a operação de um frontend (Liquity) participando do protocolo ( Pintassilgo), e oferecendo garantias como parte de um módulo de segurança (AAVE. O espaço de design aqui está totalmente aberto, mas um bom lugar para começar é mapear todos os intervenientes em um projeto, determinar quais comportamentos devem ser incentivados de cada um deles e decidir que valor abrangente o protocolo pode criar através dessa incentivação.

Por uma questão de simplicidade, 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

Aplicativos que facilitam atividades regulamentadas também devem ter cuidado ao projetar mecanismos de acumulação de valor para detentores de tokens. Se tais mecanismos acumulam valor a partir de frontends ou APIs que não estão operando em conformidade com a lei aplicável, os detentores de tokens podem lucrar com atividades ilícitas.

A maioria das soluções propostas para este problema tem se concentrado em limitar a acumulação de valor à atividade que é permitida nos EUA - por exemplo, apenas ativando taxas de protocolo em relação a pools de liquidez envolvendo 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ônomos 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.

Em um mundo ideal, os projetos seriam capazes de coletar taxas de atividades em qualquer jurisdição onde essa atividade é permitida, sem depender de DAOs para determinar o que é permitido. soluçãonão é exigir conformidade regulatória no 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 estiver localizada. Se os EUA tornarem ilegal a cobrança de taxas em um determinado tipo de transação facilitada por um aplicativo, isso poderia zerar o valor econômico do token desse aplicativo, mesmo que a atividade fosse totalmente permitida em todos os outros países do mundo. A flexibilidade quanto à acumulação e distribuição de taxas equivale, em última análise, à resiliência diante das pressões regulatórias.

Uma questão central: Rastreamento de taxas

A rastreabilidade das taxas é fundamental para resolver os riscos potenciais decorrentes de interfaces não conformes sem introduzir riscos de censura ou tornar o protocolo com permissões. Com a rastreabilidade, um aplicativo poderia garantir que quaisquer taxas que se acumulem aos detentores de tokens venham apenas de interfaces que estejam em conformidade legal na jurisdição do detentor de tokens. Se as taxas forem inrastreáveis, não haverá como 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 estaca de token de aplicativo de duas etapas.

Etapa 1: identificar qual frontend originou as taxas e

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

Mapeamento de frontends

A rastreabilidade de taxas requer um mapeamento um para um de um domínio para um par de chave pública / privada. Sem esse mapeamento, um frontend malicioso poderia falsificar transações e fingir que elas foram enviadas a partir de um domínio honesto. A criptografia nos permite 'registrar' frontends, registrando de forma imutável o mapeamento de domínio para chave pública, provando que o domínio realmente controla essa chave pública e assinando transações com a referida 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 é 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 sem aumentar as cargas de governança descentralizada do DAO. Para ilustrar esse ponto, pense no espectro de designs possíveis para o staking de tokens de aplicativos, variando de uma única pool de staking para cada frontend a uma única pool de staking para todos os frontends.

Em sua construção mais simples, as taxas de cada frontend podem ser encaminhadas para um módulo de staking específico do frontend. Ao selecionar quais frontends apostar, um detentor de tokens seria capaz de decidir quais taxas está recebendo e evitar quaisquer taxas que coloquem o detentor de tokens em risco legal. Por exemplo, um detentor de tokens poderia apostar apenas 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. Pode haver 50 pools de staking para 50 frontends diferentes, e a diluição das taxas pode ser prejudicial ao valor do token.

Na extremidade oposta do espectro, as taxas de cada frente podem ser agrupadas juntas - mas isso vai contra o propósito da rastreabilidade das taxas. Se todas as taxas forem agrupadas, não há como diferenciar as taxas de frontends compatíveis versus não compatíveis - uma maçã podre estragaria o barril. Os detentores de tokens seriam forçados a escolher entre não receber nenhuma taxa ou participar de um pool onde se beneficiariam das atividades ilegais de frontends 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 deve avaliar onde as taxas podem ser aplicadas.

Abordando a rastreabilidade da taxa por meio da curadoria

Essas complexidades podem ser resolvidas por meio de curadoria. Considere um aplicativo de protocolo de contrato inteligente sem permissão que tenha uma taxa e um token. Qualquer pessoa pode criar uma interface para o aplicativo e qualquer interface pode ter seu próprio módulo de aposta. Vamos chamar uma interface para este aplicativo de protocolo 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 tem seu próprio módulo de staking, e os detentores de tokens podem apostar seus tokens diretamente nesse módulo ou a um curador que deseja escolher individualmente um conjunto de frontends que considerem conformes. Esses apostadores de tokens receberiam rendimento na forma das taxas do conjunto de frontends em que apostam. Se um frontend gerar $100 em taxas, e 100 entidades estiverem apostando 1 token cada, então cada entidade teria direito a $1. Os curadores poderiam inicialmente cobrar uma taxa por seus serviços. No futuro, os governos poderiam fazer atestações onchain sobre a conformidade dos frontends em sua jurisdição para ajudar a proteger os consumidores, com o benefício adicional sendo a automação da curadoria.

Um risco potencial nesse modelo é que as interfaces não conformes podem ser mais baratas de operar porque não possuem as despesas administrativas das interfaces conformes. Elas também podem criar modelos para reciclar as taxas das interfaces para os traders, incentivando ainda mais suas soluções alternativas. Dois fatores mitiGate esse risco. Primeiro, a maioria dos usuários realmente deseja interfaces conformes para seguir as leis e regulamentos locais. Isso se aplica especialmente a grandes instituições regulamentadas. Segundo, a governança pode desempenhar um papel vital como último recurso ou "autoridade de veto" nas interfaces não conformes que repetidamente quebram as regras e colocam em risco a viabilidade do aplicativo, desencorajando comportamentos ruins.

Finalmente, todas as taxas de transações que não são iniciadas por meio de uma interface registrada seriam depositadas em um único módulo de staking catchall, permitindo que o protocolo capture receita de 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 do aplicativo com mais detalhes. Para um protocolo facilitar a participação no frontend, seria necessário 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 de certificado.

1. O cliente da interface do usuário pode, então, chamar uma função register() e provar que é proprietário do seu nome de domínio. Um mapeamento do domínio para a chave pública do certificado, e vice-versa, são armazenados.
2. Quando as transações são criadas através do cliente, ele também assina a carga da transação com sua chave pública de certificado. Estes são passados para os contratos inteligentes da aplicação em um pacote.
3. Os contratos inteligentes do aplicativo validam o certificado, verificam se ele corresponde ao corpo tx correto e foram registrados. Se sim, a transação é processada. As taxas geradas pela transação são então enviadas para um contrato FeeCollector junto com o nome de domínio (do registro).
4. O FeeCollector permite que curadores, usuários, validadores e outros apostem tokens diretamente em um domínio ou conjunto de domínios. Esses contratos devem acompanhar a quantidade de tokens apostados em cada domínio, a participação de cada endereço nessa aposta e o tempo durante o qual eles foram apostados. Implementações populares de mineração de liquidez podem ser usadas como ponto de partida para essa lógica de contrato.
5. Usuários que apostaram em curadores (ou diretamente nos contratos de gerenciamento de taxas) podem então sacar a parcela proporcional da taxa de acordo com a quantidade de token do aplicativo apostado no domínio. A arquitetura poderia ser similar aMetaMorpho/Morpho Blue.

Isso poderia ser introduzido sem aumentar a carga de governança do DAO de um aplicativo. Na verdade, as responsabilidades de governança poderiam ser reduzidas, pois o interruptor de taxa poderia ser ligado 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, cadeias de aplicativos 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. Geralmente, isso ocorre por meio de um frontend fácil de usar (como um aplicativo ou site) que serve como 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 frontend, os aplicativos também podem adotar uma abordagem de lista branca ou lista negra para os frontends que contribuem para as taxas de rede. Novamente, o objetivo aqui seria garantir que os detentores de tokens e o protocolo como um todo não estejam lucrando ou se beneficiando de atividades ilícitas e estejam seguindo as leis e regulamentos específicos da jurisdição.

No método de lista branca, o aplicativo publicaria um conjunto de regras para as interfaces, criaria um registro dessas interfaces que seguem as regras, emitiria um certificado para as interfaces que optam por participar e exigiria que as interfaces apostassem tokens para receber uma parte das taxas do aplicativo. Se as interfaces não seguirem essas regras, elas serão punidas e o certificado delas para contribuições de taxas será removido.

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

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

Ambas essas abordagens aumentam significativamente o ônus 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 dos casos, terceirizar esse ônus de conformidade para um curador seria preferível.

Considerações para appchains

Appchains são blockchains específicos de aplicativos com validadores que trabalham apenas para esse aplicativo.

Em troca de seu trabalho, esses validadores recebem pagamento. Ao contrário das cadeias de blocos 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.

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

Este conjunto de trabalho é diferente de um validador de 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 suportar 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 geograficamente descentralizado.

A arquitetura para appchains que desejam aproveitar os benefícios da rastreabilidade de taxas seria semelhante às aplicações de Camada 1 até o pipeline de taxas. Mas os validadores poderiam usar mapeamento de frontend para determinar de quais frontends desejam processar transações. As taxas para qualquer transação dada então iriam para o conjunto ativo de validadores, com validadores inativos que escolheram não participar perdendo tais taxas. Do ponto de vista das taxas, o validador desempenha a mesma função que os curadores do módulo de staking discutido acima e os stakers para esses validadores poderiam garantir que não estão recebendo receitas de atividades ilícitas. Os validadores também poderiam eleger um curador para determinar quais frontends estão em conformidade por jurisdição.

Considerações para rollups de aplicativos

Os rollups têm seu próprio espaço de bloco, mas podem herdar a segurança de outra cadeia. A maioria dos pacotes cumulativos 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 por meio de um processo chamado "inclusão forçada.”

Se esses rollups são específicos de aplicativos e consagram seu sequenciador como o único validador, as taxas geradas pelas transações incluídas por esse sequenciador podem ser dispersas para os validadores com base no conjunto selecionado de front-ends compatíveis ou como um pool geral.

Se os rollups descentralizarem seu conjunto de sequenciadores, os sequenciadores se tornam os módulos de staking curados de facto e o pipeline de taxas espelharia o das appchains. Os sequenciadores substituem os validadores para distribuição de taxas, e cada sequenciador pode tomar suas próprias decisões sobre de quais frontends aceitar taxas.

Embora existam muitos modelos possíveis para tokens de aplicativos, fornecer pools de staking selecionados é um caminho a seguir que ajuda a lidar com os desafios extrínsecos únicos das aplicações. Ao reconhecer os desafios intrínsecos e extrínsecos enfrentados pelos aplicativos, os fundadores podem projetar modelos de token de aplicativo melhor desde o início para o seu projeto.

Aviso Legal:

1. Este artigo é reproduzido a partir de [Gatea16zcrypto]. Todos os direitos autorais pertencem ao autor original [Mason HallPorter SmithMiles Jennings and Ross Shuel]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso 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 da Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.