De noodzaak van interoperabiliteit in security token-protocollen – Thought Leaders

Een korte geschiedenis van tokens

Het is nu meer dan 10 jaar geleden sinds Bitcoin voor het eerst blockchain‑technologie aan de wereld introduceerde. In die tijd is de lijst met potentiële use‑cases voor gedistribueerde grootboeken snel gegroeid, van digitale valuta’s tot toeleveringsketens en identiteitsbeheer. In de kern volgen veel van deze use‑cases echter een vergelijkbare structuur: ze stellen gebruikers in staat digitale activa te houden en over te dragen op een peer‑to‑peer basis. Simpel gezegd kunnen we nu digitale activa verhandelen en volgen zonder een centrale, vertrouwde autoriteit die het proces beheert.

Deze evolutie van de ruimte leidde natuurlijk tot de uitvinding van “tokens” – digitale activa op een blockchain die eigendom kunnen zijn en overdraagbaar tussen individuen. Tokens worden opgesplitst in twee hoofd‑categorieën: diegenen die een natively digitaal actief vertegenwoordigen, en diegenen die een onderliggend real‑world actief vertegenwoordigen. Door dit nieuwe paradigma te benutten, zijn er al honderden duizenden verschillende tokens gecreëerd op alleen Ethereum, met een gecombineerde marktkapitalisatie van meer dan $15 billion op het moment van schrijven.

Een van de meest veelbelovende toepassingen van tokens is de weergave van real‑world effecten on‑chain, waardoor traditioneel illiquide activa zoals commercieel vastgoed gefractioneerd en peer‑to‑peer kunnen worden overgedragen. Dit proces, bekend als “tokenisatie”, heeft aanzienlijke aandacht gekregen van zowel legacy‑instellingen als nieuwe start‑ups, vanwege het potentieel om veel bestaande pijnpunten binnen de kapitaalmarkten te verlichten.

Regelgevende naleving

Hoewel blockchain het technisch gezien makkelijker kan maken om eigendom over te dragen, blijven security tokens onderworpen aan dezelfde wetten en regelgeving als traditionele effecten. Het waarborgen dat security tokens voldoen aan de regelgeving is daarom cruciaal voor elke potentiële tokenisatie, en is tot nu toe een belemmering voor adoptie geweest. Zoals te zien is in de onderstaande grafiek, wordt regelgevende onzekerheid algemeen beschouwd als de grootste barrière voor blockchain‑adoptie.

Talrijke projecten zijn ontstaan in de blockchain‑ruimte, elk met een protocol dat probeert te vereenvoudigen en te standaardiseren hoe security tokens worden gereguleerd, verhandeld en beheerd. Alleen al op Ethereum zijn er projecten die standaarden hebben gepubliceerd om dit probleem aan te pakken, waaronder Securitize, Harbor, Polymath en meer. Echter, zonder aanpassingen aan de manier waarop deze protocollen momenteel zijn ontworpen, zullen investeerders en beurzen blijven worstelen met aanzienlijke frictie bij het kopen en verkopen van getokeniseerde effecten. Waarom? Interoperabiliteit.

Interoperabiliteit is cruciaal

Interoperabiliteit is een van de meest significante voordelen van tokenisatie. Het stelt een heel ecosysteem van kapitaalmarkt‑applicaties en -producten in staat om met elkaar te integreren omdat ze gemeenschappelijke software‑standaarden delen. Om interoperabiliteit op applicatie‑ en productniveau mogelijk te maken, moet dit echter beginnen op het laagste niveau: bij de tokens zelf. In de security token‑ruimte is interoperabiliteit essentieel voor twee belangrijke partijen: beurzen en investeerders.

Als beurs wil je in staat zijn investeerders te autoriseren voor de aankoop van elk security token dat zij mogen kopen – ongeacht het bedrijf dat het token heeft gecreëerd. Dit betekent dat je geen op maat gemaakte integratie per security token nodig hebt, maar een eenvoudige en generieke integratie die uniform is voor alle security tokens.

