A Necessidade de Interoperabilidade em Protocolos de Token de Segurança – Líderes de Pensamento

Uma Breve História dos Tokens

Já se passaram mais de 10 anos desde que o Bitcoin introduziu a tecnologia blockchain ao mundo. Nesse período, a lista de casos de uso potenciais para registros distribuídos expandiu-se rapidamente, desde moedas digitais, até cadeias de suprimentos e gerenciamento de identidade. No fundo, porém, muitos desses casos de uso compartilham uma estrutura semelhante: eles permitem que usuários mantenham e transfiram ativos digitais de forma ponto‑a‑ponto. Simplificando, agora podemos negociar e rastrear ativos digitais sem precisar de uma autoridade central confiável para gerenciar o processo.

Essa evolução naturalmente levou à invenção dos “tokens” – ativos digitais em uma blockchain que são possuíveis e transferíveis entre indivíduos. Os tokens se dividem em duas categorias principais: aqueles que representam um ativo digital nativo e aqueles que representam um ativo do mundo real subjacente. Aproveitando esse novo paradigma, centenas de milhares de tokens diferentes já foram criados apenas no Ethereum, com uma capitalização de mercado combinada de mais de US$ 15 bilhões no momento da escrita.

Uma das aplicações mais promissoras dos tokens é a representação de valores mobiliários do mundo real na cadeia, o que permite que ativos tradicionalmente ilíquidos, como imóveis comerciais, sejam fracionados e transferidos ponto‑a‑ponto. Esse processo, conhecido como “tokenização”, tem ganhado considerável atenção tanto de instituições legadas quanto de startups, devido ao seu potencial de aliviar muitos dos pontos de dor existentes nos mercados de capitais.

Conformidade Regulatória

Embora a blockchain possa facilitar a transferência de propriedade em termos técnicos, os tokens de segurança ainda estão sujeitos às mesmas leis e regulamentos que os valores mobiliários tradicionais. Garantir que os tokens de segurança estejam em conformidade com a regulamentação é, portanto, crítico para qualquer tokenização potencial, e tem sido uma barreira à adoção até o momento. Como pode ser visto no gráfico abaixo, a incerteza regulatória é amplamente considerada a maior barreira à adoção da blockchain.

Numerosos projetos surgiram no espaço blockchain, cada um projetando um protocolo que tenta simplificar e padronizar como os tokens de segurança são regulados, negociados e gerenciados. Olhando apenas para o Ethereum, projetos que publicaram padrões que abordam esse problema incluem Securitize, Harbor, Polymath e outros. Contudo, sem modificações no modo como esses protocolos são atualmente concebidos, investidores e exchanges continuarão a enfrentar atritos significativos ao comprar e vender valores mobiliários tokenizados. Por quê? Interoperabilidade.

A Interoperabilidade é Crucial

A interoperabilidade é um dos benefícios mais significativos da tokenização. Ela permite que todo um ecossistema de aplicações e produtos de mercados de capitais se integrem entre si porque compartilham padrões de software comuns. Contudo, para habilitar a interoperabilidade ao nível de aplicação e produto, ela precisa começar no nível mais baixo, com os próprios tokens. No espaço de tokens de segurança, a interoperabilidade é essencial para duas partes‑chave: exchanges e investidores.

Como exchange, você deseja poder autorizar investidores para a compra de qualquer token de segurança que eles estejam elegíveis a adquirir – independentemente da empresa que criou o token. Isso significa não ter uma integração sob medida com cada token de segurança, mas sim uma integração simples e genérica que seja uniforme em todos os tokens de segurança.

Como investidor, você quer que o processo de onboarding seja o mais simples e livre de atritos possível. Atualmente, quando um investidor deseja comprar ações de múltiplas fontes, ele precisa fornecer suas informações pessoais repetidamente em um processo chamado Conheça Seu Cliente “KYC”. A blockchain tem o potencial de transformar esse processo armazenando essas informações de forma imutável na cadeia, onde podem ser referenciadas por todos os tokens de segurança. Isso significaria não precisar fornecer repetidamente as mesmas informações pessoais toda vez que desejar comprar um novo token, exigindo apenas informações suplementares ou atualizadas após o registro inicial. Contudo, esse processo só será possível se a interoperabilidade entre tokens de segurança for incorporada aos padrões que regem o sistema.

Os Protocolos

Três dos principais protocolos de token de segurança do Ethereum foram publicados por Securitize, Harbor e Polymath. Todos esses protocolos são construídos sobre o padrão de token ERC‑20 do Ethereum, que eles então estendem para impor conformidade na negociação do token de segurança. Isso é alcançado consultando um segundo contrato sobre a legalidade de cada negociação no momento em que ela ocorre.

Embora nomeados de forma diferente nos protocolos, o uso de um segundo contrato é consistente em todos os três, alcançando o mesmo resultado: impedir negociações não‑conformes. Esse segundo contrato “Regulador” é mantido atualizado com as informações de KYC e acreditação dos usuários por serviços off‑chain autorizados a fazê‑lo – por exemplo, uma exchange ou o emissor do token.

