Behovet av interoperabilitet i säkerhetstokenprotokoll – Thought Leaders

En kort historia om token

Det har gått mer än 10 år sedan Bitcoin först introducerade blockkedjeteknik för världen. Under den tiden har listan över potentiella användningsområden för distribuerade liggare expanderat snabbt, från digitala valutor till leveranskedjor och identitetshantering. I grunden har dock många av dessa användningsfall en liknande struktur: de möjliggör för användare att hålla och överföra digitala tillgångar på en peer‑to‑peer‑basis. Enkelt uttryckt kan vi nu handla och spåra digitala tillgångar utan att behöva en central betrodd myndighet för att hantera processen.

Denna utveckling av området ledde naturligt till uppfinningen av “token” – digitala tillgångar på en blockkedja som är ägda och överförbara mellan individer. Token delas in i två huvudkategorier: de som representerar en nativt digital tillgång, och de som representerar en underliggande verklig tillgång. Genom att utnyttja detta nya paradigm har redan hundratusentals olika token skapats på enbart Ethereum, med ett samlat marknadsvärde på över 15 miljarder dollar vid skrivtillfället.

En av de mest lovande tillämpningarna av token är representationen av verkliga värdepapper på kedjan, vilket möjliggör att traditionellt illikvida tillgångar som kommersiella fastigheter kan fraktioneras och överföras peer‑to‑peer. Denna process, känd som “tokenisering”, har fått betydande uppmärksamhet både från etablerade institutioner och nya start‑ups, på grund av dess potential att lindra många befintliga smärtpunkter inom kapitalmarknaderna.

Regulatorisk efterlevnad

Även om blockkedjan kan göra det enklare att tekniskt överföra ägande, är säkerhetstoken fortfarande föremål för samma lagar och regler som traditionella värdepapper. Att säkerställa att säkerhetstoken är förenliga med regler är därför kritiskt för varje potentiell tokenisering, och har hittills varit ett hinder för antagandet. Som diagrammet nedan visar, anses regulatorisk osäkerhet allmänt vara den största hindret för blockkedjeantagande.

Ett flertal projekt har dykt upp i blockkedjeområdet, där varje projekt designar ett protokoll som försöker förenkla och standardisera hur säkerhetstoken regleras, handlas och hanteras. Enbart på Ethereum finns projekt som har publicerat standarder för att tackla detta problem, inklusive Securitize, Harbor, Polymath och flera fler. Men i slutändan, utan förändringar i hur dessa protokoll för närvarande är designade, kommer investerare och börser fortsätta uppleva betydande friktion när de köper och säljer tokeniserade värdepapper. Varför? Interoperabilitet.

Interoperabilitet är avgörande

Interoperabilitet är en av de mest betydelsefulla fördelarna med tokenisering. Det möjliggör att ett helt ekosystem av kapitalmarknadsapplikationer och produkter kan integreras med varandra eftersom de delar gemensamma mjukvarustandarder. För att möjliggöra interoperabilitet på applikations‑ och produktnivå måste det dock börja på den lägsta nivån med själva tokenen. Inom säkerhetstokenområdet är interoperabilitet väsentlig för två nyckelparter: börser och investerare.

Som en börs vill du kunna auktorisera investerare för köp av vilken säkerhetstoken de är berättigade att köpa – oavsett vilket företag som skapade tokenen. Detta innebär att du inte behöver en skräddarsydd integration med varje säkerhetstoken, utan en enkel och generisk integration som är enhetlig över alla säkerhetstoken.

Som investerare vill du att onboarding‑processen ska vara så enkel och friktionsfri som möjligt. Idag, när en investerare vill köpa aktier från flera platser, måste de lämna sina personuppgifter om och om igen i en process som kallas Know Your Customer “KYC”. Blockkedjan har potentialen att transformera denna process genom att lagra informationen oföränderligt på kedjan, där den sedan kan refereras av alla säkerhetstoken. Detta skulle innebära att du inte längre behöver upprepa samma personuppgifter varje gång du vill köpa en ny token, utan endast kompletterande eller uppdaterad information skulle krävas efter den initiala registreringen. Detta är dock bara möjligt om interoperabilitet mellan säkerhetstoken är inbyggd i de standarder som styr systemet.

Protokollen

Tre av Ethereums ledande säkerhetstoken‑protokoll publicerades av Securitize, Harbor och Polymath. Alla tre protokollen är byggda på Ethereums ERC‑20‑tokenstandard, som de sedan utökar för att verkställa efterlevnad i handeln med säkerhetstoken. Detta uppnås genom att fråga ett andra kontrakt om lagligheten för varje handel i det ögonblick den sker.

Även om de benämns olika i protokollen, är användningen av ett andra kontrakt konsekvent i samtliga tre, vilket ger samma resultat: att förhindra icke‑efterlevande affärer. Detta andra ‘Regulator’-kontrakt hålls uppdaterat med användarnas KYC‑ och ackrediteringsinformation av off‑chain‑tjänster som är auktoriserade att göra så – till exempel en börs eller tokenens utfärdare.