Als investeerder wil je dat het onboarding‑proces zo eenvoudig en frictieloos mogelijk is. Momenteel moet een investeerder die aandelen van meerdere plaatsen wil kopen telkens opnieuw zijn persoonlijke gegevens verstrekken in een proces dat Know Your Customer “KYC” wordt genoemd. Blockchain heeft het potentieel dit proces te transformeren door deze informatie onveranderlijk on‑chain op te slaan, waar alle security tokens ernaar kunnen verwijzen. Dit zou betekenen dat je niet telkens dezelfde persoonlijke gegevens hoeft te verstrekken bij elke nieuwe token‑aankoop; alleen aanvullende of bijgewerkte informatie zou nodig zijn na de initiële registratie. Dit proces zal echter alleen mogelijk zijn als interoperabiliteit tussen security tokens is ingebouwd in de standaarden die het systeem regelen.

De protocollen

Drie van de toonaangevende security token‑protocollen op Ethereum zijn gepubliceerd door Securitize, Harbor en Polymath. Alle drie deze protocollen zijn gebouwd op de ERC‑20 token‑standaard van Ethereum, die ze vervolgens uitbreiden om naleving af te dwingen bij de handel in het security token. Dit wordt bereikt door een tweede contract te raadplegen over de legaliteit van elke transactie op het moment dat deze plaatsvindt.

Hoewel ze in de protocollen verschillend worden genoemd, is het gebruik van een tweede contract consistent in alle drie, met hetzelfde resultaat: het voorkomen van niet‑conforme transacties. Dit tweede ‘Regulator’-contract wordt up‑to‑date gehouden met de KYC‑ en accreditatie‑informatie van gebruikers door off‑chain diensten die daartoe geautoriseerd zijn – bijvoorbeeld een beurs of de uitgever van het token.

Hoewel deze drie componenten misschien lijken op alles wat je nodig hebt om een security token te reguleren (en in de eenvoudigste vorm zijn ze dat), is het de manier waarop de componenten geprogrammeerd zijn die echt de interoperabiliteit bepaalt. Helaas missen de protocollen interoperabiliteit op twee cruciale gebieden, wat zal blijven zorgen voor frictie en een trage adoptie van deze technologie:

1. Hoe werken geautoriseerde partijen on-chain informatie over gebruikers bij?

Harbor

Harbor verklaart in hun whitepaper dat zij voorlopig de enige partij zullen zijn die geautoriseerd is om gebruikersinformatie on-chain bij te werken. De centralisatie van deze rol betekent dat beurzen geen data die door de Regulator worden geraadpleegd, zouden bijwerken. Ze zullen daarom niet in staat zijn nieuwe ontvangers van het token goed te keuren, waardoor tokens niet gemakkelijk buiten het Harbor‑platform verhandeld kunnen worden.

Securitize

Securitize heeft al een systeem geïmplementeerd waarbij meerdere partijen geautoriseerd kunnen worden, waardoor investeerders hun nalevingsinformatie op meerdere plaatsen kunnen registreren en niet via Securitize zelf hoeven te gaan. De on-chain data wordt vervolgens direct bijgewerkt door de geautoriseerde partij, en kan worden bekeken door al de tokens van Securitize. Bovendien, om te voorkomen dat investeerders informatie meerdere keren moeten verstrekken, heeft Securitize een API ontworpen waarmee geautoriseerde partijen toegang krijgen tot de privé‑informatie over investeerders die off‑chain is opgeslagen, zodat ze gemakkelijk kunnen bepalen of een individu compliant is of dat er meer informatie nodig is.

Polymath

Polymath heeft een native digitale utility‑token genaamd POLY die vereist is door hun platform om verschillende taken uit te voeren, inclusief het laten bijwerken van je on-chain data door een geautoriseerde partij. Om zichzelf te KYC‑en moet een individu eerst POLY‑tokens kopen, maar er bestaat geen liquide fiat‑naar‑POLY‑markt. In plaats daarvan moet het individu een andere cryptocurrency, zoals Ethereum’s “ether” (ETH), met fiat kopen en deze vervolgens omwisselen voor POLY. De tokens kunnen vervolgens worden gebruikt op Polymath’s KYC‑marktplaats om een bod te doen op een KYC‑provider. Als de KYC‑provider het bod accepteert, wordt hij in POLY‑tokens betaald om de KYC‑check voor het individu uit te voeren. Dit proces vormt duidelijk een aanzienlijke onboarding‑frictie voor het Polymath‑platform en maakt het proces onnodig complex.

2. Hoe deze informatie over gebruikers vervolgens wordt opgeslagen en opgevraagd on-chain?

Harbor

