a16z: ¿Cómo generan flujo de caja los tokens de protocolo?

Autor original: a16z Crypto

Traducción original: Pzai, Foresight News

En el caso de los tokens de infraestructura (que corresponden a las redes de capa 1 o a partes adyacentes de la pila de computación, como la capa 2), los modelos económicos están bien desarrollados y se comprenden bien, y se basan en la oferta y la demanda del espacio de bloques. Pero en el caso de los tokens de protocolo (App Tokens), es decir, los contratos inteligentes que implementan servicios en la cadena de bloques y heredan derechos en “negocios distribuidos”, la construcción de modelos económicos aún se está explorando.

El modelo de negocio de un token de protocolo debe ser tan expresivo como su software subyacente. Con este fin, introdujimos flujos de efectivo para tokens de protocolo, un enfoque que permite a los protocolos crear modelos flexibles y flexibles en los que los usuarios pueden elegir cómo ser recompensados en función del valor que brindan. Este enfoque genera tarifas a partir de actividades de cumplimiento basadas en requisitos regulatorios en diferentes jurisdicciones, lo que fomenta un mayor cumplimiento. También maximiza el valor generado por el protocolo al tiempo que fomenta una gobernanza mínima.

Los principios que compartimos aquí se aplican a todos los protocolos Web3, desde DeFi hasta redes sociales descentralizadas, DePIN y todas las demás.

Desafíos de los modelos de tokens

Los tokens de infraestructura están sujetos a una oferta y una demanda intrínsecas: a medida que aumenta la demanda, la oferta disminuye y el mercado se ajusta en consecuencia. La economía nativa de muchos tokens de infraestructura se aceleró con la EIP-1559, que implementó una quema de tarifa base para todas las transacciones de Ethereum. Sin embargo, a pesar de los intentos esporádicos de modelos de compra y quema, no ha habido ningún intento comparable a la EIP-1559 para los tokens de protocolo.

Los protocolos son usuarios del espacio de bloques, no proveedores, por lo que no pueden depender del cobro de tarifas de gas a otros usuarios de su espacio de bloques. Por eso necesitan desarrollar sus propios modelos económicos.

También existen algunos desafíos legales: la economía de tokens de infraestructura es menos susceptible al riesgo legal debido a la naturaleza genérica de las transacciones típicas de blockchain y los mecanismos programáticos que utilizan. Pero en el caso de la economía de tokens de protocolo, los protocolos involucrados pueden depender de la facilitación de actividades de cumplimiento y pueden requerir la participación de los titulares de tokens de gobernanza, lo que hace que su economía sea más complicada. Los intercambios descentralizados que facilitan el comercio de derivados son una actividad altamente regulada en los Estados Unidos, muy diferente de, por ejemplo, Ethereum.

La combinación de estos desafíos intrínsecos y extrínsecos significa que los tokens de protocolo requieren un modelo económico diferente. Con esto en mente, proponemos una posible solución: un enfoque para diseñar protocolos que compense a los poseedores de tokens de protocolo por sus servicios mientras maximiza los ingresos del protocolo, incentiva el cumplimiento normativo e incorpora la minimización de la gobernanza. Nuestro objetivo es simple: proporcionar a los tokens de protocolo la misma base económica a través del flujo de efectivo que muchos tokens de infraestructura ya tienen.

Nuestra solución se centra en abordar tres problemas que enfrentan los tokens de protocolo relacionados con: desafíos de gobernanza, desafíos de distribución de valor y desafíos de actividad de cumplimiento.

Desafíos de gobernanza

Los tokens de protocolo suelen tener derechos de gobernanza, y la existencia de una organización autónoma descentralizada (DAO) puede introducir incertidumbres que los tokens de infraestructura no enfrentan. Para las DAO con una presencia sustancial en los EE. UU., pueden surgir riesgos si la DAO controla los ingresos del protocolo o interviene en las actividades económicas del protocolo y hace que dichas actividades sean programáticas. Para evitar estos riesgos, los proyectos pueden eliminar el control de las DAO minimizando la gobernanza. Para las DAO que no pueden hacer esto, la nueva Asociación sin fines de lucro descentralizada no incorporada (DUNA) de Wyoming proporciona una entidad legal descentralizada que puede ayudar a mitigar estos riesgos y cumplir con las leyes fiscales aplicables.

El desafío de la distribución del valor

