Para los tokens de infraestructura, que corresponden a una red de Capa 1 (o a una parte adyacente de la pila informática como la Capa 2), los modelos económicos están bien desarrollados y comprendidos, arraigados en la oferta y la demanda de espacio de bloque. Pero para los tokens de aplicación, los protocolos de contratos inteligentes que despliegan servicios en las blockchains que transmiten derechos en "negocios distribuidos", los modelos económicos todavía se están resolviendo.

Los modelos de negocio de tokens de aplicaciones deben ser tan expresivos como su software subyacente. Con ese fin, presentamos flujos de efectivo para tokens de aplicaciones, un enfoque que permite a las aplicaciones crear modelos permisivos y flexibles y a los usuarios elegir cómo se les recompensa por el valor que proporcionan. Este método crea tarifas a partir de actividades legítimas según los requisitos reglamentarios de diferentes jurisdicciones, lo que fomenta un mayor cumplimiento. También maximiza el valor que se acumula en el protocolo mientras fomenta minimización de la gobernanza.

Los principios que compartimos aquí se aplican a todas las aplicaciones web3, desde DeFi hasta aplicaciones sociales descentralizadas, redes DePIN y en todas partes intermedias.

Desafíos para los modelos de tokens

Las fichas de infraestructura están sujetas a la oferta y demanda incorporadas: a medida que aumenta la demanda, la oferta disminuye y los mercados se ajustan en consecuencia. Esta base económica nativa para muchas fichas de infraestructura fue acelerada por la Propuesta de Mejora de Ethereum 1559 (EIP-1559) que implementó una tarifa base que se quemará para todas las transacciones de Ethereum. Pero a pesar de los intentos dispersos de modelos de compra y quema, no hay un paralelo a EIP-1559 para tokens de aplicación.

Las aplicaciones son usuarios, no proveedores, de espacio de bloque, por lo que no pueden depender de la recopilación de tarifas de gas de otros que utilizan su espacio de bloque. Por eso necesitan desarrollar sus propios modelos económicos.

Aquí también hay algunos desafíos legales: los modelos económicos de tokens de infraestructura están más aislados del riesgo legal, debido a la naturaleza genérica de las transacciones típicas de blockchain y a los mecanismos programáticos que utilizan. Pero para los modelos económicos de tokens de aplicación, las aplicaciones involucradas pueden depender de la facilitación de actividades reguladas y pueden requerir la intermediación de los titulares de tokens de gobernanza, lo que complica más la economía. Un exchange descentralizado que facilita el comercio de derivados, una actividad altamente regulada en los EE. UU., es radicalmente diferente que, por ejemplo, Ethereum.

La combinación de estos desafíos intrínsecos y extrínsecos significa que los tokens de aplicación requieren un modelo económico diferente. Con eso en mente, presentamos una posible solución: un método para diseñar protocolos que compensen a los titulares de tokens de aplicación por sus servicios mientras maximizan los ingresos del protocolo, incentivan el cumplimiento normativo e incorporanminimización de la gobernanza. Nuestro objetivo es simple: dar a los tokens de aplicación el mismo respaldo económico, a través de flujos de efectivo, que muchos tokens de infraestructura ya tienen.

Nuestra solución se centra en resolver tres problemas que enfrentan los tokens de aplicación relacionados con:

1. Desafíos con la gobernanza
2. Desafíos con la distribución de valor
3. Desafíos con actividad regulada

1. Desafíos con la gobernanza

Los tokens de aplicación suelen tener derechos de gobernanza, y la presencia de una Organización Autónoma Descentralizada (DAO) puede introducir incertidumbreque los tokens de infraestructura no enfrentan. Para los DAO con operaciones significativas en los Estados Unidos, pueden surgir riesgos si el DAO tiene control sobre los ingresos del protocolo o intermedia la actividad económica del protocolo y hace que dicha actividad sea programática. Para evitar estos riesgos, los proyectos pueden eliminar el control que tiene un DAO mediante la minimización de la gobernanza. Para los DAO donde eso no es posible, la nueva iniciativa de Wyoming.Decentralized Unincorporated Nonprofit Association (DUNA)proporcionaunaentidad legal descentralizada que podría ayudar a mitigar estos riesgos y cumplir con las leyes fiscales aplicables.

2. Desafíos con la distribución de valor

