Cómo planificar tu token en un mundo de interoperabilidad | Governance Day | Crecimiento 2024

Transcript

y esta charla va a tratar sobre cómo gobernar tokens desde una perspectiva lo más entendible simple posible dado que el mundo en el que nos encontramos de interoperabilidad que empieza a salir nos presenta múltiples retos primero un poco de antecedentes es en el en el año pasado el governance de del 2023 había dado una charla sobre cómo se gobernaban los en ethereum Así que si les interesa este tópico lo pueden recuperar del canal de YouTube de s latam y bajo esa misma metodología es que voy a a abordar el tema de los

tokens ahora para dejar un poco Claro porque capaz puede ser un poco confuso el título de la charla eh gobernando tokens e empezaría diciendo sobre cuál no es el scope de la charla y no voy a estar hablando sobre cómo los tokens gobiernan un dao Tampoco voy a estar hablando sobre la seguridad de puentes como Estableciendo un criterio para ello tampoco estaré hablando sobre cómo se maneja esto en las propiedades en un token que es lo que al final de cuenta es un cierto modo de gobernar su funcionalidad sino que me enfocaré muy específicamente en entender lo que

implica que haya representaciones de tokens Y por qué importa en un mundo en donde crypto se convierte en un ecosistema que es multichain y la situación actual es tan simple como esta actualmente las daos los protocolos los token issues Crean un rc20 Generalmente en ethereum el token y después al crearlo se enfrenta a que en realidad el token puede ir a cualquier parte de del ecosistema web 3 donde haya la posibilidad de conectar dos blockchains entonces la gran pregunta

acá es cuando se crea un nuevo token cómo después ese token lo llevas O lo haces compatible en un ecosistema donde hay múltiples blockchains funcionando en paralelo derivando una sobre otras layer 1 layer 2 layer 3 etcétera etcétera esta situación es bastante problemática ya veremos por qué pero es como una de las más grandes interrogantes que se encuentra cualquier daado cualquier proyecto cuando lanza un token es cómo adaptar si es que se desea que el token pueda vivir en múltiples cadenas Cuáles son principalmente los problemas que se que nos

enfrentamos cuando se crea un nuevo token y se quiere mandar a una una nueva Chain para su usabilidad sea cual sea primero el primer problema Sería el tipo de Bridge utilizado Es decir para mover activos de una Chain a otra necesariamente va a tener que pasar por un protocolo de pase de mensajes puentes como prefieran decirle Y estos protocolos funcionan de una manera muy específica de acuerdo a Cómo fueron concebidos y Cuál es la utilidad del puente qué chains conecta qué framework utiliza qué eh modelo de seguridad utiliza y esto te crea un sinfín de

puntos a considerar que se pueden considerar parte del problema no eh utilizar un puente en específico quiere decir que el token va a depender de dicho puente lo que crea el problema de lockin vendor es decir depender de su infraestructura también eh veremos que hay múltiples modelos de seguridad en puentes cuál sería el correcto utilizar han escuchado no que en el año 2021 22 23 podría decir que decenas de puentes fueron hackeados algunos recordarán warm Hall otros recordarán poly Network etcétera etcétera cuál escoger Sabiendo de que esto puede suceder e hay que pensar en métodos de recuperación Es decir de que el token

puedas tener este eh Si se quiere decir de precar que el token que viva en una cadena e pasar a alg alguna otra representación y lo importante también que es la adquisición de infra un punto importante acá que es de referencia es cstp que es el protocolo que utiliza usdc que si bien es una solución centralizada nos hace nos muestra de cómo un token puede vivir en múltiples cadenas pero si utilizas una infra que es la que se encargue de llevarla de una a otra por el método de mintear kemar tokens eh requiere pues mantener esa infraestructura y después hay que pensar en el tipo de token estándar a

utilizar en la lámina anterior mencionaba que el rc20 nada es super básico es como es el estándar pero solamente te tiene las funciones de Okay Cuál es el nombre del token ticket el mapping de cada uno de los balances transferencias Ya está entonces e hay que pensar también que cuando un nuevo token es creado en cualquier cadena pues se va a regir por algún estándar Y entonces hay como distintas variables a tomar en cuenta es un token que solo sirve para lo que es para transferirlo sin ninguna funcionalidad o sea un vanila es tiene funcionalidades que son custom quién apropia ese token en esa nueva cadena o no lo es etcétera entonces hay muchas cosas a considerar