Los protocolos también deben actuar con cuidado al diseñar mecanismos para distribuir valor a los tenedores de tokens. La combinación de derechos de voto y derechos económicos puede generar inquietudes en relación con las leyes de valores de Estados Unidos, especialmente en el caso de mecanismos simples y directos como las distribuciones prorrateadas y las compras y quemas de tokens. Estos mecanismos pueden parecer similares a los dividendos y las recompras de acciones, y pueden socavar el argumento de que los tokens deberían recibir un marco regulatorio diferente al de las acciones.

En cambio, los proyectos deberían explorar el capitalismo de las partes interesadas, es decir, recompensar a los poseedores de tokens por sus contribuciones a un proyecto de una manera que beneficie al proyecto. Muchos proyectos incentivan la participación de suma positiva, incluidas las operaciones de front-end (Liquity), la participación en el protocolo (Goldfinch) y la participación en el colateral como parte de un módulo de seguridad (Aave). El espacio de diseño aquí es abierto, pero un buen punto de partida es trazar un mapa de todas las partes interesadas en el proyecto, determinar qué comportamientos se deben alentar para cada uno de ellos y decidir qué valor general puede crear el protocolo a través de dichos incentivos.

Para simplificar, en esta publicación asumiremos un modelo de compensación simple que recompensa a los poseedores de tokens por participar en la gobernanza, incluso si existen otros esquemas.

Los desafíos de las actividades de cumplimiento

Los protocolos que facilitan actividades que cumplen con las normas también deben tener cuidado al diseñar mecanismos de acumulación de valor para los poseedores de tokens. Si dichos mecanismos generan valor a partir de una interfaz o API que no funciona de conformidad con la ley aplicable, los poseedores de tokens podrían estar obteniendo beneficios de actividades ilegales.

La mayoría de las soluciones propuestas a este problema se centran en limitar la acumulación de valor a las actividades permitidas en los EE. UU. (por ejemplo, cobrar tarifas de protocolo solo por fondos de liquidez que involucren ciertos activos). Esto somete a los proyectos al mínimo común denominador de los enfoques regulatorios y socava la propuesta de valor de los protocolos de software globalmente autónomos. También socava directamente los esfuerzos por minimizar la gobernanza. Determinar qué estrategias de cobro de tarifas son efectivas desde una perspectiva de cumplimiento regulatorio no es una tarea apropiada para una DAO.

En un mundo ideal, los proyectos podrían cobrar tarifas por la actividad en cualquier jurisdicción que permita esa actividad, sin tener que depender de una DAO para determinar qué está permitido. La solución no es exigir el cumplimiento de las regulaciones a nivel de protocolo, sino garantizar que las tarifas que genera un protocolo solo se transfieran si el front-end o la API que las origina cumple con las leyes y regulaciones aplicables de la ubicación del front-end. Si Estados Unidos hiciera ilegal cobrar tarifas por un cierto tipo de transacción facilitada por un protocolo, esto podría reducir el valor económico de los tokens del protocolo a cero, incluso si esa actividad está perfectamente permitida en todos los demás países del mundo. La flexibilidad en la forma en que se acumulan y distribuyen las tarifas equivale en última instancia a la resiliencia frente a la presión regulatoria.

Una cuestión central: el rastreo de costes

La trazabilidad de las tarifas es fundamental para abordar los posibles riesgos derivados de los front-end que no cumplen con las normas sin introducir el riesgo de censura o hacer que el protocolo no tenga permisos. A través de la trazabilidad, los protocolos pueden garantizar que las tarifas en las que incurran los titulares de tokens solo provengan de front-end que cumplan con las normas legales en la jurisdicción donde se encuentra el titular del token. Si las tarifas no son rastreables, no se puede atribuir a los titulares de tokens el valor generado por los front-end que no cumplen con las normas (es decir, las tarifas cobradas por los front-end que no cumplen con las normas), lo que puede poner en riesgo a los titulares de tokens.

Para que las tarifas sean rastreables, el protocolo puede diseñarse utilizando un sistema de participación de tokens en dos pasos.

• Paso 1: Determinar qué extremo frontal genera las cargas

• Paso 2: Distribuir las tarifas a diferentes grupos según una lógica personalizada

Mapeo del front-end

La trazabilidad de las tarifas requiere una asignación uno a uno de los dominios a los pares de claves públicas y privadas. Sin esta asignación, un frontend malicioso podría falsificar transacciones y simular que se enviaron desde un dominio honesto. La criptografía nos permite registrar frontends, registrar de forma inmutable la asignación de dominios a claves públicas, demostrar que el dominio realmente controla esa clave pública y firmar transacciones con dicha clave privada. Esto nos permite atribuir transacciones, y por lo tanto tarifas, a un dominio determinado.