Uit een blik op de whitepaper en de smart contracts op GitHub blijkt dat het technisch mogelijk is dat veel van Harbor’s tokens één gemeenschappelijk Regulator‑contract delen, en één gemeenschappelijke bron van gebruikersdata, hoewel dit onwaarschijnlijk is vanwege de verschillen in regelgeving tussen verschillende tokens. Het ontbreken van live Harbor‑tokens op Ethereum heeft niet verduidelijkt of dit hun intentie is, of dat elk token met een eigen Regulator wordt uitgerold.

Securitize

Het protocol van Securitize is zo ontworpen dat hun Regulator‑contract een derde smart contract raadpleegt dat gebruikersinformatie opslaat. Dit stelt elk token in staat unieke regelgeving te coderen in hun eigen individuele Regulator, terwijl ze toch een gemeenschappelijke bron van gebruikersdata delen in het derde contract, waardoor wanneer een gebruiker KYC‑t voor één Securitize‑token, zijn informatie klaarstaat voor toekomstige token‑aankopen.

Polymath

In hun whitepaper wordt niet expliciet vermeld of Polymath een centrale bron van compliance‑data on-chain heeft die elke Regulator aanspreekt, of dat tokens hun eigen lokale bron van informatie hebben. Op basis van Polymath’s voorbeeldcontracten lijkt echter elk token een lokale informatiebron te gebruiken, die niet wordt gedeeld tussen verschillende tokens. Hoewel dit voordelen kan hebben, brengt deze opzet risico’s van data‑redundantie en inconsistenties met zich mee.

Neem het volgende voorbeeld: Bob heeft interesse getoond in twee Polymath security tokens, ABC en DEF, en is voor beide als investeerder goedgekeurd. Deze informatie wordt naar het Regulator‑contract van elk token gestuurd. Een maand later probeert Bob meer DEF‑tokens te kopen, maar blijkt dat hij niet langer geaccrediteerd is. Deze informatie wordt naar DEF’s Regulator gestuurd om Bob’s investeerdersstatus bij te werken naar niet‑geaccrediteerd. Nu is er on‑chain tegenstrijdige informatie: ABC denkt dat Bob een geverifieerde investeerder is, terwijl DEF het oneens is. Het is duidelijk dat een centrale informatiebron dergelijke discrepanties zou voorkomen.

Interoperabiliteit van de protocollen

Zoals eerder besproken, zijn er twee hoofd‑partijen betrokken bij de uitgifte en uitwisseling van security tokens waarvoor interoperabiliteit van groot belang zal zijn: beurzen en investeerders. Beide partijen verlangen een soepele ervaring bij interactie met verschillende security tokens. Dus, als we de protocollen zoals ze zijn gebruiken, laten we kijken hoe beurzen en gebruikers worden beïnvloed.

Beurzen

Als beurs is het integreren van deze protocollen voor overdrachtsdoeleinden eenvoudig: alle tokens maken gebruik van de ERC‑20 token‑standaard, waardoor een uniforme interface beschikbaar is om transfers, goedkeuringen en saldo‑controles aan te roepen. Echter, verdere integratie met het compliance‑aspect van elk protocol wordt veel complexer. Je herinnert je dat het momenteel niet mogelijk is voor een vertrouwde partij om geautoriseerd te worden op Harbor’s protocol – zij moeten gebruikers in plaats daarvan naar Harbor sturen om zelf KYC te doen. Om vervolgens te integreren met Securitize’s protocol, moet de vertrouwde partij geautoriseerd worden door Securitize, waardoor zij toegang krijgen tot investeerder‑KYC‑data via de off‑chain API, en on‑chain informatie kunnen bijwerken die in de on‑chain datastore is opgeslagen.

Integreren met Polymath’s protocol is waarschijnlijk het meest complex. De vertrouwde partij moet zich registreren als KYC‑provider op Polymath’s KYC‑marktplaats en zich opzetten om biedingen in POLY‑tokens te ontvangen in ruil voor het leveren van KYC‑diensten. Bij het leveren van KYC‑diensten aan investeerders moet de vertrouwde partij vervolgens een manier organiseren om ervoor te zorgen dat de duplicatieve on‑chain data die over een gebruiker in elke security’s Regulator④ wordt opgeslagen, niet inconsistent wordt.

