La necesidad de interoperabilidad en los protocolos de tokens de seguridad – Thought Leaders

Una breve historia de los tokens

Han pasado más de 10 años desde que Bitcoin introdujo por primera vez la tecnología blockchain al mundo. En ese tiempo, la lista de casos de uso potenciales para los libros contables distribuidos se ha expandido rápidamente, desde monedas digitales, hasta cadenas de suministro, hasta gestión de identidad. En su núcleo, sin embargo, muchos de estos casos de uso comparten una estructura similar: permiten a los usuarios poseer y transferir activos digitales de forma peer-to-peer. En pocas palabras, ahora podemos comerciar y rastrear activos digitales sin necesidad de una autoridad central de confianza que gestione el proceso.

Esta evolución del espacio naturalmente llevó a la invención de “tokens” – activos digitales en una blockchain que son poseíbles y transferibles entre individuos. Los tokens se dividen en dos categorías principales: aquellos que representan un activo digital nativo, y aquellos que representan un activo subyacente del mundo real. Aprovechando este nuevo paradigma, cientos de miles de diferentes tokens ya se han creado solo en Ethereum, con una capitalización de mercado combinada de más de 15 mil millones de dólares al momento de escribir.

Una de las aplicaciones más prometedoras de los tokens es la representación de valores del mundo real en cadena, lo que permite que activos tradicionalmente ilíquidos como bienes raíces comerciales se fraccionalicen y transfieran peer-to-peer. Este proceso, conocido como “tokenización”, ha ganado una importante atención tanto de instituciones tradicionales como de nuevas startups, debido a su potencial para aliviar muchos de los puntos de dolor existentes dentro de los mercados de capital.

Cumplimiento regulatorio

Aunque blockchain puede facilitar la transferencia de propiedad en un sentido técnico, los tokens de seguridad siguen estando sujetos a las mismas leyes y regulaciones que los valores tradicionales. Garantizar que los tokens de seguridad cumplan con la normativa es, por lo tanto, crítico para cualquier tokenización potencial, y ha sido una barrera para la adopción hasta la fecha. Como se muestra en el gráfico a continuación, la incertidumbre regulatoria se considera ampliamente la mayor barrera para la adopción de blockchain.

Numerosos proyectos han surgido en el espacio blockchain, cada uno diseñando un protocolo que intenta simplificar y estandarizar cómo se regulan, negocian y gestionan los tokens de seguridad. Mirando solo a Ethereum, los proyectos que han publicado estándares que abordan este problema incluyen Securitize, Harbor, Polymath, y más. Sin embargo, en última instancia, sin modificaciones a cómo están diseñados actualmente estos protocolos, los inversores y los intercambios seguirán experimentando una fricción significativa al comprar y vender valores tokenizados. ¿Por qué es esto? Interoperabilidad.

La interoperabilidad es crucial

La interoperabilidad es uno de los beneficios más significativos de la tokenización. Permite que todo un ecosistema de aplicaciones y productos de los mercados de capital se integren entre sí porque comparten estándares de software comunes. Sin embargo, para habilitar la interoperabilidad a nivel de aplicación y producto, debe comenzar al nivel más bajo con los propios tokens. En el espacio de tokens de seguridad, la interoperabilidad es esencial para dos partes clave: intercambios e inversores.

Como intercambio, deseas poder autorizar a los inversores para la compra de cualquier token de seguridad que estén elegibles para comprar, sin importar la empresa que creó el token. Esto significa no tener una integración a medida con cada token de seguridad, sino una integración simple y genérica que sea uniforme en todos los tokens de seguridad.

Como inversor, deseas que el proceso de incorporación sea lo más simple y sin fricciones posible. Actualmente, cuando un inversor quiere comprar acciones de múltiples lugares, debe proporcionar su información personal una y otra vez en un proceso llamado Conozca a su Cliente “KYC”. Blockchain tiene el potencial de transformar este proceso almacenando esta información de forma inmutable en cadena, donde luego puede ser referenciada por todos los tokens de seguridad. Esto significaría no tener que proporcionar repetidamente la misma información personal cada vez que deseas comprar un nuevo token, sino que solo se requeriría información suplementaria o actualizada después del registro inicial. Sin embargo, este proceso solo será posible si la interoperabilidad entre los tokens de seguridad está diseñada en los estándares que rigen el sistema.

Los protocolos

Tres de los principales protocolos de tokens de seguridad de Ethereum fueron publicados por Securitize, Harbor y Polymath. Los tres protocolos se basan en el estándar de token ERC-20 de Ethereum, que luego extienden para imponer el cumplimiento en la negociación del token de seguridad. Esto se logra consultando un segundo contrato sobre la legalidad de cada operación en el momento en que ocurre.

Aunque se nombran de forma diferente en los protocolos, el uso de un segundo contrato es consistente en los tres, logrando el mismo resultado: prevenir operaciones no compatibles. Este segundo contrato ‘Regulador’ se mantiene actualizado con la información KYC y de acreditación de los usuarios mediante servicios fuera de cadena que están autorizados para hacerlo, por ejemplo un intercambio o el emisor del token.