Tarifas de ruta

Una vez que se pueda rastrear la fuente de las tarifas, el protocolo puede determinar cómo distribuirlas de manera que se proteja a los poseedores de tokens de tarifas de transacciones ilegítimas, pero que tampoco aumente la carga de gobernanza descentralizada de la DAO. Para ayudar a ilustrar este punto, considere la gama de posibles diseños para el staking de tokens del protocolo, que van desde un pool de staking por front-end hasta un pool de staking para todos los front-end.

En su estructura más simple, las tarifas de cada frontend se pueden enrutar a un solo módulo de staking frontend específico. Al elegir qué frontend participar, el titular de un token podrá decidir qué tarifas recibirá y evitar tarifas que lo pongan en riesgo legal. Por ejemplo, un titular de token solo puede participar en módulos asociados con un frontend que haya recibido todas las aprobaciones regulatorias en Europa. Si bien este diseño parece simple, en realidad es bastante complejo. Con 50 frontends diferentes que potencialmente tienen 50 grupos de staking, la dilución de las tarifas podría tener un efecto adverso en el valor del token.

Por otra parte, las tarifas de cada front-end podrían agruparse, pero esto frustraría el propósito de la trazabilidad de las tarifas. Si se agruparan todas las tarifas, sería imposible distinguir entre las tarifas de front-end que cumplen con las normas y las que no: una manzana podrida puede echar a perder todo el conjunto. Los poseedores de tokens se verían obligados a elegir entre no recibir tarifas o tener una participación en un fondo común en el que se beneficiarían de las actividades ilegales de los front-end que no cumplen con las normas en su jurisdicción, una opción que podría disuadir a muchos poseedores de tokens de participar, o podría revertir el sistema al diseño subóptimo actual en el que la DAO debe evaluar dónde se pueden cobrar las tarifas.

Resolver el problema de trazabilidad de gastos mediante la curación

Estas complejidades se pueden resolver con la curación. Considere un protocolo de contrato inteligente sin permisos que tenga tarifas y tokens. Cualquiera puede crear una interfaz para el protocolo, y cualquier interfaz puede tener su propio módulo de participación. Llamemos a una interfaz para este protocolo app.xyz.

App.xyz puede seguir reglas de cumplimiento específicas para las jurisdicciones en las que opera. La actividad de protocolo que se origina en app.xyz genera tarifas de protocolo. App.xyz tiene su propio módulo de staking, al que los poseedores de tokens pueden hacer staking de sus tokens directamente, o con curadores que quieran seleccionar individualmente una canasta de frontends que consideren compatibles. Estos stakers de tokens recibirán un rendimiento en forma de tarifas del conjunto de frontends que hagan staking. Si un frontend genera $100 en tarifas, y 100 entidades hacen staking de 1 token cada una, cada entidad tiene derecho a $1. Los curadores pueden cobrar tarifas inicialmente por sus servicios. En el futuro, los gobiernos pueden realizar certificaciones en cadena del cumplimiento de los frontends 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 de este modelo es que los front-end que no cumplen con las normas pueden tener costos operativos más bajos porque carecen de los gastos administrativos de los front-end que sí las cumplen. También pueden diseñar modelos para reciclar las tarifas de front-end a los comerciantes para incentivar aún más sus soluciones alternativas. Dos factores pueden mitigar este riesgo. En primer lugar, la mayoría de los usuarios realmente esperan que los front-end que cumplen con las normas cumplan con las leyes y regulaciones locales, y esto es especialmente cierto para las grandes instituciones reguladas. En segundo lugar, para los front-end que no cumplen con las normas que rompen repetidamente y ponen en peligro la viabilidad del protocolo, la gobernanza puede desempeñar un papel importante como último recurso o poder de veto para detener el mal comportamiento.

Finalmente, todas las tarifas de transacción que no se inicien a través de la interfaz de registro se depositarán en un módulo de staking 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 el enfoque en práctica

Volvamos a analizar la pila de tokens del protocolo con más detalle. Para que un protocolo facilite el staking en el frontend, necesitaría crear un contrato inteligente de registro en el que el frontend tendría que registrarse.