Embora esses três componentes possam parecer tudo o que você precisa para regular um token de segurança (e, na forma mais simples, são), é a forma como os componentes são programados que realmente determina a interoperabilidade. Infelizmente, os protocolos carecem de interoperabilidade em duas áreas‑chave, o que continuará a causar atritos e retardar a adoção dessa tecnologia:

1. Como as partes autorizadas atualizam informações on‑chain sobre os usuários?

Harbor

Harbor declara em seu whitepaper que será a única parte autorizada a atualizar informações de usuários on‑chain por enquanto. A centralização desse papel significa que as exchanges não atualizarão quaisquer dados referenciados pelo Regulador. Elas, portanto, não poderão aprovar novos destinatários do token, impedindo que os tokens sejam negociados facilmente fora da plataforma Harbor.

Securitize

Securitize já implementou um sistema no qual múltiplas partes podem ser autorizadas, permitindo que investidores registrem suas informações de conformidade em vários locais e não sejam obrigados a passar pelo Securitize diretamente. Os dados on‑chain são então atualizados diretamente pela parte autorizada e podem ser visualizados por todos os tokens da Securitize. Além disso, para evitar que investidores precisem fornecer informações múltiplas vezes, a Securitize projetou uma API que permite às partes autorizadas acessar as informações privadas sobre investidores armazenadas off‑chain, permitindo determinar facilmente se um indivíduo está em conformidade ou se são necessárias informações adicionais.

Polymath

Polymath possui um token utilitário digital nativo chamado POLY que é exigido em toda a sua plataforma para executar várias tarefas, inclusive para que uma parte autorizada atualize seus dados on‑chain. Para que um indivíduo faça seu próprio KYC, ele primeiro deve comprar tokens POLY, que não possuem um mercado fiat‑para‑POLY líquido. Em vez disso, o indivíduo deve comprar outra criptomoeda, como o “ether” (ETH) da Ethereum, usando fiat, e então trocar por POLY. Os tokens podem então ser usados no marketplace de KYC da Polymath para fazer uma oferta a um provedor de KYC. Se o provedor aprovar a oferta, ele é pago em tokens POLY para realizar a verificação KYC para o indivíduo. Esse processo representa claramente um atrito significativo no onboarding da plataforma Polymath, tornando o procedimento mais complexo do que o necessário.

2. Como essas informações sobre usuários são então armazenadas e acessadas on‑chain?

Harbor

A partir da análise do whitepaper e dos contratos inteligentes no GitHub, é tecnicamente possível que muitos dos tokens da Harbor compartilhem um contrato Regulador comum e uma fonte comum de dados de usuário, porém isso é improvável devido às diferenças regulatórias entre os diferentes tokens. A ausência de tokens Harbor ativos no Ethereum não esclareceu se essa era a intenção deles, ou se cada token será implantado com seu próprio Regulador.

Securitize

O protocolo da Securitize foi projetado de modo que seu contrato Regulador consulte um terceiro contrato inteligente que armazena informações do usuário. Isso permite que cada token tenha regulamentações únicas codificadas em seu próprio Regulador, ao mesmo tempo em que compartilha uma fonte comum de dados de usuário no terceiro contrato, de modo que, quando um usuário faz KYC para um token Securitize, suas informações ficam armazenadas prontas para a compra de tokens futuros.

Polymath

Não está explicitamente declarado no whitepaper da Polymath se há uma fonte central de dados de conformidade armazenada on‑chain com a qual cada Regulador interage, ou se os tokens possuem sua própria fonte local de informações. Contudo, com base nos contratos de exemplo da Polymath, parece que cada token usa uma fonte local de informações, que não é compartilhada entre diferentes tokens. Embora isso possa ter vantagens, essa configuração corre o risco de redundância de dados e inconsistências.

Considere o seguinte exemplo: Bob demonstrou interesse em dois tokens de segurança da Polymath, ABC e DEF, e foi aprovado como investidor para ambos. Essas informações são enviadas ao contrato Regulador de cada token. Um mês depois, Bob tenta comprar mais tokens DEF, mas descobre que ele não está mais acreditado. Essa informação é enviada ao Regulador do DEF para atualizar o status de investidor de Bob para não‑acreditado. Agora, on‑chain, há informações conflitantes: o ABC acredita que Bob é um investidor verificado, porém o DEF discorda. É fácil perceber que ter uma fonte central de informações evitaria tais discrepâncias.

Interoperabilidade dos Protocolos

Conforme discutido anteriormente, há duas partes principais envolvidas na emissão e troca de tokens de segurança para as quais a interoperabilidade será extremamente importante: exchanges e investidores. Ambas as partes desejam uma experiência fluida ao interagir com diferentes tokens de segurança. Portanto, se utilizarmos os protocolos como estão, vamos analisar como exchanges e usuários serão afetados.

Exchanges