allí este logo no sé si se acordarán de aquel protocolo se my finance o chido lo menciono acá porque puedo decir que fue es un equipo nada latinoamericano y fue uno de los puedo decir que visionarios de cómo se debe pensar un token cuando pensas que tu protocolo es multi Chain entonces dicho protocolo defy tenía ciertamente alguna suerte de da Chain etcétera y se decidía dónde este token iba a estar viviendo en las nuevas chains que iban saliendo entonces a medida que iban saliendo layer 2 este otras redes ibn etcétera ellos en eh A través de el equipo y la dao coordinaban

en donde este protocolo defa y por lo tanto su token se iba a existir este token simplemente funcionaba como una suerte de die no entonces eh se mentia a través de colateral eh Y nada aceptaba múltiples colaterales etcétera e Cómo se debe trabajar un token que se pretende que sea multicadena y hablando de tokens multicadena pensemos que también hay otra realidad paralela que es que cada layer 2 que va saliendo e va incluyendo o van Estableciendo sus propios estándares entonces e si bien Nos gusta que los roll sean

permissionless y que cualquiera pueda bridar un token desde por ejemplo eum a un nuevo rollup si lo hacemos de la forma tradicional o método por default nos encontraremos Que estaremos creando una representación del token que capaz es subóptima o una versión vanila porque no conserva todas las propiedades entonces imagínense que vos tenés el token de uniswap en ethereum y sabes que con ese token Puedes delegar puedes votar etcétera Pero luego la representación por default de ese token uni en op mainet en arbitrum W no conserva ninguna de esas propiedades ni la apropia la dao de uniswap entonces para lo único que sirve el token de unis Swap en openbit es para

comerciar pero para nada más entonces lo convierte en un token donde ciertamente queda inútil para lo que se supone que que debería para lo que se supone que es la utilidad que es originalmente concebida por lo tanto si vos queres utilizar uniswap el token de uniswap para votar y el protocolo es decir el gnor está preparado para lo que va a causar es que esa representación que vive en Open Main Y en arbitrum W no sirve en ninguna hay que migrar a una nueva representación que tenga las propiedades que tiene el token original e Entonces nada es un problema ya saben cómo es esto de las migraciones ni siquiera usdc ha podido

deprecar la versión este por default que se emitia a través de los rollups a su vez También hay que pensar que los Rolls Piensan en Cuáles son los tokens estándar que mejor hace buen fit a su propia cadena Entonces está como que esa dicotomía en quién marca Cuál es el estándar para los tokens que debería existir en determinada Chain y vemos que opain tiene la versión el optimis mint rc20 ahora super Chain rc20 como una versión mejorada del mismo y arbitrum también tiene la suya Entonces como es un entorno competitivo de bueno quien bria primero arma la primera representación del token Y si tiene suficiente tracción pues va ganando

liquidez y termina siendo ad entonces a veces está bueno pero otras veces no conviene si vos querés utilizar el token para lo que supone que que que está no y no solo comercial entonces Cuáles son los requerimientos para un buen token Estos son solo criterios que que han salido en parte de mi investigación pero algunos de ellos podrían ser que la idea es que tengo un estándar uniforme es decir que cada representación del token que existen en cada Chain eh tenga la si es posible la misma implementación segundo que el token sea apropiado por el protocolo que lo emite o sea por la dao imagínense eh un mundo

en el que Maker dao ahora Sky me parece skynet este tiene esta versión de de su stable Coin donde no solo la emite desde ethereum sino que también la emite desde otros Rolls y tiene el completo ownership de ese token lo cual permite permite que baul haga existan en estas otras cadenas tal cual como les explicaba de antecedente con my finance también hay que pensar en el manejo del minter ciertamente cuando vos movés o transportas un token de una china a otra Hay que preguntarse bueno Quién fue el encargado de quemar el token y después del otro lado Quién fue el encargado de de minarlo eh Generalmente hasta ahora

lo que se ha visto es como una terceros que se encargan de de de de nada establecer esta funcionalidad de un modo u otro eh Pero bueno este hay que preguntarse bien a quién al final de cuenta dependes para que el minteo del token eh suceda después eh un buen requerimiento es que sea actualizable el ecosistema cambia muy rápido y nunca sabes cuándo necesitas agregar una nueva funcionalidad al token entonces Está bueno que las dados los colos los productos sepan de que bajo esa realidad Está bueno que los tokens los establezcan como actualizables y tengan el método que mejor les haga fit sobre

cómo actualizarlo para que si al futuro aparecen nuevos estándares requieren de nuevas funcionalidades y eso no tengan que estar forzando o nada castigando un poco a los usuarios a migrar de una este de una implementación a otra Como justo lo que pasa ahora estos días con Maker d y por último lo de portar sus funcionalidades es decir con lo que he estado hablando hasta ahora si tu token sirve para x y cosa entonces Está bueno que puedas ejercerlo desde cualquier Chain si está ready para hacerlo y hay soluciones O sea hay distintos teams que han estado trabajando en pensar que el tema de