• Cada interfaz o API puede agregar un registro TXT especial a los registros DNS de sus dominios, como la integración DNS de ENS. Este registro TXT contiene la clave pública de un par de claves generado una vez por la interfaz, llamado certificado.

• El cliente front-end puede luego llamar a la función de registro y demostrar que es propietario de su nombre de dominio, almacenando la asignación del dominio a la clave pública del certificado y viceversa.

• Cuando se crea una transacción a través del cliente, también se firma la carga útil de la transacción con su clave pública de certificado. Se transmiten al contrato inteligente de protocolos en forma de paquete.

• El contrato inteligente de protocolos verifica el certificado, comprueba si corresponde al principal de transacción correcto (interfaz) 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 (desde el registro).

• Los contratos FeeCollector permiten a los curadores, usuarios, validadores y otros realizar staking de tokens directamente en un dominio o un grupo de dominios. Estos contratos deben llevar un registro de la cantidad de tokens que se han staking en cada dominio, la participación de cada dirección en ese staking y el tiempo durante el cual se han staking. Una implementación general de minería de liquidez puede servir como punto de partida para esta lógica de contrato.

• Los usuarios que hacen stake con los curadores (o directamente con el contrato de gestión de tarifas) pueden extraer una parte prorrateada de las tarifas en función de la cantidad de tokens de protocolo que tienen stake con el dominio. La arquitectura podría ser similar a MetaMorpho/Morpho Blue.

Este mecanismo se puede introducir sin aumentar la carga de gobernanza de la DAO del protocolo. De hecho, las responsabilidades de gobernanza se pueden reducir porque podemos activar permanentemente el interruptor de tarifas para todas las transacciones facilitadas por el protocolo, eliminando así cualquier control que la DAO pueda tener sobre el modelo económico del protocolo.

Consideraciones adicionales según el tipo de protocolo

Si bien estos principios se aplican ampliamente a los modelos económicos de tokens de protocolo, puede haber consideraciones de tarifas adicionales según el tipo de protocolo: protocolos creados en la Capa 1 o Capa 2, cadenas de aplicaciones y protocolos creados utilizando Rollups.

Consideraciones sobre el protocolo L1/L2

Los protocolos en cadenas de bloques de Capa 1 o Capa 2 implementan contratos inteligentes directamente en la cadena. Cuando los usuarios interactúan con los contratos inteligentes del protocolo, se cobran tarifas. Esto suele suceder a través de un front-end fácil de usar (como un protocolo o un sitio web) que actúa como interfaz entre los inversores minoristas y los contratos inteligentes subyacentes. En este caso, las tarifas provendrán de ese front-end. El ejemplo anterior sobre app.xyz ilustra cómo puede funcionar un sistema de tarifas para un protocolo de Capa 1.

En lugar de depender de los curadores para filtrar las tarifas de front-end, los protocolos también pueden adoptar un enfoque de lista blanca o lista negra para filtrar las tarifas de front-end. Nuevamente, el propósito aquí es asegurar que los poseedores de tokens y todo el protocolo no se beneficien de actividades ilegales y cumplan con las leyes y regulaciones de una jurisdicción específica. En el enfoque de lista blanca, el protocolo publicará un conjunto de reglas para los front-end, creará un registro para los front-end que cumplan con las reglas, emitirá certificados para los front-end que opten por participar y requerirá que los front-end hagan staking de tokens para recibir una parte de las tarifas del protocolo. Si los front-end no siguen estas reglas, serán recortados y sus certificados de contribución de tarifas serán eliminados.

En el enfoque de la lista negra, el protocolo no tendría que crear ninguna regla, pero los frontends que lo lanzaran no estarían exentos de permisos. En cambio, el protocolo exigiría que cualquier frontend proporcionara una opinión de un bufete de abogados que certificara que el frontend cumple con su jurisdicción antes de permitirle utilizar el protocolo. Una vez recibida la opinión, el protocolo emitiría un certificado al frontend para el pago de una tarifa, que solo se eliminaría si el protocolo recibiera un aviso de un regulador de que el frontend no cumple con las normas.

Los canales de pago reflejarían los ejemplos proporcionados en las secciones anteriores. Ambos enfoques aumentan significativamente la carga de la gobernanza descentralizada, lo que requiere que la DAO establezca y mantenga un conjunto de reglas o evalúe las 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.

Notas sobre cadenas de aplicación