Niet alleen hebben de protocollen verschillende interfaces waarmee de vertrouwde partij moet integreren, elk protocol heeft ook een andere manier om foutmeldingen aan de beurs te rapporteren. Bij het bouwen van een interface is het belangrijk om eventuele fouten die optreden te vertalen naar iets dat begrijpelijk is voor gebruikers. Bijvoorbeeld, als een gebruiker geen token kan kopen, kan dit om een breed scala aan redenen zijn: de security kan een houdingsperiode hebben die nog niet is vervuld, of kan het maximale aantal houders beperken. Om deze berichten aan gebruikers te kunnen communiceren, moet de beurs integreren met een andere fout‑rapportagemethode voor elk protocol.

Investeerders

De verschillende methoden waarop onboarding van investeerders momenteel in de protocollen is ontworpen, betekenen dat investeerders waarschijnlijk hun persoonlijke informatie vele malen moeten verstrekken aan verschillende platforms en op verschillende manieren. Dit wordt veroorzaakt doordat Harbor geen andere partijen heeft geautoriseerd, en Polymath investeerders vereist om te bieden voor KYC‑processen met POLY‑tokens. De frictie die wordt veroorzaakt door de handhaving van deze compliance‑methoden kan ervoor zorgen dat investeerders onwillig of niet in staat zijn de effecten te kopen die ze anders wel zouden kopen.

De schaal van deze door het protocol veroorzaakte frictie voor investeerders kan enigszins worden verzacht door de manier waarop beurzen elk van de protocollen integreren. Bijvoorbeeld, als een investeerder ervoor kiest om KYC te doen op een beurs om een Polymath‑token te kopen, zou die beurs, indien geautoriseerd, tegelijkertijd Securitize’s data‑opslag kunnen bijwerken. Dit zou betekenen dat de informatie van de investeerder on‑chain is voor het geval deze in de toekomst nodig is. Echter, als er geen wijzigingen worden aangebracht in de huidige protocol‑ontwerpen, blijft het proces van registreren en effecten kopen ontmoedigend.

Oplossingen

De oplossing voor dit probleem hoeft niet complex te zijn. In feite is het mogelijk bepaalde oplossingen te introduceren zonder enige bestaande tokens op Ethereum te wijzigen. Een ideale oplossing die minimale frictie oplevert voor zowel beurzen als investeerders, en die data‑inconsistenties veroorzaakt door vele verschillende bronnen van compliance‑data voorkomt, zou sterk lijken op Securitize’s gecentraliseerde on‑chain datastore; echter, een dergelijke opzet moet dan op industriële schaal worden geadopteerd.

Door een centrale bron van informatie on‑chain te hebben, wordt het risico op data‑inconsistenties verwijderd, en kunnen investeerders verschillende effecten kopen via slechts één compliance‑verificatie. Dit centrale contract zou de verificatie uitvoeren dat de overdracht compliant was voor alle security tokens, en de overdracht zou doorgaan of terugdraaien. De off‑chain API die toegankelijk is voor alle geautoriseerde beurzen betekent dat investeerder‑compliance‑informatie kan worden gecommuniceerd naar beurzen en het aantal keren dat investeerders data moeten verstrekken, wordt verminderd. Deze aspecten samen verminderen ook massaal de hoeveelheid integratiewerk die beurzen nodig hebben.

De introductie van een nieuw systeem als dit brengt duidelijk enkele complicaties met zich mee, en een aantal kwesties moet nog worden uitgewerkt. Bijvoorbeeld in het ontwerp van hoe elke beurs geautoriseerd wordt: wie neemt de beslissing dat een beurs vertrouwd moet worden? Er moet tijd worden genomen om een systeem te ontwerpen dat consensus mogelijk maakt.

Conclusie

De tokenisatie van effecten is nog een gebied dat zich in een vroeg stadium van ontwikkeling en adoptie bevindt, deels vanwege de complexiteit van regelgevende naleving. Terwijl de publicatie van protocollen de naleving van veel van deze regelgevingen vereenvoudigt door ze af te dwingen in de uitvoering van elke overdracht, is er nog een lange weg te gaan voordat dit een naadloos proces is. Totdat we een overeenkomst hebben tussen protocollen over hoe investeerder‑informatie zowel on‑chain als off‑chain wordt opgeslagen en bijgewerkt, zal er aanzienlijke frictie blijven bestaan gedurende de registratie‑ en investeringsprocessen voor alle betrokken partijen.