ERC-3643: Los tokens T-REX
La infraestructura de tokens permisionados para la nueva ola de adopción institucional
Introducción
La principal ventaja que aporta la tecnología blockchain como la conocemos hoy en día es la posibilidad de que cualquier persona pueda interactuar con ella independientemente de su nacionalidad, sexo, raza o clase social. A esto es a lo que se le llama una infraestructura “permisionless”, es decir, que no requiere de permiso de nadie para ser utilizada.
No obstante, esto supone un problema a la hora de emitir activos financieros tokenizados en la blockchain ya que estos son considerados securities y como tal están sujetos a las regulaciones de los mercados de valores y por tanto pueden excluir a ciertas personas o entidades de interactuar con ellos. Personas que no hayan sido identificadas mediante un proceso de KYC, personas que se encuentren en listas de blanqueo de capitales internacionales, personas provenientes de países incluídos en la lista negra de organismos regulatorios por ser considerados “paraísos fiscales”, etc.
Si queremos emitir valores financieros en la blockchain necesitamos de una infraestructura que nos permita incluir estas regulaciones en la base de los tokens de forma que podamos controlar quién, cómo y cuándo puede interactuar con estos tokens y establecer medidas de contingencia cuando se infringan estas normas. Hasta ahora el enfoque que se había tomado era el de creard desde cero blockchains permisionadas en la que un grupo de validadores elegidos a dedo se encargasen de decidir quién sí y quien no podía participar en ella.
El principal problema de esto es que el construir una blockchain desde cero es muy complicado, y no sólo construirla, sino atraer una masa crítica de usuarios que quieran permanecer en ella. Para esto necesitamos invertir cantidades ingentes de capital en incentivar el desarrollo en nuestra blockchain para que se construyan aplicaciones que la gente quiera utilizar, pero ni aún así te aseguras el éxito, nada más hay que ver las “Ethereum Killers” del bull run pasado…
Pero, ¿y si pudiésemos construir una infraestructura de tokens permisionados sobre una red ya existente y con una gran base de usuarios? Esto es lo que se pretende conseguir con el ERC-3643, crear un estándar que permita crear tokens que cumplan con los requisitos regulatorios y que además se beneficie del enorme ecosistema y seguridad de la red más importante y usada del mundo, Ethereum.
ERC-3643: T-REX Tokens
El estándar ERC-3633, tambien conocido como “T-REX” de las siglas “Tokens for Regulated Exchanges”, se creó con la intención de aportar una interfaz desde la que poder emitir y gestionar securities sobre la red de Ethereum.
Al contrario que en una ICO, donde los dueños del proyecto no deben hacer muchas modificaciones al token posteriormente a su lanzamiento, en una STO (Security Token Offering) los emisores deben mantener un estricto control post-lanzamiento con el objetivo de cumplir las regulaciones del comercio de valores. Estas las podemos dividir en dos grupos:
Controles generales: Por ley cualquier persona que interactúe con una security debe identificarse a través de un proceso de KYC (Know Your Customer) y esta información debe ser monitorizada frente a listas de blanqueo de capitales internacionales (AML) en busca de posibles restricciones.
Controles específicos: Además de esto, ciertos activos pueden tener restricciones a la hora de comerciar con ellos como pueden ser cantidades mínimas, la necesidad de ser inversor cualificado, ser de un país o zona territorial concreta, etc
Además de que exista toda esta lista de requisitos, estos evolucionan a lo largo del tiempo, por ejemplo: las listas de países considerados paraísos fiscales cambia a menudo. Por ello, el estándar ERC-3643 se enfoca especialmente en aportar una gran flexiblidad y reusabildiad en el diseño de los tokens. Vamos a ver cómo funciona.
ONCHAINID
Un requisito fundamental a la hora de operar con securities es la identificación previa de toda persona o empresa a través de un proceso de KYC/KYB. Sin embargo, la blockchain se identifica por ser completamente anónima, no necesitas aportar ningún dato personal, ni siquiera correo electrónico, a la hora de crearte una billetera o interactuar con un protocolo.
Bajo esta premisa se creó el contrato ONCHAINID, que se trata de un protocolo para la verificación y el almacenamiento de identidades en la blockchain basado en los estándares ERC-734 y ERC-735. En este protocolo, existen una serie de entidades permisionadas como proveedores de KYC, consultoras, abogados, etc; que se encargan de pedir y verificar la información personal de los usuarios.
La información se solicita en forma de claims
, que no son más que las distintas pruebas que se piden en un proceso de verificación de identidad.
Por ejemplo, en un KYC normal para una persona se suelen pedir: nombre y apellidos, dirección, prueba del DNI y prueba de vida. Cada una de estas informaciones sería un
claim
.
Una vez se ha completado este proceso, se crea un smart contract ONCHAINID que representa la prueba digital de esta información, y se le vinculan una o varias billeteras que a partir de ahora estarán directamente asociadas a la persona o empresa detrás de ese ONCHAINID. Posteriormente, este ONCHAINID es usado como certificado de identidad para interactuar con tokens y aplicaciones descentralizadas permisionadas o incluso para abrir cuentas en exchanges sin necesidad de pasar un nuevo KYC.
Hasta ahora las propuestas de identidad digital que se hacían iban más en la dirección de la creación de tokens NFT como los “souldbound tokens” que se vinculasen a tu billetera de forma permanente. Sin embargo, este modelo carece de la flexibilidad y la programabilidad que hacen falta para poder cumplir con las regulaciones.
Componentes del T-REX
Registro de identidades (Identity Registry)
Se trata de un smart contract que sirve como punto de conexión entre las identidades de los usuarios y el contrato del token. Este smart contract contiene y ejecuta la función isVerified
que se encarga de validar que los claims
dentro del ONCHAINID de un usuario corresponden con los requisitos de identidad que pide el token con el que quiere interactuar.
Registro de emisores (Trusted Issuers Registry)
Este contrato sirve como listado de los ONCHAINIDs de las entidades permitidas para emitir claims
para un security token concreto.
Con él se dice qué empresas tienen la confianza y el permiso para poder emitir claims
que se vincularán a los ONCHAINID de los usarios. Adicionalmente, se puede definir qué claims
concretos puede emitir cada empresa
Por ejemplo: A un proveedor de KYC se le puede dar permiso para emitir
claims
relacionados con la verificación de identidad personal de los usaurios, pero no relacionados con documentos financieros como nóminas o extractos bancarios, que serán adjudicados a notarios, abogados o consultoras.
Además de este contrato, existe el “Claim Topics Registry”, que se trata de un listado de los distintos claims
que hacen falta para poder operar con el security token en cuestión y que son los que se revisan en el “Identity Registry” que hemos mencionado anteriormente.
Almacenamiento de identidades (Identity Registry Storage)
Este contrato funciona como un repositorio de billeteras y ONCHAINIDs de inversores, donde se asocia cada billetera a su respectivo ONCHAINID. Los ONCHAINID que se guardan aquí son aquellos que han cumplido con las condiciones que se pedían en el registro de identidades y sirve como “whitelist” de las billeteras que están permitidas para interactuar con el contrato del token.
Este contrato de almacenamiento puede estar vinculado o a uno o varios contratos de registro en el caso de que el creador del token quiera tener distintos tipos de usuarios con distintas funciones.
Token permisionado (T-REX)
El último punto de la infraestructura del T-REX es el propio contrato del token. Este contrato ERC-3643 está basado en la estructura fudamental de un ERC-20, por lo que es totalmente compatible con él. No obstante, los T-REX tokens cuentan con muchas más funcionalidades para asegurar que cumplen con la regulación de comercio de valores.
Una de ellas es que para poder ejecutar las funciones transfer
o transferFrom
primero se verifica si el inversor cumple los requisitos que se especifican en el contrato de identidad y el módulo de compliance. En el caso de que no los cumpla, este no puede interactuar con el token de ninguna forma.
El módulo de compliance es el smart contract que establece las reglas para el T-REX token. Estas puedne ser, por ejemplo: la cantidad máximas de inversores por país, la cantidad mínima o máxima de tokens por inversor, la lista de países donde está permitido su circulación, etc. Estos requisitos son dinámicos y pueden cambiarse posteriormente al deployment del contrato con el fin de asegurar el máximo cumplimiento con la regulación vigente.
Este contrato es activado para cada transaccion que se desee hacer y se asegura de que cada una de ellas cumple con las reglas. Este devuelve un TRUE
si la transacción cumple las reglas y un FALSE
si no.
Además los T-REX tokens permiten que los puedan recuperar sus fondos en el caso de que pierdan la clave privada de su billetera. Estos simplemente deberían ir al creador del token, verificar que el ONCHAINID asociado a esa billetera perdida es suyo, y el creador del token podría llamar a la función recovery
para enviarlos a una nueva billetera que desee (de nuevo asociada a ese ONCHAINID).
Inconvenientes
Este modelo, aunque interesante, también presenta muchos inconvenientes por culpa de la infraestructura permisionless de las finanzas descentralizadas y la estructura de billetera de algunas aplicaciones o protocolos.
El primer problema le encontramos en los exchanges y demás plataformas que utilizan modelos de custodia centralizados. En estos modelos, por lo general, debes enviar a una dirección de depósito los tokens que quieres depositar en la plataforma. Estos tokens luego son retirados de esa billetera de depósito y se agrupan con los del resto de usuarios de la plataforma. En el caso de los T-REX tokens esto no se podría hacer a menos que tanto la dirección de depósito personal, como las billeteras internas de la plataforma cumpliesen con los requisitos de compliance. Para solucionar esto, la billetera de depósito debería estar asociada a tu ONCHAINID y el CEX tener también el suyo propio para poder mover los tokens de forma interna.
En el caso de los DEXs el inconveniente es parecido. Cuando nosotros realizamos un swap en un DEX, lo que estamos haciendo es enviar nuestros tokens a contrato de una pool, por lo que también esta pool debería tener su ONCHAINID y cumplir con las reglas definidas en el módulo de compliance.
Conclusión
La naturaleza permisionless de la blockchain tiene muchísimas ventajas, siendo las más importantes la “facilidad” de uso y la libertad que otorga. No obstante, el sector financiero es uno de los más regulados del mundo, especialmente porque cuando se trata del dinero que tanto nos cuesta ganar, normalmente exigimos fuertes garantías. Y esto con la infraestructura actual no es posible.
El protocolo ONCHAINID y el estándar ERC-3643 aportan un modelo de blockchain libre y descentralizada, pero donde también hay lugar para construir soluciones que cumplan con las regulaciones vigentes y atraigan a empresas e inversores institucionales en busca de garantías. En este mundo convivirían ambas partes de forma independiente, permitiéndote permanecer anónimo, o beneficiarte de las mejoras de la infraestructura regulada y centralizada si así lo deseas.
Cuando hablamos de las ventajas y los casos de uso que aporta la blockchain, se nos llena la boca hablando de tokenizar esto y aquello, pero la realidad es muy distinta. Sí, con la tecnología blockchain podemos emitir bienes inmuebles fraccionados en forma de tokens y mantener un registro seguro e inmutable de su propiedad, ¿pero cómo vas a hacer esto correctamente si ni siquiera tienes una infraestructura funcional que te permita identificar a los inversores?
Todos estos años se ha permitido la emisión “no-legal” de securities porque no existía aún una regulación general que indicase cómo se debían hacer las cosas, pero eso está cambiando. Cada vez hay más textos legales que traen el concepto de security a los activos digitales, por lo que todos esos tokens enmascarados como “utilities” tienen los días contados. Por esto debemos avanzar a construir soluciones, estándares, protocolos o infraestructuras, que nos permitan emitir y gestionar securities en la blockchain cumpliendo con la regulación.
Si queremos que los casos de uso de la tecnología blockchain que defendemos empiecen a ser una realidad debemos apartar nuestra mentalidad cypherpunk (o por lo menos reservarla para unos pocos aspectos), ampliar nuestra visión y aceptar que la regulación es algo vital para el desarrollo de los mercados.
Muy muy interesante