Las aplicaciones también deben tener cuidado al diseñar el mecanismo que distribuye el valor a los poseedores de tokens. Combinando derechos de voto y económicospuede plantear preocupaciones bajo las leyes de valores de EE.UU., especialmente con mecanismos simples y directos como las distribuciones pro rata y la compra y quema de tokens. Estos mecanismos se parecen a los dividendos y recompras de acciones, y pueden socavar los argumentos de que los tokens merecen un marco regulatorio diferente al de las acciones.

En cambio, los proyectos deberían explorar el capitalismo de los grupos de interés, recompensando a los poseedores de tokens por sus contribuciones al proyecto de una manera que beneficie al proyecto. Muchos proyectos han fomentado la participación de suma positiva, incluyendo el funcionamiento de un frontend (Liquity) participando en el protocolo (Jilguero), y comprometiéndose con un módulo de seguridad como parte del colateral (Aave). El espacio de diseño aquí está ampliamente abierto, pero un buen lugar para comenzar es mapear a todos los interesados en un proyecto, determinar qué comportamientos deben ser alentados por cada uno de ellos y decidir qué valor general puede crear el protocolo a través de esa incentivación.

Por simplicidad, en esta publicación asumiremos un modelo de compensación simple que recompensa a los titulares de tokens por su participación en la gobernanza, aunque existen otros esquemas.

3. Desafíos con actividad regulada

Las aplicaciones que facilitan actividades reguladas también deben tener cuidado al diseñar mecanismos de acumulación de valor para los titulares de tokens. Si dichos mecanismos acumulan valor de interfaces o APIs que no se operan de conformidad con la ley aplicable, los titulares de tokens podrían estar obteniendo ganancias de actividades ilícitas.

La mayoría de las soluciones propuestas a este problema se han centrado en limitar la acumulación de valor a la actividad que es permitida en los EE. UU. — por ejemplo, solo activando las tarifas del protocolo con respecto a las piscinas de liquidez que involucran ciertos activos. Esto somete a los proyectos al enfoque regulatorio más bajo y socava la propuesta de valor de los protocolos de software autónomos a nivel global. También socava directamente los esfuerzos de minimización de la gobernanza. Determinar qué estrategia de tarifas funciona desde una perspectiva de cumplimiento regulatorio no es una tarea apropiada para las DAOs.

En un mundo ideal, los proyectos podrían cobrar tarifas por la actividad en cualquier jurisdicción donde esa actividad sea permitida, sin tener que depender de las DAO para determinar lo que es permisible. The soluciónno es exigir el cumplimiento normativo a nivel de protocolo, sino asegurar que las tarifas generadas por el protocolo se transfieran solo si la interfaz o API que las originó cumple las leyes y regulaciones aplicables en la ubicación de la interfaz. Si Estados Unidos hiciera ilegal cobrar tarifas en un cierto tipo de transacción facilitada por una aplicación, eso podría reducir el valor económico del token de esa aplicación a cero, incluso si la actividad fuera completamente permitida en todos los demás países del mundo. La flexibilidad en cuanto a la acumulación y distribución de tarifas equivale en última instancia a la resistencia ante las presiones regulatorias.

Un problema clave: Rastreo de tarifas

La trazabilidad de las tarifas es fundamental para resolver los posibles riesgos derivados de los frontends no conformes sin introducir el riesgo de censura o hacer que el protocolo requiera permisos. Con la trazabilidad, una aplicación podría asegurar que las tarifas que se acumulan para los titulares de tokens provengan solo de frontends que cumplan con la ley en la jurisdicción del titular del token. Si las tarifas no son rastreables, no habría forma de proteger a los titulares de tokens de acumular valor proveniente de frontends no conformes (es decir, tarifas recolectadas por frontends no conformes), lo que podría exponer a los titulares de tokens a riesgos.

Para hacer que las tarifas sean rastreables, un protocolo podría usar un diseño de sistema de participación de tokens de aplicación de dos pasos.

Paso 1: identificar cuál frontend originó las tarifas, y

Paso 2: enrutamiento de las comisiones a diferentes pools basado en lógica personalizada.

Mapeo de interfaces