Un Lisk es una cadena de bloques específica de un protocolo cuyos validadores trabajan únicamente en ese protocolo. A cambio de su trabajo, estos validadores reciben una compensación. A diferencia de las cadenas de bloques de capa 1, donde los validadores suelen recibir una recompensa mediante la emisión inflacionaria de tokens, algunos Lisks (dYdX) transfieren las comisiones de los clientes a los validadores.

En este modelo, los poseedores de tokens deben hacer staking con los validadores para recibir recompensas. Los validadores se convierten en módulos de staking seleccionados. Este conjunto de trabajo es diferente de los validadores de capa 1. Los validadores de Lisk liquidan transacciones específicas de protocolos específicos. Debido a esta diferencia, los validadores de Lisk pueden asumir un mayor grado de riesgo legal en las actividades subyacentes que facilitan. Por lo tanto, los protocolos deben dar a los validadores la libertad de realizar el trabajo que pueden realizar de acuerdo con las leyes de sus jurisdicciones y su propio nivel de comodidad. Es importante destacar que esto se puede hacer sin poner en peligro la falta de permisos de Lisk o exponerlo a un riesgo significativo de censura, siempre que su conjunto de validadores esté descentralizado geográficamente.

La arquitectura de las cadenas de aplicaciones que deseen aprovechar la trazabilidad de las tarifas será similar a los protocolos de capa 1 hasta que existan canales de tarifas. Pero los validadores podrán usar asignaciones de frontend para determinar desde qué frontend desean procesar transacciones. Las tarifas de cualquier transacción determinada irán entonces al conjunto activo de validadores, y los validadores inactivos que elijan no participar perderán dichas tarifas. Desde la perspectiva de las tarifas, los validadores realizan la misma función que los curadores de módulos de participación descritos anteriormente, y los participantes de estos validadores pueden asegurarse de que no están recibiendo ingresos de ninguna actividad ilegal. Los validadores también pueden elegir un curador para determinar qué frontends cumplen con las normas en cada jurisdicción.

Notas sobre los paquetes acumulativos de protocolos

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 clasificador que se encarga de ordenar e incluir las transacciones, aunque las transacciones pueden enviarse directamente a la capa 1 a través de un proceso llamado inclusión forzada.

Si estos Rollups son específicos del protocolo y tienen a su recopilador como único validador, las tarifas generadas por las transacciones incluidas por ese recopilador se pueden distribuir a los participantes en función de un conjunto seleccionado de frontends compatibles o como un grupo universal.

Si los Rollups descentralizan su conjunto de clasificadores, estos se convierten en el módulo de participación seleccionado de facto, y los canales de tarifas reflejarán los canales de ingresos de la cadena de aplicaciones. Los clasificadores reemplazan a los validadores en la asignación de tarifas, y cada clasificador puede decidir por sí mismo de qué interfaz aceptar tarifas.

Resumir

Si bien existen muchos modelos posibles para los tokens de protocolo, los pools de staking, si se organizan con cuidado, pueden ayudar a abordar los desafíos externos específicos del protocolo. Al reconocer los desafíos intrínsecos y externos que enfrenta un protocolo, los fundadores pueden diseñar mejor un modelo de token de protocolo para su proyecto desde cero.

Agradecimientos: Gracias a Portero Smith para iniciar este proyecto.

Este artículo proviene de Internet: a16z: ¿Cómo generan flujo de caja los tokens de protocolo?

Relacionado: Con 20 millones de dólares en financiación, cotización en OKX y 2,5 millones de descargas, ¿puede el token MAX de la plataforma MATR1X generar G?

Original | Odaily Planet Daily (@OdailyChina) Autor | Asher (@Asher_0210) El 29 de julio, OKX anunció oficialmente que el token de gobernanza de la plataforma MATR1X, MAX, se lanzó oficialmente en OKX Jumpstart. Los usuarios ahora pueden participar en la minería de tokens MAX haciendo staking de BTC/ETH. El fondo total de recompensas por staking es de 20 000 000 MAX, y el período de minería es desde las 6:00 am (UTC) del 29 de julio de 2024 hasta las 6:00 am (UTC) del 5 de agosto de 2024. La cantidad máxima de staking es de 0,3 BTC/3,5 ETH, y el comercio de tokens MAX se abrirá oficialmente el 5 de agosto. Tan pronto como salió esta noticia, las principales comunidades de juegos de blockchain que habían estado en silencio durante mucho tiempo se animaron y estaban listas para participar en esta gran oportunidad. MAX se lanzó oficialmente en OKX Jumpstart,…