Escrito por: a16z Crypto
Compilado por: Pzai, Foresight News
Para tokens de infraestrutura – correspondentes à camada 1 da rede (ou partes adjacentes da pilha de computação, como a Camada 2) – o modelo económico já está bem desenvolvido e compreendido, e está enraizado na oferta e procura de espaço de bloco. Mas para os tokens de protocolo (App Tokens) – protocolos de contratos inteligentes que implantam serviços na blockchain e herdam direitos em “negócios distribuídos” – a construção de modelos económicos ainda está a ser explorada.
O modelo de negócios de um token de protocolo deve ser tão expressivo quanto o software subjacente. Para fazer isso, introduzimos o fluxo de caixa de tokens de protocolo – uma abordagem que permite aos protocolos criar modelos soltos e flexíveis onde os usuários podem escolher como serão recompensados com base no valor que fornecem. Esta abordagem gera taxas de atividades de conformidade com base em requisitos regulamentares em diferentes jurisdições, incentivando assim uma maior conformidade. Também maximiza o valor gerado pelo protocolo, ao mesmo tempo que incentiva uma governação mínima.
Os princípios que compartilhamos aqui se aplicam a todos os protocolos Web3 – do DeFi ao social descentralizado, à rede DePIN e a todos os demais.
Desafios enfrentados pelo modelo de token
Os tokens de infraestrutura estão sujeitos à oferta e procura intrínsecas: à medida que a procura aumenta, a oferta diminui e o mercado ajusta-se em conformidade. O EIP -1559 acelera a base econômica nativa de muitos tokens de infraestrutura, com a proposta de implementar uma queima de taxa básica para todas as transações Ethereum. No entanto, apesar das tentativas esporádicas de compra e queima de modelos, não houve tentativas de igualar o EIP -1559 para tokens de protocolo.
Os protocolos são usuários do espaço de bloco, não provedores, portanto, não podem contar com 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 programáticos 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 protocolo, os protocolos envolvidos podem depender da promoção de atividades de conformidade e podem exigir a intervenção de detentores de tokens de governação, tornando a sua economia mais complexa. As bolsas descentralizadas que facilitam a negociação de derivados são uma atividade altamente regulamentada nos Estados Unidos, muito diferente, por exemplo, do Ethereum.
A combinação destes desafios intrínsecos e extrínsecos significa que os tokens de protocolo requerem diferentes modelos económicos. Com isso em mente, propomos uma solução possível: uma abordagem para projetar protocolos que maximize a receita do protocolo, incentive a conformidade regulatória e incorpore a minimização da governança, ao mesmo tempo que fornece benefícios aos detentores de tokens de protocolo. Nosso objetivo é simples: fornecer tokens de protocolo com a mesma base econômica por meio de fluxo de caixa que muitos tokens de infraestrutura já possuem.
Nossa solução se concentra em resolver três problemas enfrentados pelos tokens de protocolo relacionados a: desafios de governança, desafios de distribuição de valor e desafios de atividades de conformidade.
Desafios de governança
Os tokens de protocolo geralmente têm direitos de governança, e a existência de uma organização autônoma descentralizada (DAO) pode introduzir incertezas que os tokens de infraestrutura não enfrentam. Para DAOs com operações substanciais nos Estados Unidos, podem surgir riscos se o DAO controlar as receitas do protocolo ou intervir nas atividades económicas do protocolo e tornar tais atividades processuais. Para evitar estes riscos, os projetos podem eliminar o controlo do DAO minimizando a governação. Para os DAOs incapazes de fazer isso, a nova 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.
O desafio da distribuição de valor
Os protocolos também devem ter cautela ao projetar mecanismos para alocar valor aos detentores de tokens. A combinação de direitos de voto com direitos económicos pode suscitar preocupações ao abrigo das leis de valores mobiliários dos EUA, especialmente no que diz respeito a mecanismos simples e diretos, como o rateio e a compra e destruição 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 receber um quadro regulamentar diferente do das ações.
Em vez disso, os projetos devem explorar o capitalismo das partes interessadas – recompensando os detentores de tokens pelas suas contribuições para o projeto de uma forma que beneficie o projeto. Muitos projetos incentivam a participação de soma positiva, incluindo operações front-end (Liquity), participação em protocolos (Pintassilgo) e promessa de garantias como parte de um módulo de segurança (Aave). O espaço de design aqui é aberto, mas um bom ponto de partida é mapear todas as partes interessadas no projeto, determinar quais comportamentos de cada uma delas devem ser incentivados e decidir que valor global o protocolo pode criar através deste incentivo.
Para simplificar, neste artigo assumiremos um modelo de remuneração simples que recompensa os detentores de tokens por participarem da governança, mesmo que existam outros esquemas.
Desafios das atividades de conformidade
Os protocolos que facilitam as atividades de conformidade também devem ser cautelosos ao projetar mecanismos de acumulação de valor para os detentores de tokens. Se tais mecanismos gerarem valor a partir de um front-end ou API que não opera em conformidade com a lei aplicável, 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 acumulação de valor proveniente de atividades permitidas nos EUA – por exemplo, cobrando taxas de protocolo apenas para pools de liquidez que envolvem determinados ativos. Isto sujeita os projetos ao menor denominador comum das abordagens regulatórias e prejudica a proposta de valor dos protocolos globais de software autônomo. Também prejudica diretamente os esforços de minimização da governação. Do ponto de vista da conformidade regulatória, determinar qual estratégia de cobrança é eficaz não é uma tarefa apropriada para um DAO.
Num mundo ideal, os projetos seriam capazes de cobrar taxas de atividades em qualquer jurisdição que permita a atividade, sem ter que depender de um DAO para determinar o que é permitido. Em vez de exigir conformidade no nível do protocolo, a solução é garantir que as taxas incorridas por um protocolo sejam repassadas apenas se o front-end ou API que originou a taxa estiver em conformidade com as leis e regulamentos aplicáveis no local do front-end. Se os Estados Unidos tornassem ilegal a cobrança de taxas por certos tipos de transações facilitadas por um protocolo, isso poderia reduzir o valor económico dos tokens do protocolo a zero, mesmo que essa atividade seja perfeitamente permitida em todos os outros países 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: rastreabilidade de custos
A rastreabilidade das taxas é fundamental para lidar com riscos potenciais decorrentes de front-ends de não conformidade, sem introduzir risco de revisão ou tornar o protocolo não licenciável. Através da rastreabilidade, o protocolo garante que quaisquer taxas incorridas pelos detentores de tokens originem-se apenas de um front-end legal e compatível na jurisdição em que o detentor do token está localizado. Se as taxas não puderem ser rastreadas, os detentores de tokens não poderão gerar valor a partir de front-ends não conformes (ou seja, taxas cobradas por front-ends não conformes), o que pode colocar em risco os detentores de tokens.
Para tornar as taxas rastreáveis, os protocolos podem ser projetados usando um sistema de piquetagem de tokens de protocolo em duas etapas.
Etapa 1: determinar qual front-end está gerando o custo
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 que foram enviadas de um domínio honesto. A criptografia nos permite “registrar” o front-end, registrar imutavelmente o mapeamento de um domínio para uma chave pública, provar que o domínio realmente controla essa chave pública e usar a referida chave privada para assinar transações. Isso nos permite atribuir transações e, portanto, cobranças a um determinado domínio.
custo da rota
Uma vez rastreável a origem das taxas, o protocolo pode determinar como distribuir essas taxas de uma forma que proteja os detentores de tokens de taxas de transações ilegais, mas não aumente a carga de governança descentralizada do DAO. Para ajudar a ilustrar esse ponto, considere a variedade de designs possíveis para piquetagem de token de protocolo, variando de um pool de piquetagem por frontend a um pool de piquetagem para todos os frontends.
Em sua estrutura mais simples, as taxas de cada frontend podem ser roteadas para um módulo de staking separado específico do frontend. Ao selecionar um frontend para apostar, o detentor do token poderá decidir quais taxas está recebendo e evitar quaisquer taxas que colocariam o detentor do token em risco legal. Por exemplo, os detentores de tokens só podem apostar módulos relacionados a frontends que tenham recebido todas as aprovações regulatórias 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 de cada front-end podem ser agrupadas, mas isso vai contra o propósito da rastreabilidade das taxas. Se todas as despesas forem agrupadas, é impossível distinguir entre despesas iniciais compatíveis e não conformes – uma bosta de rato pode estragar todo o pote. Os detentores de tokens seriam forçados a escolher entre não cobrar nenhuma taxa ou manter uma participação em um pool onde se beneficiariam de atividades ilegais de frontends não conformes em sua jurisdição – uma opção que poderia impedir a participação de muitos detentores de tokens ou pode reverter o sistema ao seu atual design abaixo do ideal, onde o DAO deve avaliar onde as taxas podem ser cobradas.
Resolvendo problemas de rastreabilidade de despesas por meio de curadoria
Essas complexidades podem ser abordadas por meio da curadoria. Considere um protocolo de contrato inteligente sem permissão que possui taxas e tokens. Qualquer pessoa pode criar um frontend para o protocolo, e qualquer frontend pode ter seu próprio módulo de piquetagem. Chamamos um front end deste protocolo app .
App .xyz pode estar sujeito a regras de conformidade específicas nas jurisdições em que está localizado. A atividade de protocolo originada do app .xyz incorre em taxas de protocolo. Aplicativo . Esses tokens stakers receberão receita na forma de taxas do conjunto de front-end que eles apostam. Se o front-end gerar US$ 100 em taxas e 100 entidades apostarem 1 token cada, cada entidade terá direito a US$ 1. Os curadores podem inicialmente cobrar uma taxa por seus serviços. No futuro, os governos poderão realizar atestados em cadeia para comprovar a conformidade inicial dentro da sua jurisdição para ajudar a proteger os consumidores, com o benefício colateral de automatizar a curadoria.
Um risco potencial neste modelo é que os front-ends não conformes podem ter custos operacionais mais baixos porque não possuem a sobrecarga de gerenciamento dos front-ends compatíveis. Eles também podem projetar modelos que recuperem taxas iniciais aos traders para incentivar ainda mais suas soluções. Dois fatores reduzem esse risco. Primeiro, a maioria dos usuários realmente deseja um front-end compatível que cumpra as leis e regulamentos locais, e isso se aplica especialmente a grandes instituições regulamentadas. Em segundo lugar, para front-ends não conformes que violam repetidamente as regras e colocam em risco a viabilidade do protocolo, a governação pode desempenhar um papel importante como último recurso ou “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 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
Vamos voltar à pilha de tokens de protocolo com mais detalhes. 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 de um par de chaves gerado uma vez pelo front end, denominado certificado.
O cliente front-end pode então chamar a função de registro e provar que possui seu próprio nome de domínio, armazenando o mapeamento de chave pública do domínio para o certificado 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 são repassados aos contratos inteligentes do protocolo na forma de pacotes.
O contrato inteligente do protocolo verifica o certificado, verificando se ele corresponde ao principal da transação correto (frontend) e está registrado. Nesse caso, processe a transação. As taxas geradas pela transação são então enviadas para o contrato FeeCollector junto com o nome de domínio (do registro).
O contrato FeeCollector permite que curadores, usuários, validadores e outros façam stake de tokens diretamente em um domínio ou conjunto de domínios. Esses contratos devem rastrear o número de tokens apostados em cada domínio, a participação de cada endereço nessa aposta e o momento em que foram apostados. A implementação geral da mineração de liquidez pode servir como ponto de partida para esta lógica contratual.
Os usuários que apostam no Curador (ou diretamente no próprio contrato de gerenciamento de taxas) podem sacar uma parte proporcional das taxas com base na quantidade de tokens de protocolo prometidos ao domínio. A arquitetura pode ser semelhante à Meta Morpho/Morpho Blue.
Este mecanismo pode ser introduzido sem aumentar a carga de governação do DAO do protocolo. Na verdade, as responsabilidades de governação podem ser reduzidas porque podemos ativar permanentemente a mudança de taxas para todas as transações facilitadas pelo protocolo, eliminando assim qualquer controlo que o DAO tenha sobre o modelo económico do protocolo.
Considerações adicionais baseadas no tipo de protocolo
Embora esses princípios se apliquem amplamente aos modelos econômicos de tokens de protocolo, pode haver considerações adicionais sobre taxas dependendo do tipo de protocolo: protocolos criados na Camada 1 ou Camada 2, cadeias de aplicativos e protocolos criados usando Rollups.
Considerações para protocolos L1/L2
Um protocolo em uma blockchain de Camada 1 ou Camada 2 implanta contratos inteligentes diretamente na cadeia. As taxas são cobradas quando os usuários interagem com os contratos inteligentes do protocolo. Isso normalmente ocorre por meio de um front-end fácil de usar (como um protocolo ou site) que atua como uma interface entre os investidores de varejo e o contrato inteligente subjacente. Nesse caso, quaisquer cobranças virão desse front-end. O exemplo acima para app .xyz ilustra como funciona o sistema de cobrança para protocolos da Camada 1.
Os protocolos também podem usar listas de permissões ou listas negras para filtrar taxas iniciais, em vez de depender de curadores para filtrar taxas iniciais. Novamente, o objetivo aqui é garantir que os detentores de tokens e todo o protocolo não lucrem ou se beneficiem de atividades ilegais e cumpram as leis e regulamentos da jurisdição específica. Em uma abordagem de lista de permissões, o protocolo publicaria um conjunto de regras para front-ends, criaria um registro para front-ends que seguissem as regras, emitiria certificados para front-ends que aceitassem e exigiria que os front-ends apostassem tokens para receber uma parte das taxas do protocolo. . Se um front-end não aderir a essas regras, elas serão cortadas e seus certificados de contribuição de taxas serão removidos.
Na abordagem da lista negra, o protocolo não precisa criar nenhuma regra, mas o frontend que inicia o protocolo não ficará sem sanção. Em vez disso, o acordo exigirá que qualquer front-end forneça uma opinião de escritório de advocacia certificando que o front-end cumpre sua jurisdição antes de permitir que o front-end use o acordo. Assim que os comentários forem recebidos, o protocolo emitirá um certificado ao frontend para pagamento da taxa, que só será retirado caso o protocolo receba notificação do regulador sobre o descumprimento do frontend.
O canal de despesas refletirá os exemplos fornecidos nas seções anteriores. Ambas as abordagens aumentam significativamente o fardo da governação descentralizada, exigindo que os DAOs estabeleçam e mantenham um conjunto de regras ou avaliem pareceres jurídicos relativamente ao cumprimento. Em alguns casos isto pode ser aceitável, mas na maioria dos casos seria preferível subcontratar esta carga de conformidade a um curador.
Coisas a serem observadas sobre cadeias de aplicativos
Uma cadeia de aplicativos é um blockchain para um protocolo específico e seus validadores se aplicam apenas a esse protocolo. Em troca do seu trabalho, esses validadores recebem uma remuneração. Ao contrário dos blockchains da Camada 1, onde os validadores são normalmente recompensados através da emissão inflacionária de tokens, algumas cadeias de aplicativos (dYdX) repassam as taxas dos clientes aos validadores.
Neste modelo, os detentores de tokens devem apostar em validadores para receber recompensas. Os validadores tornam-se módulos de piquetagem orquestrados. Este conjunto de trabalho é diferente do validador da Camada 1. Os validadores da cadeia de aplicativos liquidam transações específicas de protocolos específicos. Devido a esta diferença, os validadores Lisk podem assumir um maior grau de risco legal nas atividades subjacentes que facilitam. Portanto, o protocolo deve dar aos validadores a liberdade de realizar o que puderem de acordo com as leis da sua jurisdição e o seu próprio nível de conforto. É importante ressaltar que isso pode ser conseguido sem comprometer a natureza sem permissão da cadeia de aplicativos ou expô-la a riscos significativos de censura, desde que seu conjunto de validadores seja geograficamente descentralizado.
A arquitetura de uma cadeia de aplicação que deseja aproveitar a rastreabilidade de taxas será semelhante a um protocolo da Camada 1 até que haja um canal de taxas. Mas os validadores poderão usar o mapeamento de frontend para determinar de quais frontends desejam que as transações sejam processadas. As taxas para qualquer transação irão então para o conjunto ativo de validadores, e os validadores inativos que optarem por não participar perderão essas taxas. Do ponto de vista das taxas, os validadores desempenham a mesma função que os curadores do módulo de staking mencionados acima, e os stakers desses validadores podem garantir que não estão recebendo rendimentos de qualquer atividade ilegal. Os validadores também podem eleger um curador para determinar quais frontends estão em conformidade em cada jurisdição.
Notas sobre rollups de protocolo
Rollup s possuem seu próprio espaço de bloco, mas podem herdar a segurança de outra cadeia. Hoje, a maioria dos rollups possui um sequenciador responsável por classificar e incluir transações, embora as transações possam ser confirmadas diretamente na Camada 1 por meio de um processo chamado “inclusão forçada”.
Se esses rollups forem específicos do protocolo e tiverem seu ordenante como o único validador, as taxas geradas pelas transações contidas nesse ordenador 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 Rollup descentralizasse seu conjunto de ordenadores, então os ordenantes se tornariam o módulo de piquetagem com curadoria de fato, e o canal de taxas refletiria o canal de receita do Appchain. Os solicitantes substituem os validadores para distribuição de taxas, e cada solicitante pode decidir por si mesmo de qual frontend aceitar taxas.
Resumir
Embora existam muitos modelos possíveis para tokens de protocolo, os pools de piquetagem, se cuidadosamente selecionados, podem ajudar a enfrentar desafios externos específicos do protocolo. Ao reconhecer os desafios inerentes e externos que os protocolos enfrentam, os fundadores podem projetar melhor um modelo de token de protocolo para o seu projeto desde o início.