Även om dessa tre komponenter kan verka som allt du behöver för att reglera en säkerhetstoken (och i sin enklaste form är de det), är det hur komponenterna programmeras som verkligen avgör interoperabiliteten. Tyvärr saknar protokollen interoperabilitet i två nyckelområden, vilket kommer att fortsätta orsaka friktion och bromsa antagandet av denna teknik:

1. Hur uppdaterar auktoriserade parter on‑chain‑information om användare?

Harbor

Harbor deklarerar i sitt whitepaper att de för närvarande kommer vara den enda part som är auktoriserad att uppdatera användarinformation on‑chain. Centraliseringen av denna roll innebär att börser inte skulle uppdatera någon data som refereras av Regulatorn. De skulle därför inte kunna godkänna nya mottagare av tokenen, vilket förhindrar att tokenen enkelt kan handlas utanför Harbor‑plattformen.

Securitize

Securitize har redan implementerat ett system där flera parter kan auktoriseras, vilket betyder att investerare kan registrera sin efterlevnadsinformation på flera ställen och inte är tvungna att gå via Securitize själva. On‑chain‑datan uppdateras sedan direkt av den auktoriserade parten och kan ses av alla Securitize‑token. Dessutom, för att förhindra att investerare måste lämna information flera gånger, har Securitize designat ett API som tillåter auktoriserade parter att komma åt den privata informationen om investerare som lagras off‑chain, vilket gör det enkelt att avgöra om en individ är efterlevande eller om mer information behövs.

Polymath

Polymath har en inbyggd digital nyttojon som heter POLY och som krävs genom hela deras plattform för att utföra olika uppgifter, inklusive att få en auktoriserad part att uppdatera din on‑chain‑data. För att en individ ska kunna KYC‑a sig själv måste de först köpa POLY‑token, vilket inte har en likvid fiat‑till‑POLY‑marknad. Istället måste individen köpa en annan kryptovaluta, såsom Ethereums “ether” (ETH) med fiat, och sedan byta den mot POLY. Tokenen kan sedan användas på Polymaths KYC‑marknadsplats för att lägga ett bud till en KYC‑leverantör. Om KYC‑leverantören godkänner erbjudandet, betalas de i POLY‑token för att utföra KYC‑kontrollen för individen. Denna process är tydligt en betydande onboarding‑friktion för Polymath‑plattformen och gör processen mer komplex än nödvändigt.

2. Hur lagras och nås denna information om användare sedan on‑chain?

Harbor

Genom att granska whitepaper och smarta kontrakt på GitHub är det tekniskt möjligt för många av Harbors token att dela ett gemensamt Regulator‑kontrakt och en gemensam källa för användardata, men detta är osannolikt på grund av skillnader i reglering mellan olika token. Avsaknaden av levande Harbors token på Ethereum har inte klargjort om det är deras avsikt att detta ska vara fallet, eller om varje token kommer att distribueras med sin egen Regulator.

Securitize

Securitizes protokoll är designat så att deras Regulator‑kontrakt frågar ett tredje smart kontrakt som lagrar användarinformation. Detta möjliggör att varje token har unika regler kodade i sin egen Regulator, samtidigt som de delar en gemensam källa för användardata i det tredje kontraktet, vilket betyder att när en användare KYC‑ar för en Securitize‑token lagras informationen och är redo för dem att köpa framtida token.

Polymath

Det är inte explicit angivet i deras whitepaper huruvida Polymath har en central källa för efterlevnadsdata lagrad on‑chain som varje Regulator sedan interagerar med, eller om token har sin egen lokala informationskälla. Men baserat på Polymaths exempelkontrakt verkar det som att varje token använder en lokal informationskälla, som inte delas mellan olika token. Även om detta kan ha fördelar, riskerar denna uppsättning datadubbletter och inkonsekvenser.

Ta följande exempel: Bob har uttryckt intresse för två Polymath‑säkerhetstoken, ABC och DEF, och har godkänts som investerare för båda. Denna information skickas till Regulator‑kontraktet för varje token. En månad senare försöker Bob köpa fler DEF‑token men det visar sig att han inte längre är ackrediterad. Denna information skickas till DEF:s Regulator för att uppdatera Bobs investerarsstatus till icke‑ackrediterad. På kedjan finns nu motstridig information: ABC tror att Bob är en verifierad investerare, men DEF håller inte med. Det är lätt att se att en central informationskälla skulle förhindra sådana avvikelser.

Interoperabilitet av protokollen

Som tidigare diskuterat finns två huvudparter involverade i utfärdandet och handeln med säkerhetstoken för vilka interoperabilitet kommer att vara av stor betydelse: börser och investerare. Båda dessa parter önskar en smidig upplevelse när de interagerar med olika säkerhetstoken. Så, om vi använder protokollen som de är, låt oss titta på hur börser och användare kommer att påverkas.

Börser