atacar Cómo el token debe existir en un mundo donde hay múltiples cadenas no se resuelve por el lado de puentes por el lado netamente de nada de pensar en desarrollar un nueva implementación según sea cual cadena sino que viene el lado de pensar desde desde el digamos lado de perdón que repita la palabra lado este del estándar del token entonces diversos teams han estado trabajando en ello y primero tengo acá el 20 que quizás es uno de los estándares más neutrales en los cuales básicamente lo que vos tenés es un rc20

el cual se le permite eh tener múltiples minters es decir que la dao pueda controlar Quién es el que está encargado de de mintear El token en en determinada cadena bajo qué parámetros o bajo qué límites puede hacerlo y tener completo por supuesto ownership eh la da el protocolo eh también están otros que persiguen más o menos el mismo objetivo como ntt de warm h o ft de layer Zero Eh no voy a a detallar un poco de qué hablan estos dos pero en términos generales Es okay Un estándar el cual la dao pueda controlar pueda marcar como eh un framework oficial para utilizar en cualquier eh

Chain y por lo tanto la dao tenga la disposición de poder controlar manejar y también deprecar este determinado token eh lo cual permite que te evita fragmentación de liquidez este representaciones que no son genuinas incluso maliciosas etcétera etcétera entonces eh Hay teams trabajando en ello y está bueno conocerlas hay un ejemplo de cómo se aplica eh este tipo de estándares y me gusta mucho el del Team o sea de everclear eh Solo para que también tengan contexto los de everclear antes connex son fueran los ideador de justamente el estándar de exerc 20 y por

lo tanto fueron de los primeros que se decidieron a implementar o probar este nuevo estándar y es tan simple como al momento de implementarlo os lo que decidieron es Okay Eh este nuevo standar exerc 20 me va a permitir que mi token everclear o next token lo pueda deployar y tenga la exacta representación No solo en ethereum sino también en opain en arbitr en polygon etcétera eh creo que también gnosis si no estoy mal eh y una primera propiedad a simple vista Es que todas comparten la misma address entonces la address del token X en versión X rc20 en ethereum en op Main

en el arbitrum es exactamente la misma adre o sea en todos lados Entonces cuando lo vas a buscar en explorador está ahí y ya sabes entonces que es la oficial también hay que pensar que esto permite extender funcionalidades como la del Go token entonces e dado que eh everclear antes conex tiene una gobernanza estilo of Chain si no estoy este desactualizado aún así le permite que la dao pueda votar Este de nuevo de forma Chain contar los votos este fuera de cadena utilizando snapshop e pero pero pero pero vos podés votar con tu token ubicado en cualquier en

cualquier Chain donde esté disponible Entonces si tienes eh token next en Open mainet o en arbitrum vas a poder eh digamos delegar desde ahí votar desde ahí sin ningún problema Entonces eso te permite que no tengas que pensar que la gobernanza juro tiene que estar en en e sirium por ejemplo donde puede ser relativamente costoso eh Y también diversifica que los usuarios puedan este decidir dónde ejercer sus responsabilidades como parte de la gobernanza entonces también habría que pensar de que si incluso este everclear conex o cualquiera que utilice este mecanismo pasa un modelo de govern Chain automáticamente este token estaría listo

también para votar ejecutar propuestas de estilo crusing governor etcétera entonces está buenísimo y solo Sería posible bien hecho a través de un ar como el exerc 20 o también como los otros mencionados también hay que pensar en la máxima seguridad sí eh Y para hablar un poco de ello me encanta el ejemplo del rapid stak Steak eth de que está en bnb Chain y para ello voy a poner un poco de contexto eh recordemos que no todas las blockchain se conectan igual unas a otras Entonces eso quiere decir que hay ciertas cadenas que están completamente disociadas y por lo tanto es imposible tener un

protocolo seguro de poca confianza para poder digamos este nada por ejemplo mover Ases de un lado a otro entonces eh un ejemplo claro es entre etherium y bnb Chain la red de binance este no nada las conecta entre sí de forma segura y de poca confianza entonces La pregunta es si yo quiero tener el rapid State eth en bnb Chain que tengo que hacer fue una discusión grande que que se llevó en la dao de ido sobre Qué hacer en este caso porque las oportunidades de tener tu token en todos lados es es Es grande no porque recordemos que eth es uno de los activos este más demandados de todo el ecosistema y su versión estaqueada pues está siendo cada vez más y más y más