La trazabilidad de las tarifas requiere una asignación uno a uno de un dominio a un par de clave pública/privada. Sin esta asignación, un frontend malintencionado podría falsificar transacciones y pretender que fueron enviadas desde un dominio honesto. La criptografía nos permite "registras" frontends, registrando de manera inmutable la asignación de dominio a clave pública, demostrando que el dominio realmente controla esa clave pública y firmando transacciones con dicha clave privada. Esto nos da la capacidad de atribuir transacciones y, por lo tanto, tarifas, a un dominio determinado.

Tarifas de enrutamiento

Una vez que se pueda rastrear la fuente de las tarifas, el protocolo puede determinar cómo distribuir esas tarifas de manera que los poseedores de tokens estén protegidos de recibir tarifas de transacciones ilícitas, pero que también no aumenten las cargas de gobernanza descentralizada del DAO. Para ilustrar este punto, piense en el espectro de posibles diseños para el apoyo de tokens de aplicaciones, que van desde una piscina de apoyo para cada interfaz hasta una piscina de apoyo para todas las interfaces.

En su construcción más simple, las tarifas de cada frontend podrían dirigirse a un módulo de participación específico del frontend. Al seleccionar a qué frontends apostar, un titular de tokens podría decidir qué tarifas está recibiendo y evitar cualquier tarifa que ponga al titular de tokens en peligro legal. Por ejemplo, un titular de tokens solo podría apostar al módulo asociado con un frontend que haya recibido todas las aprobaciones regulatorias en Europa. Si bien este diseño suena simple, en realidad es bastante complicado. Podría haber 50 grupos de participación para 50 frontends diferentes, y la dilución de las tarifas podría ser adversa para el valor del token.

En el extremo opuesto del espectro, las tarifas de cada interfaz podrían agruparse, pero esto va en contra del propósito de la trazabilidad de las tarifas. Si todas las tarifas se agrupan, no hay forma de diferenciar las tarifas de las interfaces compatibles de las no compatibles, un manzana podrida podría arruinar el barril. Los titulares de tokens se verían obligados a elegir entre no recibir ninguna tarifa o participar en un grupo donde se beneficiarían de las actividades ilegales de las interfaces no compatibles en su jurisdicción, una opción que podría disuadir a muchos titulares de tokens de participar o revertir el sistema a diseños subóptimos actuales, donde una DAO debe evaluar dónde se pueden aplicar las tarifas.

Abordando la trazabilidad de las tarifas a través de la curación

Estas complejidades podrían resolverse a través de la curación. Considere una aplicación de protocolo de contrato inteligente sin permisos que tiene una tarifa y un token. Cualquiera puede crear una interfaz para la aplicación y cualquier interfaz puede tener su propio módulo de apuestas. Llamemos a una interfaz para esta aplicación de protocolo app.xyz.

App.xyz podría seguir reglas de cumplimiento específicas para la jurisdicción en la que se encuentra. La actividad de la aplicación que se originó en app.xyz genera tarifas de protocolo. App.xyz tiene su propio módulo de participación, y los titulares de tokens pueden apostar sus tokens en ese módulo directamente o a un curador que quiera elegir individualmente una cesta de frontends que consideren cumplidores. Estos apostadores de tokens obtendrían rendimiento en forma de tarifas del conjunto de frontends en los que apuestan. Si un frontend genera $100 en tarifas, y 100 entidades apuestan 1 token cada una, entonces cada entidad tiene derecho a $1. Los curadores podrían cobrar inicialmente una tarifa por sus servicios. En el futuro, los gobiernos podrían hacer atestaciones en cadena sobre frontends que cumplen en su jurisdicción para ayudar a proteger a los consumidores, con el beneficio adicional de la automatización de la curación.

Un riesgo potencial en este modelo es que los frontends no compatibles podrían ser más baratos de operar porque carecen de la sobrecarga administrativa de los frontends compatibles. También podrían idear modelos para reciclar las tarifas de la interfaz a los comerciantes para incentivar aún más su solución. Dos factores mienten este riesgo. En primer lugar, la mayoría de los usuarios realmente quieren que las interfaces cumplan con las leyes y regulaciones locales. Esto se aplica especialmente a las grandes instituciones reguladas. En segundo lugar, la gobernanza podría desempeñar un papel vital como último recurso o "autoridad de veto" en los frontends que no cumplen con las normas y que rompen repetidamente las reglas y ponen en peligro la viabilidad de la aplicación, desalentando el mal comportamiento.