Som en börs är integration av dessa protokoll för överföringsändamål enkel: alla token använder ERC‑20‑standarden, vilket ger ett enhetligt gränssnitt för att initiera överföringar, godkännanden och saldo‑kontroller. Men vidare integration med efterlevnadsaspekten av varje protokoll blir mycket mer komplex. Du kommer ihåg att det för närvarande inte är möjligt för en betrodd part att bli auktoriserad på Harbors protokoll – de måste istället dirigera användare till Harbor för att KYC‑a sig själva. För att sedan integrera med Securitizes protokoll måste den betrodda parten vara auktoriserad av Securitize, vilket då tillåter dem att komma åt investerarnas KYC‑data via off‑chain‑API:t och att uppdatera on‑chain‑information lagrad i den on‑chain‑databasen.

Att integrera med Polymaths protokoll är sannolikt det mest komplexa. Den betrodda parten måste registrera sig som KYC‑leverantör på Polymaths KYC‑marknadsplats och sätta upp sig för att ta emot bud i POLY‑token i utbyte mot att tillhandahålla KYC‑tjänster. När de tillhandahåller KYC‑tjänster till investerare måste den betrodda parten sedan organisera ett sätt att säkerställa att den duplicerade on‑chain‑data som lagras om en användare i varje säkerhets Regulator④ inte blir inkonsekvent.

Inte bara har protokollen olika gränssnitt som den betrodda parten måste integrera med, varje protokoll har också ett annat sätt att tillhandahålla felrapportering till börsen. När man bygger ett gränssnitt är det viktigt att kunna översätta eventuella fel till något som är förståeligt för användarna. Till exempel, om en användare inte kan köpa en token kan det bero på en rad olika orsaker: säkerheten kan ha en hållningsperiod som ännu inte har uppfyllts, eller så kan den begränsa det maximala antalet tillåtna innehavare. För att kunna kommunicera dessa meddelanden till användarna måste börsen integrera med en annan felrapporteringsmetod för varje protokoll.

Investerare 

De olika metoderna för hur onboarding av investerare för närvarande är designade i protokollen innebär att investerare sannolikt måste lämna personlig information många gånger till olika plattformar och på olika sätt. Detta beror på att Harbor inte har auktoriserat någon annan part, och Polymath kräver att investerare lägger bud på KYC‑processer med POLY‑token. Friktionen som orsakas av dessa efterlevnadsmetoder kan göra att investerare är ovilliga eller oförmögna att köpa värdepapper de annars skulle köpa.

Skalan av denna protokollinducerade friktion för investerare kan delvis mildras av hur börser går till väga för att integrera varje protokoll. Till exempel, om en investerare väljer att KYC‑a på en börs för att köpa en Polymath‑token, kan den börsen, om den är auktoriserad, samtidigt välja att uppdatera Securitizes datalagring. Detta skulle innebära att investerarens information finns on‑chain ifall den behövs i framtiden. Men om inga förändringar görs i de nuvarande protokoll‑designerna, kommer processen för registrering och köp av värdepapper förbli avskräckande.

Lösningar

Lösningen på detta problem behöver inte vara komplex. Faktum är att det är möjligt att införa vissa lösningar utan att ändra några token som redan är live på Ethereum. En ideal lösning som ger minimal friktion för både börser och investerare, och som förhindrar datainkonsekvenser orsakade av många olika källor för efterlevnadsdata, skulle starkt likna Securitizes centraliserade on‑chain‑databutik; dock måste en sådan uppsättning antas på branschomfattande skala.

Genom att ha en central källa för information on‑chain tas risken för datainkonsekvenser bort, och investerare kan köpa olika värdepapper genom bara en efterlevnadsverifiering. Detta centrala kontrakt skulle utföra verifieringen att överföringen var förenlig för alla säkerhetstoken, och överföringen skulle fortsätta eller återkallas. Det off‑chain‑API som är tillgängligt för alla auktoriserade börser innebär att investerarnas efterlevnadsinformation kan kommuniceras till börser och minskar antalet gånger investerare måste bli ombedda att lämna data. Dessa aspekter tillsammans minskar också avsevärt mängden integrationsarbete som krävs av börser.

Införandet av ett nytt system som detta medför naturligtvis vissa komplikationer, och ett antal frågor måste fortfarande lösas. Till exempel i designen av hur varje börs blir auktoriserad: vem fattar beslutet att en börs ska vara betrodd? Tid måste avsättas för att designa ett system som möjliggör konsensus.

Slutsats

Tokenisering av värdepapper är fortfarande ett område som befinner sig i ett tidigt utvecklings- och antagningsstadium, delvis på grund av komplexiteten i regulatorisk efterlevnad. Även om publiceringen av protokoll förenklar efterlevnaden av många av dessa regler genom att möjliggöra att de verkställs i varje överföringsutförande, återstår en lång väg innan detta blir en sömlös process. Tills vi har ett avtal mellan protokollen om hur investerarinformation lagras och uppdateras både on‑chain och off‑chain, kommer betydande friktion att bestå genom registrerings‑ och investeringsprocesserna för alla inblandade parter.