Como exchange, integrar esses protocolos para fins de transferência é fácil: todos os tokens utilizam o padrão ERC‑20, oferecendo uma interface uniforme para invocar transferências, aprovações e verificações de saldo. Contudo, a integração adicional com o aspecto de conformidade de cada protocolo torna‑se muito mais complexa. Você deve se lembrar de que atualmente não é possível que uma parte confiável se torne autorizada no protocolo da Harbor – ela terá que direcionar os usuários à Harbor para fazerem seu próprio KYC. Para então integrar com o protocolo da Securitize, a parte confiável deve ser autorizada pela Securitize, o que permitirá o acesso aos dados KYC dos investidores via API off‑chain e a atualização das informações on‑chain armazenadas no repositório de dados on‑chain.

Integrar com o protocolo da Polymath provavelmente é o mais complexo. A parte confiável deve registrar‑se como provedor de KYC no marketplace de KYC da Polymath e configurar‑se para receber lances em tokens POLY em troca da prestação de serviços de KYC. Ao prestar serviços de KYC a investidores, a parte confiável deve então organizar uma forma de garantir que os dados on‑chain duplicados armazenados sobre um usuário em cada Regulador de segurança não se tornem inconsistentes.

Não apenas os protocolos têm interfaces diferentes que a parte confiável deve integrar, cada protocolo também possui um método distinto de relatar erros à exchange. Ao construir uma interface, é importante poder traduzir quaisquer erros que ocorram para algo compreensível pelos usuários. Por exemplo, se um usuário não puder comprar um token, isso pode ocorrer por uma variedade de razões: o valor mobiliário pode ter um período de retenção ainda não satisfeito, ou pode restringir o número máximo de detentores permitidos. Para comunicar essas mensagens aos usuários, a exchange teria que integrar um método de relatório de erros diferente para cada protocolo.

Investidores 

Os diferentes métodos pelos quais o onboarding de investidores é atualmente projetado nos protocolos significam que os investidores provavelmente terão que fornecer informações pessoais muitas vezes a diferentes plataformas e de maneiras distintas. Isso ocorre porque a Harbor não autorizou nenhuma outra parte, e a Polymath exige que investidores façam lances para processos de KYC usando tokens POLY. O atrito causado pela imposição desses métodos de conformidade pode fazer com que investidores se recusem ou sejam incapazes de comprar valores mobiliários que de outra forma adquiririam.

A escala desse atrito induzido pelos protocolos nos investidores pode ser parcialmente atenuada pela forma como as exchanges integram cada um dos protocolos. Por exemplo, se um investidor escolher fazer KYC em uma exchange para comprar um token da Polymath, essa exchange, se autorizada, poderia optar por atualizar o armazenamento de dados da Securitize ao mesmo tempo. Isso faria com que as informações do investidor ficassem on‑chain caso fossem necessárias no futuro. Contudo, se nenhuma mudança for feita nos designs atuais dos protocolos, o processo de registro e compra de valores mobiliários permanecerá intimidante.

Soluções

A solução para esse problema não precisa ser complexa. Na verdade, é possível introduzir certas soluções sem alterar nenhum token que já esteja ativo no Ethereum. Uma solução ideal que resulte em atrito mínimo tanto para exchanges quanto para investidores, e que evite inconsistências de dados causadas por múltiplas fontes de dados de conformidade, se assemelharia ao armazenamento centralizado de dados on‑chain da Securitize; porém, tal configuração precisaria ser adotada em escala setorial.

Ao ter uma fonte central de informações on‑chain, os riscos de inconsistências de dados são eliminados, e os investidores podem comprar diferentes valores mobiliários através de uma única verificação de conformidade. Esse contrato central realizaria a verificação de que a transferência está em conformidade para todos os tokens de segurança, e a transferência continuaria ou seria revertida. A API off‑chain acessível a todas as exchanges autorizadas permite que as informações de conformidade dos investidores sejam comunicadas às exchanges, reduzindo o número de vezes que os investidores precisam fornecer dados. Esses aspectos, juntos, também reduzem massivamente a quantidade de trabalho de integração exigida das exchanges.

A introdução de um novo sistema como este claramente gera algumas complicações, e várias questões ainda precisariam ser resolvidas. Por exemplo, no design de como cada exchange se torna autorizada: quem decide que uma exchange deve ser confiável? É necessário tempo para projetar um sistema que permita alcançar consenso.

Conclusão

A tokenização de valores mobiliários ainda é uma área em estágio inicial de desenvolvimento e adoção, em parte devido às complexidades da conformidade regulatória. Embora a publicação de protocolos simplifique a conformidade com muitas dessas regulamentações ao possibilitar sua aplicação na execução de cada transferência, ainda há um longo caminho a percorrer antes que isso se torne um processo fluido. Até que haja um acordo entre os protocolos sobre como as informações dos investidores são armazenadas e atualizadas tanto on‑chain quanto off‑chain, continuará existindo atrito significativo nos processos de registro e investimento para todas as partes envolvidas.