Autores: Mason Hall, Porter Smith, Miles Jennings, Ross Shuel
Compilado por: Deep Wave TechFlow
Para los tokens de infraestructura, como las redes Layer1 (o partes adyacentes de la pila informática, como Layer2), el modelo económico es relativamente maduro y fácil de entender, y se basa principalmente en la oferta y la demanda de espacio de bloques. Sin embargo, para los tokens de aplicación, protocolos de contratos inteligentes que implementan servicios en la cadena de bloques que transmiten derechos en el "comercio distribuido", el modelo económico aún se está explorando.
El modelo de negocio de un token de aplicación debe ser tan expresivo como su software subyacente. Con este fin, proponemos un modelo de flujo de efectivo para tokens de aplicaciones, un método que permite a las aplicaciones crear modelos económicos flexibles y permisivos y, al mismo tiempo, permite a los usuarios elegir cómo son recompensados en función del valor proporcionado. Este enfoque fomenta un mayor cumplimiento al generar tarifas por actividades legales bajo requisitos regulatorios en diferentes jurisdicciones. Al mismo tiempo, también maximiza el valor acumulado por el protocolo y promueve una gobernanza mínima.
Los principios que compartimos aquí se aplican a todas las aplicaciones Web3, desde las finanzas descentralizadas (DeFi) hasta las aplicaciones sociales descentralizadas, las redes de infraestructura física descentralizadas (DePIN) y otras áreas relacionadas.
Desafíos que enfrenta el modelo token
Los tokens de infraestructura están sujetos a una oferta y demanda integradas: a medida que aumenta la demanda, la oferta disminuye y el mercado se ajusta en consecuencia. Esta base económica se ha reforzado en muchos tokens de infraestructura, en particular a través de la Propuesta de mejora de Ethereum 1559 (EIP-1559), que implementó un mecanismo subyacente de quema de tarifas para todas las transacciones de Ethereum. Pero a pesar de algunos intentos de modelos de compra y quema, los tokens de aplicación no tienen ningún mecanismo comparable al EIP-1559.
Las aplicaciones son usuarios de espacio de bloque, no proveedores, por lo que no pueden depender de cobrar tarifas de gas a otros usuarios de su espacio de bloque. Por eso necesitan desarrollar sus propios modelos económicos.
Aquí también existen algunos desafíos legales: el modelo económico de los tokens de infraestructura es relativamente inmune a los riesgos legales debido a la naturaleza genérica de las transacciones típicas de blockchain y los mecanismos programáticos que utilizan. Pero en el caso del modelo económico de tokens de aplicación, las aplicaciones involucradas pueden depender de la promoción de actividades reguladas y pueden requerir el papel intermediario de los poseedores de tokens de gobernanza, lo que hace que el modelo económico sea más complejo. Los intercambios descentralizados que facilitan el comercio de derivados son una actividad altamente regulada en los Estados Unidos, que es fundamentalmente diferente de proyectos como Ethereum.
La combinación de estos desafíos intrínsecos y extrínsecos significa que la aplicación de tokens requiere un modelo económico diferente. Con esto en mente, proponemos una posible solución: un enfoque para diseñar protocolos que tenga como objetivo compensar a los titulares de tokens de aplicación por sus servicios mientras maximiza los ingresos del protocolo, incentiva el cumplimiento e incorpora la minimización de la gobernanza. Nuestro objetivo es simple: proporcionar tokens de aplicación con la misma base económica que muchos tokens de infraestructura a través del flujo de caja.
Nuestra solución se centra en resolver tres problemas que enfrentan los tokens de aplicación:
Desafíos relacionados con la gobernanza
Desafíos relacionados con la distribución de valor
Desafíos relacionados con las actividades reguladas
1. Desafíos relacionados con la gobernanza
Los tokens de aplicación suelen tener derechos de gobernanza, y la existencia de una organización autónoma descentralizada (DAO) puede generar una incertidumbre que los tokens de infraestructura no enfrentan. Para las DAO con operaciones importantes en los Estados Unidos, pueden surgir riesgos si la DAO controla los ingresos del protocolo o intermedia la actividad económica del protocolo y controla programáticamente dicha actividad. Para evitar estos riesgos, los proyectos pueden eliminar el control de la DAO minimizando la gobernanza. Para aquellas DAO que no pueden hacer esto, la Nueva Asociación Descentralizada sin Fines de Lucro (DUNA) de Wyoming proporciona una entidad legal descentralizada que puede ayudar a mitigar estos riesgos y cumplir con las leyes fiscales aplicables.
2. Desafíos relacionados con la distribución del valor
Las aplicaciones también deben tener cuidado al diseñar los mecanismos de valor asignados a los poseedores de tokens. Combinar los derechos de voto con los derechos económicos puede generar preocupaciones en virtud de las leyes de valores estadounidenses, particularmente en el caso de mecanismos simples y directos como la prorrata y la compra y quema de tokens. Estos mecanismos se parecen a los dividendos y las recompras de acciones, lo que potencialmente socava los argumentos de que los tokens deberían disfrutar de un marco regulatorio diferente al de las acciones.
Los proyectos deben explorar el capitalismo de las partes interesadas: recompensar a los poseedores de tokens por sus contribuciones al proyecto de una manera que beneficie al proyecto. Muchos proyectos fomentan la participación activa, incluida la operación de interfaces (como Liquidity), la participación en protocolos (como Goldfinch) y la promesa de garantías como parte de módulos de seguridad (como Aave). El espacio de diseño aquí es vasto, pero un buen punto de partida es mapear a todas las partes interesadas en el proyecto, determinar qué comportamientos deben fomentarse y decidir sobre el valor general que el protocolo puede crear a través de este incentivo.
En aras de la simplicidad, en este artículo asumiremos un modelo de compensación simple que recompensa a los poseedores de tokens por participar en la gobernanza, aunque existen otros esquemas.
3. Desafíos asociados a las actividades reguladas
Las aplicaciones que facilitan actividades reguladas también deben tener cuidado al diseñar mecanismos de acumulación de valor para los poseedores de tokens. En la medida en que estos mecanismos acumulen valor a partir de una interfaz o API que no opere de conformidad con la ley aplicable, los poseedores de tokens pueden estar beneficiándose de actividades ilegales.
La mayoría de las soluciones propuestas a este problema se centran en limitar la acumulación de valor a actividades permitidas en Estados Unidos; por ejemplo, activar tarifas de protocolo sólo en fondos de liquidez que involucran activos específicos. Esto somete los proyectos a un enfoque mínimo de gobernanza común y debilita la propuesta de valor de los protocolos de software autónomos globales. También socava directamente los esfuerzos de minimización de la gobernanza. Determinar qué estrategias de tarifas son efectivas desde una perspectiva de cumplimiento normativo no es una tarea apropiada para una DAO.
Idealmente, los proyectos deberían poder cobrar tarifas de cualquier jurisdicción que permita la actividad sin tener que depender de una DAO para determinar qué está permitido. La solución no es exigir el cumplimiento a nivel de protocolo, sino garantizar que las tarifas generadas por el protocolo solo se transmitan de conformidad con las leyes y regulaciones aplicables en el front-end o en el origen de la API. Si Estados Unidos declara ilegal el cobro de tarifas por transacciones facilitadas por una aplicación, podría reducir el valor económico del token de la aplicación a cero, incluso si la actividad es perfectamente legal en otros países del mundo. La flexibilidad con respecto a la acumulación y asignación de tarifas significa, en última instancia, resiliencia frente a las presiones regulatorias.
Una cuestión central: la trazabilidad de los gastos
La trazabilidad de las tarifas es fundamental para abordar los riesgos potenciales derivados del incumplimiento sin introducir riesgos de revisión ni hacer que el acuerdo requiera una licencia. A través de la trazabilidad, las aplicaciones pueden garantizar que las tarifas acumuladas a los poseedores de tokens solo se originen en interfaces que sean legales y conformes en la jurisdicción en la que se encuentra el poseedor de tokens. Si las tarifas no son rastreables, no hay manera de aislar a los poseedores de tokens del valor acumulado por los front-ends que no cumplen (es decir, las tarifas cobradas por los front-ends que no cumplen), lo que puede poner en riesgo a los poseedores de tokens.
Para que las tarifas sean rastreables, el protocolo puede adoptar un diseño de sistema de participación de tokens de aplicación de dos pasos:
Paso 1: Identificar el inicio de las fuentes de gastos
Parte 2: Enrutar tarifas a diferentes grupos según una lógica personalizada
Interfaz de mapeo
La trazabilidad de las tarifas requiere la asignación de nombres de dominio a pares de claves públicas/privadas. Sin este mapeo, una interfaz maliciosa podría falsificar transacciones, simulando que fueron enviadas desde un dominio honesto. La criptografía nos permite "registrar" la interfaz, registrar permanentemente la asignación de un nombre de dominio a una clave pública, demostrar que el nombre de dominio realmente controla esa clave pública y usar esa clave privada para firmar transacciones. Esto nos permite atribuir transacciones (y por lo tanto tarifas) a dominios específicos.
Cargos de ruta
Una vez que se puede rastrear la fuente de las tarifas, el protocolo puede decidir cómo distribuir esas tarifas para proteger a los poseedores de tokens de las tarifas de transacciones ilegales sin aumentar la carga de gobernanza descentralizada de la DAO. Para ayudar a ilustrar esto, considere aplicar diseños de participación de tokens que van desde un grupo de participación por interfaz hasta un grupo de participación para todas las interfaces.
En la construcción más simple, las tarifas de cada interfaz se pueden enviar a un módulo de participación separado específico de la interfaz. Al elegir en qué interfaces apostar, los poseedores de tokens podrán decidir qué tarifas recibirán y evitar cualquier tarifa que pueda ponerlos en riesgo legal. Por ejemplo, los poseedores de tokens solo pueden apostar en módulos asociados con interfaces que hayan recibido todas las aprobaciones regulatorias en Europa. Si bien este diseño parece simple, en realidad es bastante complejo. Podría haber 50 grupos de apuestas para 50 interfaces diferentes, y la dilución de las tarifas podría tener un efecto adverso en el valor del token.
En el otro extremo del espectro de diseño, los gastos de cada etapa inicial se pueden agregar, pero esto frustra el propósito de la trazabilidad de los gastos. Si se sumaran todos los gastos, no habría manera de diferenciar entre los gastos de la parte inicial que cumple y los de la parte inicial que no cumple, y sólo se necesitaría una manzana podrida para estropear todo el barril. Los poseedores de tokens se verán obligados a elegir entre no recibir tarifas y apostar en un grupo donde se beneficiarán de las actividades ilegales de los front-ends que no cumplen con las normas en sus jurisdicciones. — —Esta opción podría disuadir a muchos poseedores de tokens de participar, o podría revertir la sistema a su diseño actual subóptimo, donde la DAO debe evaluar dónde se pueden aplicar tarifas.
Resolver la trazabilidad de los gastos mediante la curación
Estas complejidades se pueden abordar mediante la curación. Considere una aplicación de protocolo de contrato inteligente sin permiso con tarifas y tokens. Cualquiera puede crear una interfaz para la aplicación y cada interfaz puede tener su propio módulo de participación. Llamamos a una interfaz de este protocolo App.xyz.
App.xyz puede cumplir con reglas de cumplimiento específicas en las jurisdicciones en las que opera. La actividad de la aplicación desde App.xyz genera tarifas de acuerdo. App.xyz tiene su propio módulo de apuesta, al que los poseedores de tokens pueden apostar sus tokens directamente, o a los curadores que deseen seleccionar individualmente una canasta de interfaces que consideren compatibles. Estos apostadores de tokens recibirán ingresos en forma de tarifas generadas por el front-end que apuesten. Si una interfaz genera $100 en tarifas y 100 entidades cada una apuesta 1 token, cada entidad tendrá derecho a $1. Inicialmente, los curadores pueden cobrar una tarifa por sus servicios. En el futuro, los gobiernos pueden certificar el cumplimiento desde el principio dentro de sus jurisdicciones en la cadena para ayudar a proteger a los consumidores y, al mismo tiempo, aprovechar los beneficios adicionales de la curación automatizada.
Un riesgo potencial en este modelo es que las interfaces que no cumplen con las normas pueden tener costos operativos más bajos porque carecen de los gastos administrativos de las interfaces que cumplen con las normas. También pueden diseñar modelos que recuperen las tarifas iniciales a los comerciantes para incentivar aún más las soluciones alternativas. Dos factores pueden mitigar este riesgo. En primer lugar, la mayoría de los usuarios en realidad quieren que el interfaz de cumplimiento cumpla con las leyes y regulaciones locales, lo cual es especialmente cierto para las grandes instituciones reguladas. En segundo lugar, la gobernanza puede desempeñar un papel importante como último recurso o “poder de veto” para frenar el mal comportamiento contra interfaces que no cumplen las normas y que violan repetidamente las reglas y ponen en peligro la viabilidad de la aplicación.
Finalmente, todas las tarifas de transacción que no se inicien a través de la interfaz registrada se depositarán en un único módulo de participación integrado, lo que permitirá que el protocolo capture los ingresos generados por los bots y otras transacciones que interactúan directamente con los contratos inteligentes del protocolo.
De la teoría a la implementación: poner los métodos en práctica
Repasemos la pila de tokens de la aplicación con más detalle. Para facilitar la participación del front-end, el protocolo debe establecer un contrato inteligente de registro en el que el front-end debe registrarse.
Cada interfaz o API puede agregar un registro TXT especial a los registros DNS para su nombre de dominio, al igual que la integración DNS de ENS. Este registro TXT contiene la clave pública de un par de claves generadas por el front-end, llamado certificado.
El cliente front-end puede llamar a la función registrarse() y demostrar que posee su nombre de dominio. Se almacenará la asignación de nombres de dominio a claves públicas de certificados, así como la asignación inversa.
Cuando se crea una transacción a través del cliente, también firma la carga útil de la transacción con su clave pública de certificado. Estos se empaquetan y pasan al contrato inteligente de la aplicación.
El contrato inteligente aplicado verifica el certificado, comprobando que corresponde al sujeto de la transacción correcta y que está registrado. Si es así, se procesa la transacción. Las tarifas generadas por la transacción se envían al contrato FeeCollector junto con el nombre de dominio (del registro).
FeeCollector permite a curadores, usuarios, validadores y otros apostar tokens directamente en un dominio o conjunto de dominios. Estos contratos deben realizar un seguimiento de la cantidad de tokens apostados en cada dominio, la participación de cada dirección en esa apuesta y cuándo se apostaron. Las implementaciones populares de minería de liquidez pueden servir como punto de partida para esta lógica contractual. Los usuarios que se hayan comprometido con el curador (o se hayan comprometido directamente con el contrato de administración de tarifas) pueden retirar la tarifa compartida correspondiente según la cantidad de tokens de aplicación comprometidos con el dominio. La arquitectura podría ser similar a MetaMorpho/Morpho Blue.
Esta solución se puede introducir sin aumentar la carga de gobernanza de la aplicación DAO. De hecho, las responsabilidades de gobernanza pueden reducirse ya que el cambio de tarifas puede activarse permanentemente, aplicándose a todas las transacciones facilitadas por el protocolo, eliminando así cualquier control que la DAO tenga sobre el modelo económico del protocolo.
Consideraciones adicionales según el tipo de aplicación
Si bien estos principios se aplican ampliamente a los modelos económicos de tokens de aplicaciones, puede haber consideraciones de tarifas adicionales según el tipo de aplicación (como aplicaciones creadas en Layer1 o Layer2, cadenas de aplicaciones y aplicaciones creadas mediante Rollup).
Consideraciones de aplicación L1/L2
Las aplicaciones en cadenas de bloques de Capa 1 o Capa 2 implementan contratos inteligentes directamente en la cadena. Se cobran tarifas cuando los usuarios interactúan con el contrato inteligente de la aplicación. Normalmente, esta interacción se produce a través de una interfaz fácil de usar (como una aplicación o un sitio web) que actúa como interfaz entre el usuario minorista y el contrato inteligente subyacente. En este caso, todos los cargos se originarán en ese front-end. El ejemplo anterior en app.xyz ilustra cómo funciona el sistema de gastos en una aplicación Layer1.
Las aplicaciones también pueden adoptar un enfoque de lista blanca o lista negra para filtrar las tarifas iniciales, en lugar de depender de curadores. El propósito aquí es garantizar que ni los poseedores de tokens ni todo el protocolo se beneficien de actividades ilegales y cumplan con las leyes y regulaciones de la jurisdicción específica.
En el enfoque de lista blanca, la aplicación publica un conjunto de reglas de frontend, crea un registro de frontends que siguen esas reglas, emite certificados a los frontends que optan por participar y requiere que los frontends apuesten tokens para recibir una parte de la tarifa de la aplicación. Si un front-end no sigue estas reglas, se le reducirá su contribución de tarifa y se le revocará su certificado.
En el enfoque de lista negra, la aplicación no necesita crear ninguna regla, pero el proceso de inicio de la interfaz de la aplicación no será sin permiso. En cambio, la aplicación requiere que cualquier front-end proporcione una opinión de una firma de abogados que certifique que el front-end cumple con las regulaciones de su jurisdicción antes de ser habilitado. Una vez que se reciben los comentarios, la aplicación emitirá un certificado por la contribución de la tarifa al frontend, que solo será revocado si la aplicación recibe una notificación del regulador de que el frontend no cumple.
El proceso de tarifas será similar al ejemplo proporcionado en la sección anterior.
Ambos enfoques aumentan significativamente la carga de la gobernanza descentralizada, lo que requiere que las DAO establezcan y mantengan un conjunto de reglas o evalúen opiniones legales sobre el cumplimiento. En algunos casos esto puede ser aceptable, pero en la mayoría de los casos sería preferible subcontratar la carga de cumplimiento a un curador.
Consideraciones de la cadena de aplicaciones
Una cadena de aplicaciones es una cadena de bloques para una aplicación específica y los validadores solo funcionan para esa aplicación.
A cambio de su trabajo, estos validadores reciben un pago. A diferencia de las cadenas de bloques de Capa 1, donde los validadores generalmente son recompensados mediante la emisión de tokens inflacionarios, algunas cadenas de aplicaciones (como dYdX) pasan las tarifas de los clientes a los validadores.
En este modelo, los poseedores de tokens deben apostar a los validadores para recibir recompensas. Los validadores se convierten en módulos de participación seleccionados.
Este conjunto de trabajo es diferente de los validadores de Capa1. Los validadores de la cadena de aplicaciones procesan transacciones específicas de aplicaciones específicas. Debido a esta diferencia, los validadores de Lisk pueden estar sujetos a mayores riesgos legales debido a la naturaleza de las actividades que facilitan. Por lo tanto, el protocolo debe dar a los validadores la libertad de realizar su trabajo de acuerdo con las leyes de su jurisdicción y su propia comodidad. Es importante destacar que esto se puede lograr sin comprometer la naturaleza sin permiso de la cadena de aplicaciones ni exponerla a un riesgo de censura significativo, siempre que la distribución geográfica de los validadores esté descentralizada.
Una arquitectura de cadena de aplicaciones que desee aprovechar los beneficios de la trazabilidad de gastos será similar a una aplicación de Capa 1, hasta el proceso de gastos. Pero los validadores podrán utilizar el mapeo de frontend para determinar en qué frontend desean trabajar. Las tarifas de cualquier transacción determinada se distribuirán al conjunto activo de validadores, mientras que los validadores inactivos que decidan no participar se perderán estas tarifas. Desde la perspectiva de las tarifas, los validadores funcionan de la misma manera que los curadores del módulo de participación discutidos anteriormente, y los participantes que apuestan por estos validadores tienen la garantía de que no recibirán ingresos de ninguna actividad ilegal. Los validadores también pueden seleccionar curadores para determinar qué interfaces cumplen con las normas en sus respectivas jurisdicciones.
Consideraciones para aplicar Rollup
Rollup tiene su propio espacio de bloque pero puede heredar la seguridad de otra cadena. La mayoría de los paquetes acumulativos actuales tienen un único secuenciador responsable de ordenar e incluir transacciones, aunque las transacciones se pueden enviar directamente a Layer1 a través de un proceso llamado "inclusión forzada".
Si estos paquetes acumulativos son específicos de la aplicación y tratan a su ordenante como el único validador, las tarifas generadas por las transacciones incluidas en ese ordenante se pueden distribuir a los participantes en función de un conjunto seleccionado de interfaces compatibles o como un grupo general.
Si Rollup descentraliza su conjunto de ordenantes, los ordenantes se convertirán en el módulo de participación seleccionado de facto y la canalización de tarifas será similar a la cadena de aplicaciones. Los secuenciadores reemplazan a los validadores para la distribución de tarifas, y cada secuenciador puede decidir qué interfaces aceptar tarifas.
Si bien existen muchos modelos posibles para tokens de aplicaciones, ofrecer grupos de participación seleccionados es un camino a seguir que ayuda a resolver los desafíos externos únicos de las aplicaciones. Al reconocer los desafíos intrínsecos y extrínsecos que enfrentan las aplicaciones, los fundadores pueden diseñar mejor modelos de tokens de aplicaciones para sus proyectos desde cero.