Aunque estos tres componentes pueden parecer todo lo que necesitas para regular un token de seguridad (y en su forma más simple, lo son), es la forma en que los componentes están programados lo que realmente determina la interoperabilidad. Lamentablemente, los protocolos carecen de interoperabilidad en dos áreas clave, lo que continuará causando fricción y ralentizando la adopción de esta tecnología:

1. ¿Cómo actualizan las partes autorizadas la información en cadena sobre los usuarios?

Harbor

Harbor declara en su libro blanco que serán la única parte autorizada para actualizar la información del usuario en cadena por el momento. La centralización de este rol significa que los intercambios no actualizarían ningún dato referenciado por el Regulador. Por lo tanto, no podrán aprobar nuevos destinatarios del token, impidiendo que los tokens se negocien fácilmente fuera de la plataforma de Harbor.

Securitize

Securitize ya ha implementado un sistema mediante el cual múltiples partes pueden ser autorizadas, lo que significa que los inversores pueden registrar su información de cumplimiento en varios lugares y no están obligados a pasar por Securitize directamente. Los datos en cadena son entonces actualizados directamente por la parte autorizada, y pueden ser vistos por todos los tokens de Securitize. Además, para evitar que los inversores tengan que proporcionar información múltiples veces, Securitize ha diseñado una API que permite a las partes autorizadas acceder a la información privada de los inversores que se almacena fuera de cadena, permitiéndoles determinar fácilmente si una persona cumple o si se necesita más información.

Polymath

Polymath tiene un token de utilidad digital nativo llamado POLY que es requerido en toda su plataforma para realizar diversas tareas, incluido obtener que una parte autorizada actualice sus datos en cadena. Para que una persona pueda hacer su propio KYC, primero debe comprar tokens POLY, los cuales no tienen un mercado líquido fiat a POLY. En su lugar, la persona debe comprar otra criptomoneda como el “ether” (ETH) de Ethereum usando fiat, y luego intercambiarla por POLY. Los tokens pueden luego usarse en el mercado KYC de Polymath para hacer una oferta a un proveedor de KYC. Si el proveedor aprueba la oferta, se le paga en tokens POLY para realizar la verificación KYC para la persona. Este proceso es claramente una fricción significativa en la incorporación a la plataforma Polymath, y hace el proceso más complejo de lo necesario.

2. ¿Cómo se almacena y accede luego a esta información sobre los usuarios en cadena?

Harbor

Al observar el libro blanco y los contratos inteligentes en GitHub, es técnicamente posible que muchos de los tokens de Harbor compartan un contrato Regulador común y una fuente común de datos de usuarios, sin embargo esto es poco probable debido a las diferencias regulatorias entre distintos tokens. La falta de tokens activos de Harbor en Ethereum no ha aclarado si es su intención que sea así, o si cada token será desplegado con su propio Regulador.

Securitize

El protocolo de Securitize está diseñado de modo que su contrato Regulador consulta un tercer contrato inteligente que almacena la información del usuario. Esto permite que cada token tenga regulaciones únicas codificadas en su propio Regulador individual, mientras comparte una fuente común de datos de usuarios en el tercer contrato, de modo que cuando un usuario hace KYC para un token de Securitize su información queda almacenada y lista para que compre futuros tokens.

Polymath

No se indica explícitamente en su libro blanco si Polymath tiene una fuente central de datos de cumplimiento almacenada en cadena con la que cada Regulador interactúe, o si los tokens tienen su propia fuente local de información. Sin embargo, basándose en los contratos de muestra de Polymath, parece que cada token usa una fuente local de información, que no se comparte entre diferentes tokens. Si bien esto puede tener ventajas, esta configuración arriesga redundancia de datos e inconsistencias.

Tomemos el siguiente ejemplo: Bob ha mostrado interés en dos tokens de seguridad de Polymath, ABC y DEF, y ha sido aprobado como inversor para cada uno de ellos. Esta información se envía al contrato Regulador de cada token. Un mes después, Bob intenta comprar más tokens DEF pero se descubre que ya no está acreditado. Esta información se envía al Regulador de DEF para actualizar el estado de inversor de Bob a no acreditado. Ahora, en cadena, hay información conflictiva: ABC piensa que Bob es un inversor verificado, sin embargo DEF discrepa. Es fácil ver que tener una fuente central de información evitaría que ocurran tales discrepancias.

Interoperabilidad de los protocolos

Como se discutió anteriormente, hay dos partes principales involucradas en la emisión e intercambio de tokens de seguridad a quienes la interoperabilidad les importará mucho: intercambios e inversores. Ambas partes desean una experiencia fluida al interactuar con diferentes tokens de seguridad. Entonces, si usamos los protocolos tal cual, veamos cómo se verán afectados los intercambios y los usuarios.

Exchanges

