Título original: Un nuevo modelo financiero para tokens de aplicaciones: cómo generar flujos de efectivo
Fuente original: a16z
Compilación original: Félix, PANews
Para tokens de infraestructura como L1 o L2, el modelo económico está bien desarrollado y comprendido, arraigado en la oferta y la demanda de espacio de bloques. Pero para los tokens de aplicación (protocolos de contratos inteligentes que implementan servicios en blockchain), el modelo económico aún se está perfeccionando.
El modelo de negocio de un token de aplicación debe ser tan expresivo como su software subyacente. Con este fin, este artículo presenta el concepto de flujo de caja de los tokens de aplicación. Este enfoque permite que las aplicaciones creen modelos flexibles y flexibles donde los usuarios pueden elegir cómo ser recompensados por el valor que brindan. Este enfoque fomenta un mayor cumplimiento al incurrir en tarifas por actividades legítimas sujetas a requisitos regulatorios en diferentes jurisdicciones. Además, se puede maximizar el valor del protocolo fomentando al mismo tiempo una gobernanza mínima.
Los principios compartidos en este artículo se aplican a todas las aplicaciones Web3, desde DeFi hasta aplicaciones sociales descentralizadas, redes DePIN y todo lo demás.
Desafíos que enfrenta el modelo token
Los tokens de infraestructura están sujetos a la oferta y la demanda inherentes: a medida que aumenta la demanda, la oferta disminuye y el mercado se ajusta en consecuencia. Esta base económica nativa para muchos tokens de infraestructura se ve acelerada por la Propuesta de mejora de Ethereum 1559 (EIP-1559), que implementa un mecanismo de grabación para todas las transacciones de Ethereum. No existe un modelo similar al EIP-1559 para tokens de aplicaciones, aunque hay intentos esporádicos de comprarlos y quemarlos.
Las aplicaciones son usuarios del espacio en bloque, no proveedores, por lo que no pueden depender de las tarifas de gas de otros que usan su espacio en bloque. Por eso necesitan desarrollar su propio modelo económico.
Aquí también existen algunos desafíos legales: debido a la naturaleza genérica de las transacciones típicas de blockchain y los mecanismos de programación que utilizan, los modelos económicos de tokens de infraestructura son menos susceptibles a riesgos legales. Pero en el caso de los modelos económicos de tokens de aplicación, las aplicaciones involucradas pueden depender de actividades regulatorias y pueden requerir intermediarios para gobernar a los poseedores de tokens, lo que hace que la economía sea más compleja. Por ejemplo, un intercambio descentralizado que facilita el comercio de derivados (una actividad altamente regulada en los Estados Unidos) es completamente diferente de, digamos, Ethereum.
Estos desafíos internos y externos significan que los tokens de aplicación requieren diferentes modelos económicos. Teniendo esto en cuenta, este artículo propone una posible solución: una forma de diseñar protocolos que compensen a los poseedores de tokens de aplicación y al mismo tiempo maximicen los ingresos del protocolo, incentivan el cumplimiento normativo e incorporan servicios de minimización de la gobernanza. El objetivo es simple: proporcionar tokens de aplicación con la misma base económica a través del flujo de caja que ya tienen muchos tokens de infraestructura.
La solución se centra en resolver tres problemas que enfrentan los tokens de aplicación:
· Desafíos de gobernanza
· Desafíos de distribución de valor
· Desafíos regulatorios
Desafíos de gobernanza
Los tokens de aplicación suelen tener derechos de gobernanza y la existencia de una DAO puede introducir incertidumbres que los tokens de infraestructura no enfrentan. Para las DAO con operaciones importantes en los EE. UU., pueden surgir riesgos si la DAO controla los ingresos del protocolo o actúa como intermediario para las actividades económicas del protocolo y programa dichas actividades. Para evitar estos riesgos, los proyectos pueden eliminar el control de la DAO minimizando la gobernanza. Para las DAO que no pueden hacer esto, la nueva Asociación Descentralizada No Incorporada 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.
Desafío de distribución de valor
Las aplicaciones deben diseñar cuidadosamente mecanismos para distribuir valor a los poseedores de tokens. La combinación de derechos económicos y de voto puede generar preocupaciones en virtud de las leyes de valores estadounidenses, especialmente con mecanismos simples y directos como el prorrateo y la compra y quema de tokens. Estos mecanismos se parecen a los dividendos y las recompras de acciones, y podrían socavar los argumentos de que los tokens deberían estar sujetos a un marco regulatorio diferente al de las acciones.
Los proyectos deben explorar modelos de partes interesadas, recompensando a los poseedores de tokens por sus contribuciones de una manera que beneficie al proyecto. Muchos proyectos fomentan la participación activa, incluida la operación de interfaces (Liquity), la participación en protocolos (Goldfinch) y la participación de garantías como parte de módulos de seguridad (como Aave). El espacio de diseño aquí está abierto, pero un buen punto de partida es mapear a todas las partes interesadas en el proyecto, identificar qué comportamientos se debe alentar a cada uno de ellos a adoptar y decidir qué valor general puede crear el protocolo a través de este incentivo.
Para simplificar, este artículo asumirá un modelo de compensación simple que recompensa a los poseedores de tokens por participar en la gobernanza.
desafíos regulatorios
Las aplicaciones que facilitan actividades reguladas también deben ser cautelosas al diseñar mecanismos de valor agregado para los poseedores de tokens. Si dichos mecanismos obtienen valor de una interfaz o API que no cumple con las leyes aplicables, los poseedores de tokens pueden beneficiarse de actividades ilegales.
La mayoría de las soluciones propuestas a este problema se centran en limitar la adición de valor a las actividades permitidas en Estados Unidos; por ejemplo, cobrar tarifas de protocolo sólo para los fondos de liquidez que involucran ciertos activos. Esto somete los proyectos a enfoques regulatorios y socava la propuesta de valor de los protocolos de software autónomos globales. También socava directamente los esfuerzos por minimizar la gobernanza. No es apropiado que una DAO determine qué estrategia de tarifas es efectiva desde una perspectiva de cumplimiento regulatorio.
En un mundo ideal, los proyectos podrían cobrar tarifas en cualquier jurisdicción que permita dicha actividad sin tener que depender de la DAO para determinar qué está permitido. La solución no es exigir el cumplimiento a nivel de protocolo, sino garantizar que las tarifas incurridas por un protocolo solo se transfieran si el front-end o API que genera esas tarifas cumple con las leyes y regulaciones aplicables en la región donde se encuentra el front-end. se encuentra. Si Estados Unidos prohíbe las tarifas sobre una determinada transacción facilitada por una aplicación, podría reducir el valor económico del token de la aplicación a cero, incluso si dicha actividad está permitida en otros países del mundo. La flexibilidad en la acumulación y asignación de tarifas equivale en última instancia a la resiliencia frente a las presiones regulatorias.
Una cuestión central: las tasas retroactivas
La trazabilidad de las tarifas es fundamental para abordar los riesgos potenciales que surgen desde el principio del incumplimiento sin introducir riesgos de escrutinio o licencia del acuerdo. Con la trazabilidad, las aplicaciones pueden garantizar que cualquier tarifa que reciban los poseedores de tokens provenga únicamente de interfaces legales y conformes dentro de la jurisdicción del poseedor de tokens. Si las tarifas no son rastreables, no hay forma de proteger a los poseedores de tokens de la acumulación de valor en una interfaz que no cumple con las normas, lo que podría poner a los poseedores de tokens en riesgo.
Para que los gastos sean rastreables, los protocolos se pueden diseñar en dos pasos:
· Paso 1: Identificar qué front-end incurrieron en costos
· Paso 2: Enrutar tarifas a diferentes grupos según una lógica personalizada
Interfaz de mapeo
La trazabilidad de las tarifas requiere una asignación uno a uno de los dominios a los pares de claves públicas/privadas. Sin este mapeo, una interfaz maliciosa podría falsificar transacciones y pretender ser enviadas desde un dominio honesto. La criptografía permite que una interfaz "registrada" registre de forma inmutable una asignación de dominio a clave pública, demuestre que el dominio realmente controla esa clave pública y utilice dicha clave privada para firmar transacciones. Esto nos permite atribuir transacciones (y por tanto tarifas) a un dominio determinado.
Cargos de ruta
Una vez que se puede rastrear la fuente de las tarifas, el protocolo puede determinar cómo distribuir estas tarifas para que a los titulares de tokens no se les cobren tarifas por transacciones ilegales y no aumenten la carga de gobernanza descentralizada de la DAO. Para ayudar a ilustrar esto, podemos considerar varios diseños posibles para aplicar la apuesta de tokens, desde un grupo de apuestas por interfaz hasta un único grupo de apuestas compartido por todas las interfaces.
En su configuración más simple, las tarifas de cada interfaz se pueden enviar a un módulo de participación específico de la interfaz independiente. Al elegir en qué interfaz apostar, los poseedores de tokens podrán decidir qué tarifas cobrar y evitar cualquier tarifa que los ponga en riesgo legal. Por ejemplo, los poseedores de tokens solo pueden apostar en módulos relacionados con interfaces que hayan sido aprobados por todas las autoridades reguladoras de Europa. Si bien este diseño parece simple, en realidad es bastante complejo. Dado que 50 interfaces diferentes tienen potencialmente 50 grupos de participación, la dilución de las tarifas podría afectar negativamente al valor del token.
Por otro lado, las tarifas para cada fase inicial se pueden agrupar, pero esto va en contra del propósito de la trazabilidad de las tarifas. Si se agrupan todos los costos, no hay forma de diferenciar entre los costos de una fase inicial que cumple y otra que no cumple. Los poseedores de tokens se verán obligados a elegir entre no cobrar ninguna tarifa y mantener una participación en un grupo donde se beneficiarán de las actividades ilegales de los front-ends que no cumplen con las normas en su jurisdicción. — —Esta opción podría impedir que muchos poseedores de tokens participen, o podría revertir el sistema a su diseño subóptimo actual, es decir, la DAO necesita evaluar dónde se pueden aplicar tarifas.
Resolver problemas de trazabilidad de gastos a través de la gestión
Estas complejidades pueden abordarse mediante la gestió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 cualquier interfaz puede tener su propio módulo de participación; una interfaz para este protocolo se llama 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 que se origina en app.xyz genera cargos de protocolo. App.xyz tiene su propio módulo de apuesta, al que los poseedores de tokens pueden apostar sus tokens directamente, o a los administradores que quieran seleccionar individualmente una canasta de interfaces que consideren compatibles. Estos apostadores de tokens recibirán beneficios en forma de tarifas del conjunto de interfaces que apuesten. Si una interfaz genera $100 en tarifas y 100 entidades apuestan 1 token cada una, entonces cada entidad tiene derecho a $1. El administrador puede cobrar inicialmente una tarifa de servicio. En el futuro, los gobiernos podrán certificar el cumplimiento inicial dentro de sus jurisdicciones en cadena para ayudar a proteger a los consumidores, con el beneficio adicional de automatizar la administración.
Un riesgo potencial con este modelo es que los front-ends que no cumplen pueden tener costos operativos más bajos porque no tienen la sobrecarga administrativa de los front-ends que sí cumplen. También pueden diseñar modelos para recuperar las tarifas iniciales para los comerciantes. Dos factores mitigan este riesgo. En primer lugar, la mayoría de los usuarios en realidad quieren una interfaz de cumplimiento que cumpla con las leyes y regulaciones locales, especialmente para las grandes instituciones reguladas. En segundo lugar, para las interfaces que no cumplen las normas y que violan repetidamente las reglas y ponen en peligro la viabilidad de la aplicación, la gobernanza puede utilizarse como último recurso o ejercer "poder de veto" para evitar malos comportamientos.
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 integral, lo que permitirá que el protocolo genere ingresos a partir de transacciones iniciadas por bots y otras interacciones directas con los contratos inteligentes del protocolo.
De la teoría a la implementación: poner los métodos en práctica
Una revisión detallada de la pila de tokens de la aplicación. Para que un protocolo facilite la participación en el front-end, requiere el establecimiento de un contrato inteligente de registro que el front-end debe registrar.
Cada interfaz o API puede agregar registros TXT especiales a los registros DNS de su dominio, como la integración DNS de ENS. Este registro TXT contiene la clave pública del par de claves generada una vez por el front-end, llamado certificado.
Luego, el cliente front-end puede llamar a la función registrarse() y demostrar que es propietario de su nombre de dominio. El sistema almacena el mapeo de dominios a claves públicas de certificados y viceversa.
Cuando se crea una transacción a través del cliente, también firma la carga útil de la transacción utilizando su clave pública de certificado. Estos se pasarán al contrato inteligente de la aplicación en forma de paquete.
El contrato inteligente de la aplicación verifica el certificado, verifica que corresponda al principal de transmisión correcto y 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 los administradores, usuarios, validadores, etc. apostar tokens directamente en un único dominio o conjunto de dominios. Estos contratos deben realizar un seguimiento de la cantidad de tokens apostados en cada dominio, la participación apostada de cada dirección y la duración de la apuesta. Las implementaciones populares de minería de liquidez pueden usarse como punto de partida para esta lógica contractual.
Aquellos usuarios que hayan apostado al administrador (o directamente al contrato de administración de tarifas) pueden retirar una parte proporcional de las tarifas según la cantidad de tokens de aplicación prometidos al dominio. La arquitectura puede ser similar a MetaMorpho/Morpho Blue.
La introducción de esta característica no aumentará la carga de gobernanza de la aplicación DAO. De hecho, las responsabilidades de gobernanza se pueden reducir porque el cambio de tarifas se puede activar permanentemente para 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, existen otras tarifas a considerar según el tipo de aplicación: aplicaciones creadas dentro o fuera de L2, cadenas de aplicaciones y aplicaciones creadas mediante paquetes acumulativos.
Aplicación L1/L2
Las aplicaciones en la cadena de bloques L1/L2 implementan contratos inteligentes directamente en la cadena. Las tarifas se cobran cuando los usuarios interactúan con el contrato inteligente de la aplicación. Normalmente, esto sucede a través de una interfaz fácil de usar (como una aplicación o un sitio web) que actúa como interfaz entre los inversores minoristas y el contrato inteligente subyacente. En este caso, todos los cargos se originarán en ese front-end. El ejemplo anterior para app.xyz ilustra cómo funciona el sistema de tarifas para aplicaciones L1.
Además de depender de los administradores para filtrar los cargos iniciales, las aplicaciones también pueden emplear un enfoque de lista blanca o lista negra para filtrar los cargos iniciales que aumentan los cargos de la red. Nuevamente, el propósito aquí es garantizar que los poseedores de tokens y todo el protocolo no se beneficien de actividades ilegales y cumplan con las leyes y regulaciones de la jurisdicción específica.
En el enfoque de la lista blanca, la aplicación publicaría un conjunto de reglas para los front-ends, crearía un registro de front-ends que cumplan con las reglas, emitiría certificados para los front-ends que opten por participar y requeriría que los front-ends apostaran tokens. para recibir una parte de las tarifas de solicitud. Si un front-end no cumple con las reglas, se eliminará y se eliminará su certificado de contribución de tarifas.
En el enfoque de lista negra, la aplicación no tiene que crear ninguna regla, pero el inicio de la interfaz de la aplicación no es sin permiso. En cambio, la aplicación requerirá que cualquier front-end proporcione una opinión de un bufete de abogados que certifique que el front-end cumple con su jurisdicción antes de permitirle utilizar la aplicación. Una vez recibidos los comentarios, la aplicación emitirá un certificado de contribución de tarifas al frontend, que solo se eliminará si la aplicación recibe una notificación del regulador de que el frontend no cumple.
El canal de gastos es similar a los ejemplos proporcionados en las secciones anteriores.
Ambos enfoques aumentan significativamente la carga de la gobernanza descentralizada, al requerir 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 es mejor subcontratar esta carga de cumplimiento a los gerentes.
cadena de aplicaciones
Una cadena de aplicaciones es una cadena de bloques específica de una aplicación cuyos validadores son específicos de esa aplicación.
A cambio de su trabajo, estos validadores reciben una compensación. A diferencia de las cadenas de bloques L1, donde los validadores generalmente son recompensados mediante la emisión de tokens a través de la inflación, algunas cadenas de aplicaciones (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 del verificador L1. Los validadores de la cadena de aplicaciones procesan transacciones específicas de aplicaciones específicas. Debido a esta diferencia, los validadores de Lisk pueden asumir un mayor grado de riesgo legal relacionado con las actividades subyacentes que facilitan. Por lo tanto, el protocolo debe otorgar a los validadores la libertad de realizar el trabajo que puedan realizar de acuerdo con las leyes de su jurisdicción y su propia voluntad. Es importante destacar que esto se puede hacer sin poner en peligro la naturaleza sin permiso de la cadena de bloques ni exponerla a un riesgo significativo de censura, siempre que su conjunto de validadores esté disperso geográficamente.
Las cadenas de aplicaciones que deseen aprovechar la trazabilidad de los gastos tendrán una arquitectura similar a las aplicaciones L1. Pero los validadores podrán utilizar el mapeo de frontend para determinar desde qué frontend quieren que se procesen las transacciones. Las tarifas de cualquier transacción determinada irán al conjunto de validadores activos, mientras que los validadores inactivos que decidan no participar no recibirán dichas tarifas. Desde la perspectiva de las tarifas, los validadores realizan las mismas funciones que los administradores del módulo de participación discutidos anteriormente, y los participantes de estos validadores tienen la seguridad de que no recibirán ingresos de ninguna actividad ilegal. Los validadores también pueden elegir un delegado para determinar qué interfaces cumplen con las normas en cada jurisdicción.
Rollups
Los rollups tienen su propio espacio de bloque pero pueden heredar la seguridad de otra cadena. La mayoría de los Rollups actuales tienen un único secuenciador. Si estos Rollups son específicos de una aplicación y tienen a su ordenante como ú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 Rollups descentraliza su conjunto de ordenantes, los ordenantes se convertirán en los módulos de participación destacados de facto y los canales de cobro serán los mismos que los de AppChain. Los ordenantes reemplazan a los validadores para la distribución de tarifas, y cada ordenante puede decidir por sí mismo desde qué interfaz aceptar tarifas.
Si bien existen muchos modelos posibles para tokens de aplicaciones, proporcionar grupos de participación seleccionados puede ayudar a abordar desafíos externos exclusivos de las aplicaciones. Al reconocer los desafíos internos y externos que enfrentan las aplicaciones, los fundadores pueden diseñar mejor modelos de tokens de aplicaciones para sus proyectos desde cero.
Enlace original