atractivo y Y eso no más atractivo Entonces qué se les ocurrió a a los de ido en general era bueno abrir la discusión sobre cuál es la mejor manera de transportar este token a a la red de bnb Chain y e salió una propuesta muy interesante que busca maximizar la seguridad Antes que nada que es reconociendo la desconexión entre ambas cadenas dos proyectos eh de puentes como warm Hall y axelar se pusieron de acuerdo en ofrecer una solución para llevar este token a bnb Chain de forma digamos eh más segura y en qué se basa primero en utilizar el

el estándar ntt que es como un poco el equivalente de lo que explicaba del exer C2 lo cual también le entregaba el ownership de alguna forma u otra a daado de laido a través de los contratos de los puentes que se implementaron para ello y tiene algo muy interesante que utiliza una especie de consenso donde laido no tiene por qué exponer a sus usuarios O sea la daado no tiene por qué hacer alguna implementación haciendo depender a los usuarios de algún puente en particular sino que puede utilizar una especie de consenso que es básicamente utilizar varios al mismo tiempo en el cual cuando vos envias este token a bnb Chain ese envío pasa por un protocolo de mensajería que

es independiente uno es de War El otro es de axelar pasa el mismo mensaje y si el resultado es el mismo desde el otro lado de la cadena o se en bnb entonces tendrás adjudicado tus rapid Steak eth Entonces eso evita de que si warh se convierte o se vuelve malicioso y axelar pues este no va a haber una no coincidencia de el pase de mensajes y por lo tanto el token no va a ser miniado y por lo tanto no va a haber liquidez generada de forma maliciosa Por lo cual te evitas lo de tener que depender de una sola infraestructura ahora eh laido la dado de laido implementó dos pero la verdad es que a futuro pueden remover cualquiera de estos en en cualquier momento o incluso

agregar más para tener con este mayor seguridad a través de consenso de puentes lo cual está muy muy muy muy interesante eh Y esto Solo es posible porque lo piensan desde el lado de que lo que importa al final del día es el es el token estándar y también del ownership de Cuál es la infraestructura para que la dao pueda resguardarse aí mismo de cualquier problema que estos al final de cuentas Services providers este puedan causarle Pero cuál sería el el mundo ideal la el mundo ideal en un ecosistema multichain sería que existiera una única representación predominante por cadena

es decir es muy fastidioso estar en una Chain donde cuando por ejemplo entras a uniswap y vas a buscar qué s yo usdc eh Y pones dicha dicho tag te aparezcan cuatro cinco versiones diferentes y no sepas cuál es la que se supone que es correcta Entonces eso es un problema que cada vez es más predominante al día de hoy y que vale la pena pues tomar conciencia si sos participante de una dao si contribuyes a un protocolo o si eres un un proyecto que está emitiendo un token de que la única representación eh en cada Chain hace un montón de sentido Obviamente el lado de producto para para nada para poder este tener la

liquidez concentrada en un token O sea no tiene por qué haber múltiples tokens si al final lo que se necesita es uno que tenga todas las funcionalidades Entonces eso solo es posible a través de por el momento utilizando dichos estándares como una manera adecuada ordenada de poder llevar tu token a nada en un mundo multichain que se interoperable etcétera etcétera Así que este Debería ser en mi criterio No sé ustedes este el mundo ideal y para eso hay como algunas end aciones no muy rápidamente capaz ya dije algunas me adelanté un poco eh la primera es que si el activo está pensado para Más allá de una cadena Entonces tienes que pensar en que estos

estándares que mencioné pero capaz no van a ser los únicos tienen que ser concebidos eventualmente y más temprano que tarde sobre todo en un mundo donde las dados son lentas tomando decisiones eh segundo eh Nada que las implementaciones custon requiere recursos extras Así que hay que tomar en cuenta decir cada funcionalidad añadida requiere que eh el estándar se modifique que haya este nada auditorías etcétera etcétera y eh Nada esto trae como consecuencia que que la fragmentación de liquidez es resuelta con un diseño óptimo pero hay una pregunta acá importante es el fin entonces de los

tokens que son de confianza mínima otros minimized Qué quiere decir esto Tal vez eh hace años atrás las layer 2 o los rollups hablaban sobre Okay si yo tengo un token en ethereum y lo mando a otra Chain La idea es que nadie pueda tener control sobre ese token Por ejemplo si es algo como un stable conon o algo así pero en toda esta tesis que estaba explicando estamos como O al menos yo estoy validando un poco la idea de que eh el Owner del token siga siendo el emisor Entonces hasta qué punto esto puede ser positivo en todos los escenarios eh la verdad es que es un problema que aún digamos está abierto y está a consideración del ecosistema Y creo que eso lo va a determinar el mercado eh

pero por el momento eh la situación es esa y nada Muchas gracias