Como intercambio, integrar estos protocolos para propósitos de transferencia es fácil: todos los tokens utilizan el estándar ERC-20, proporcionando una interfaz uniforme para invocar transferencias, aprobaciones y consultas de saldo. Sin embargo, la integración adicional con el aspecto de cumplimiento de cada protocolo se vuelve mucho más compleja. Recordarás que actualmente no es posible que una parte de confianza se autorice en el protocolo de Harbor; en su lugar tendrán que dirigir a los usuarios a Harbor para que hagan su propio KYC. Para integrar con el protocolo de Securitize, la parte de confianza debe ser autorizada por Securitize, lo que le permitirá acceder a los datos KYC de los inversores a través de la API fuera de cadena, y actualizar la información en cadena almacenada en el almacén de datos en cadena.

Integrarse con el protocolo de Polymath probablemente sea lo más complejo. La parte de confianza debe registrarse como proveedor de KYC en el mercado KYC de Polymath y configurarse para recibir ofertas en tokens POLY a cambio de proporcionar servicios de KYC. Al proporcionar servicios de KYC a los inversores, la parte de confianza debe entonces organizar una forma de asegurar que los datos duplicados en cadena almacenados sobre un usuario en cada Regulador de seguridad no se vuelvan inconsistentes.

No solo los protocolos tienen diferentes interfaces que la parte de confianza debe integrar, cada protocolo también tiene una forma distinta de proporcionar informes de errores al intercambio. Al construir una interfaz es importante poder traducir cualquier error que ocurra a algo comprensible para los usuarios. Por ejemplo, si un usuario no puede comprar un token, esto podría deberse a una amplia variedad de razones: el valor puede tener un período de retención que aún no se ha cumplido, o puede restringir el número máximo de tenedores permitidos. Para poder comunicar estos mensajes a los usuarios, el intercambio tendría que integrar un método diferente de reporte de errores para cada protocolo.

Inversores 

Los diferentes métodos mediante los cuales la incorporación de inversores está diseñada actualmente en los protocolos hacen que los inversores probablemente tengan que proporcionar información personal muchas veces a diferentes plataformas y de diferentes maneras. Esto se debe a que Harbor no ha autorizado a ninguna otra parte, y Polymath requiere que los inversores pujen por procesos KYC usando tokens POLY. La fricción causada por la imposición de estos métodos de cumplimiento puede hacer que los inversores no quieran o no puedan comprar valores que de otro modo comprarían.

La escala de esta fricción inducida por los protocolos en los inversores puede aliviarse algo por la forma en que los intercambios integran cada uno de los protocolos. Por ejemplo, si un inversor elige hacer KYC en un intercambio para comprar un token de Polymath, ese intercambio, si está autorizado, podría elegir actualizar el almacenamiento de datos de Securitize al mismo tiempo. Esto significaría que la información del inversor está en cadena en caso de que se necesite en el futuro. Sin embargo, si no se hacen cambios a los diseños actuales de los protocolos, el proceso de registrar y comprar valores seguirá siendo intimidante.

Solutions

La solución a este problema no tiene por qué ser compleja. De hecho, es posible introducir ciertas soluciones sin cambiar ningún token que ya esté activo en Ethereum. Una solución ideal que resulte en una fricción mínima tanto para intercambios como para inversores, y que evite inconsistencias de datos causadas por tener muchas fuentes diferentes de datos de cumplimiento, se asemejaría mucho al almacén de datos centralizado en cadena de Securitize; sin embargo, cualquier configuración de este tipo debe adoptarse a escala de toda la industria.

Al tener una fuente central de información en cadena, se elimina el riesgo de inconsistencias de datos, y los inversores pueden comprar diferentes valores mediante una sola verificación de cumplimiento. Este contrato central llevaría a cabo la verificación de que la transferencia sea compatible para todos los tokens de seguridad, y la transferencia continuaría o revertiría. La API fuera de cadena accesible a todos los intercambios autorizados permite que la información de cumplimiento del inversor se comunique a los intercambios y reduce la cantidad de veces que se les pide a los inversores que proporcionen datos. Estos aspectos juntos también reducen enormemente la cantidad de trabajo de integración requerido por los intercambios.

La introducción de un nuevo sistema como este claramente genera algunas complicaciones, y aún habría que resolver varios problemas. Por ejemplo, en el diseño de cómo cada intercambio se autoriza: ¿quién decide que un intercambio debe ser de confianza? Se debe dedicar tiempo a diseñar un sistema que permita llegar a un consenso.

Conclusion

La tokenización de valores sigue siendo un área que está en una fase temprana de desarrollo y adopción, lo cual se debe en parte a las complejidades del cumplimiento regulatorio. Si bien la publicación de protocolos simplifica el cumplimiento de muchas de estas regulaciones al permitir que se apliquen en la ejecución de cada transferencia, aún queda mucho camino por recorrer antes de que esto sea un proceso sin fricciones. Hasta que no haya un acuerdo entre protocolos sobre cómo se almacena y actualiza la información del inversor tanto en cadena como fuera de cadena, seguirá existiendo una fricción significativa a lo largo de los procesos de registro e inversión para todas las partes involucradas.