Finalmente, todas las tarifas de transacciones que no se inicien a través de un frontend registrado se depositarían en un único módulo de participación general, lo que permitiría al protocolo capturar ingresos de transacciones iniciadas por bots y otras interacciones directas con los contratos inteligentes del protocolo.

De la teoría a la implementación: Poniendo el método en práctica

Volviendo a examinar la pila de tokens de la aplicación en mayor detalle. Para que un protocolo facilite el staking en el frontend, necesitaría establecer un contrato inteligente de registro al que los frontends tendrían que registrarse.

1. Cada frontend o API puede agregar un registro TXT especial al registro DNS de su dominio como el Integración de ENS DNSEste registro TXT contiene la clave pública de un par de claves que el frontend genera una vez, llamado el certificado.

1. El cliente frontend puede llamar a una función de registro() y demostrar que es dueño de su nombre de dominio. Se almacena un mapeo del dominio a la clave pública del certificado, y viceversa.
2. Cuando se crean transacciones a través del cliente, también firma la carga útil de la transacción con su clave pública del certificado. Estos se pasan a los contratos inteligentes de la aplicación en un paquete.
3. Los contratos inteligentes de la aplicación validan el certificado, comprueban que corresponde al cuerpo tx correcto y ha sido registrado. Si es así, se procesa la transacción. Las tarifas generadas por la transacción se envían luego a un contrato de FeeCollector junto con el nombre de dominio (del registro).
4. El FeeCollector permite a los curadores, usuarios, validadores y otros apostar tokens directamente a 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 la cantidad de tiempo que han estado apostados. Las implementaciones populares de extracción de liquidez se pueden utilizar como punto de partida para esta lógica de contrato.
5. Los usuarios que hayan apostado a los curadores (o directamente a los contratos de gestión de tarifas) pueden luego retirar la parte proporcional de la tarifa según la cantidad de tokens de la aplicación apostados para el dominio. La arquitectura podría ser similar a MetaMorpho/Morpho Azul.

Esto se podría introducir sin aumentar la carga de gobernanza de un DAO de una aplicación. De hecho, las responsabilidades de gobernanza podrían reducirse, ya que el interruptor de tarifa podría activarse permanentemente para todas las transacciones facilitadas por el protocolo, eliminando así cualquier control del DAO sobre el modelo económico del protocolo.

Consideraciones adicionales basadas en el tipo de aplicación

Si bien estos principios se aplican ampliamente a los modelos económicos de tokens de aplicación, puede haber otras consideraciones de tarifas basadas en el tipo de aplicación: aplicaciones construidas en capas 1 o capas 2, cadenas de aplicaciones y aplicaciones construidas utilizando rollups.

Consideraciones para aplicaciones L1/L2

Las aplicaciones en blockchain de capa 1 o capa 2 tienen contratos inteligentes implementados directamente en la cadena. Se cobrarán tarifas cuando los usuarios interactúen con los contratos inteligentes de las aplicaciones. Por lo general, esto ocurre a través de una interfaz fácil de usar (como una aplicación o sitio web) que sirve como interfaz entre un usuario minorista y los contratos inteligentes subyacentes. En ese caso, cualquier tarifa se originaría en esa interfaz. El ejemplo anterior sobre app.xyz ilustra cómo podría funcionar un sistema de tarifas para una aplicación de capa 1.

En lugar de depender de curadores para filtrar las tarifas de frontend, las aplicaciones también podrían optar por un enfoque de lista blanca o lista negra para los frontends que contribuyen a las tarifas de red. Una vez más, el propósito aquí sería asegurar que los titulares de tokens y el protocolo en general no estén obteniendo beneficios de actividades ilícitas y estén siguiendo las leyes y regulaciones específicas de la jurisdicción.

En el enfoque de lista blanca, la aplicación publicaría un conjunto de reglas para los frontends, crearía un registro de aquellos frontends que siguen las reglas, emitiría un certificado a los frontends que opten por participar y requeriría que los frontends apuesten tokens para recibir una parte de las tarifas de la aplicación. Si los frontends no siguen estas reglas, serían reducidos, y su certificado de contribuciones de tarifas sería eliminado.

En el enfoque de lista negra, las aplicaciones no tendrían que crear reglas, pero el lanzamiento de un frontend para la aplicación no sería sin permiso. En cambio, la aplicación requeriría que cualquier frontend entregue una opinión de un bufete de abogados de que el frontend cumple con su jurisdicción antes de habilitar que el frontend use la aplicación. Una vez recibida la opinión, la aplicación emitiría un certificado al frontend para contribuciones de tarifas que solo se eliminarían si la aplicación recibe aviso de un regulador de que el frontend no cumple con los requisitos.

El pipeline de tarifas reflejaría los ejemplos proporcionados en las secciones anteriores.

Ambos enfoques aumentan significativamente la carga de la gobernanza descentralizada, ya que exigen 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 externalizar esta carga de cumplimiento a un curador.

Consideraciones para las appchains

Las Appchains son blockchains específicos de aplicaciones con validadores que solo funcionan para esa aplicación.

A cambio de su trabajo, esos validadores reciben un pago. A diferencia de las blockchains de Capa 1 donde los validadores a menudo son recompensados a través de la emisión inflacionaria de tokens, algunas appchains (dYdX) en cambio transfieren las tarifas de los clientes a los validadores.

En este modelo, los titulares de tokens deben apostar a los validadores para recibir recompensas. Los validadores se convierten en los módulos de apuesta seleccionados.

Este conjunto de trabajo es diferente de un validador de la Capa 1. Los validadores de Appchain liquidan transacciones específicas de una aplicación específica. Debido a esta diferencia, los validadores de Appchain pueden asumir un mayor grado de riesgo legal con respecto a la actividad subyacente que están facilitando. Como resultado, los protocolos deben otorgar a los validadores la libertad de realizar el trabajo que pueden realizar de acuerdo con las leyes de su jurisdicción y su propio nivel de comodidad. Es importante destacar que esto se puede hacer sin poner en peligro la libertad de permisos de la Appchain ni someterla a un riesgo significativo de censura, siempre y cuando su conjunto de validadores esté descentralizado geográficamente.

La arquitectura para las appchains que deseen aprovechar los beneficios de la trazabilidad de las tarifas sería similar a las aplicaciones de Capa 1 hasta el pipeline de tarifas. Pero los validadores podrían utilizar la asignación de frontends para determinar qué frontends desean procesar transacciones. Las tarifas para cualquier transacción dada irían al conjunto activo de validadores, y los validadores inactivos que optaron por no participar se perderían dichas tarifas. Desde una perspectiva de tarifas, el validador realiza la misma función que los curadores del módulo de participación mencionados anteriormente, y los apostadores de esos validadores podrían asegurarse de que no están recibiendo ingresos de ninguna actividad ilícita. Los validadores también podrían elegir un curador para determinar qué frontends cumplen con las normativas por jurisdicción.

Consideraciones para rollups de aplicaciones

Los rollups tienen su propio espacio de bloques, pero pueden heredar la seguridad de otra cadena. Hoy en día, la mayoría de los rollups tienen un único secuenciador que se encarga de secuenciar e incluir transacciones, aunque las transacciones se pueden enviar directamente a la capa 1 a través de un proceso llamado "inclusión forzada.”

Si estos rollups son específicos de la aplicación y consagran a su secuenciador como el único validador, las tarifas generadas por las transacciones incluidas por ese secuenciador pueden ser dispersadas a los apostadores basándose en el conjunto curado de frontends compatibles o como un fondo general.

Si los rollups descentralizan su conjunto de secuenciadores, los secuenciadores se convierten en los módulos de staking curados de facto y el canal de comisiones reflejaría el de las appchains. Los secuenciadores reemplazan a los validadores para la distribución de comisiones, y cada secuenciador puede tomar sus propias decisiones sobre de qué frontends aceptar comisiones.

Si bien existen muchos modelos posibles para tokens de aplicaciones, proporcionar piscinas de participación curadas es un camino a seguir que ayuda a abordar los desafíos extrínsecos únicos de las aplicaciones. Al reconocer los desafíos intrínsecos y extrínsecos que enfrentan las aplicaciones, los fundadores pueden diseñar mejores modelos de tokens de aplicaciones desde cero para su proyecto.

Descargo de responsabilidad：

1. Este artículo se reproduce de [Gatea16zcrypto]. Todos los derechos de autor pertenecen al autor original [Mason HallPorter SmithMiles Jennings y Ross Shuel]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Renuncia de responsabilidad de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.