Tankeledere

Behovet for interoperabilitet i sikkerhedstoken-protokoller – Thought Leaders

mm
Føj Securities.io til dine foretrukne kilder på Google
Oplysning: Securities.io kan modtage betaling, når du bruger links til produkter, vi anmelder. Det påvirker ikke vores redaktionelle vurderinger. Vi er ikke registreret investeringsrådgiver; dette er ikke investeringsrådgivning. Læs vores affiliateoplysning.
Redaktørens note:
Denne artikel blev indsendt eksternt under den tidlige udvikling af sikkerhedstoken-standarder. Den afspejler tilstanden af Ethereum-baserede overholdelsesprotokoller og interoperabilitetsudfordringer på tidspunktet for skrivning. Selvom de specifikke implementeringer, der diskuteres, siden da er udviklet, forbliver de arkitektoniske afvejninger og friktionspunkter, der er skitseret her, nyttig historisk kontekst for at forstå, hvorfor tidlige tokeniseringsforsøg havde svært ved at opnå skala.

En kort historie om tokens

Det er nu over 10 år siden, Bitcoin først introducerede blockchain-teknologi for verden. I den periode er listen over potentielle anvendelsesområder for distribuerede registre vokset hurtigt, fra digitale valutaer til forsyningskæder til identitetsstyring. I deres kerne har mange af disse anvendelsestilfælde dog en lignende struktur: de gør det muligt for brugere at holde og overføre digitale aktiver peer-to-peer. Simpelt sagt kan vi nu handle og spore digitale aktiver uden at skulle have en central betroet myndighed til at styre processen.

Denne udvikling af området førte naturligt til opfindelsen af “tokens” – digitale aktiver på en blockchain, som kan ejes og overføres mellem individer. Tokens er opdelt i to hovedkategorier: dem, der repræsenterer et indfødt digitalt aktiv, og dem, der repræsenterer et underliggende real-world aktiv. Ved at udnytte dette nye paradigme er hundredtusinder af forskellige tokens allerede blevet oprettet på Ethereum alene, med en samlet markedsværdi på over 15 milliarder dollars på tidspunktet for skrivning.

En af de mest lovende anvendelser af tokens er repræsentationen af real-world værdipapirer on-chain, hvilket gør det muligt for traditionelt illikvide aktiver som erhvervsejendomme at blive fraktioneret og overført peer-to-peer. Denne proces, kendt som “tokenisering”, har opnået betydelig opmærksomhed fra både etablerede institutioner og nye start-ups, på grund af dens potentiale til at afhjælpe mange eksisterende smertepunkter inden for kapitalmarkederne.

Regulatorisk overholdelse

Selvom blockchain kan gøre det teknisk lettere at overføre ejerskab, er sikkerhedstokens stadig underlagt de samme love og reguleringer som traditionelle værdipapirer. At sikre, at sikkerhedstokens er i overensstemmelse med reguleringerne, er derfor kritisk for enhver potentiel tokenisering, og har indtil nu udgjort en barriere for adoption. Som det ses i diagrammet nedenfor, betragtes regulatorisk usikkerhed bredt som den største hindring for blockchain-adoption.

Talrige projekter er opstået i blockchain-området, hver med design af en protokol, der forsøger at forenkle og standardisere, hvordan sikkerhedstokens reguleres, handles og administreres. Når man ser på Ethereum alene, inkluderer projekter, der har offentliggjort standarder til at tackle dette problem, Securitize, Harbor, Polymath og flere. Men i sidste ende, uden ændringer i hvordan disse protokoller i øjeblikket er designet, vil investorer og børser fortsat opleve betydelig friktion ved køb og salg af tokeniserede værdipapirer. Hvorfor? Interoperabilitet.

Interoperabilitet er afgørende

Interoperabilitet er en af de mest betydningsfulde fordele ved tokenisering. Det tillader et helt økosystem af kapitalmarkedsapplikationer og produkter at integrere med hinanden, fordi de deler fælles softwarestandarder. Men for at muliggøre interoperabilitet på applikations- og produktniveau, skal det starte på det laveste niveau med selve tokenerne. I sikkerhedstokenområdet er interoperabilitet essentiel for to nøgleparter: børser og investorer.

Som en børs vil du kunne autorisere investorer til at købe ethvert sikkerhedstoken, de er berettiget til – uanset hvilket firma der har oprettet tokenet. Det betyder, at du ikke behøver en skræddersyet integration med hvert sikkerhedstoken, men en simpel og generisk integration, der er ensartet på tværs af alle sikkerhedstokens. 

Som investor vil du have, at onboarding-processen skal være så enkel og friktionsfri som muligt. I øjeblikket, når en investor ønsker at købe aktier fra flere steder, skal de levere deres personlige oplysninger gang på gang i en proces kaldet Know Your Customer “KYC”. Blockchain har potentialet til at transformere denne proces ved at gemme disse oplysninger uforanderligt on-chain, hvor de så kan refereres af alle sikkerhedstokens. Det ville betyde, at man ikke behøver at gentage de samme personlige oplysninger hver gang man ønsker at købe et nyt token, men kun supplerende eller opdateret information ville være påkrævet efter den indledende registrering. Denne proces vil kun være mulig, hvis interoperabilitet mellem sikkerhedstokens er indbygget i de standarder, der styrer systemet.

Protokollerne

Tre af Ethereums førende sikkerhedstoken-protokoller blev offentliggjort af Securitize, Harbor og Polymath. Alle tre protokoller er bygget på Ethereums ERC-20 tokenstandard, som de derefter udvider for at håndhæve overholdelse i handlen med sikkerhedstokenet. Dette opnås ved at forespørge en sekundær kontrakt om lovligheden af hver handel på det tidspunkt, den finder sted.

Selvom de er navngivet forskelligt i protokollerne, er brugen af en sekundær kontrakt konsistent i alle tre, og opnår samme resultat: at forhindre ikke-overholdende handler. Denne sekundære ‘Regulator’-kontrakt holdes opdateret med brugernes KYC- og akkrediteringsinformation af off-chain tjenester, der er autoriseret til at gøre det – for eksempel en børs eller tokenets udsteder.

Selvom disse tre komponenter kan synes at være alt, hvad du behøver for at regulere et sikkerhedstoken (og i den simpleste form er de det), er det hvordan komponenterne er programmeret, der virkelig bestemmer interoperabilitet. Desværre mangler protokollerne interoperabilitet på to nøgleområder, som vil fortsætte med at forårsage friktion og bremse adoption af denne teknologi:

 

  1. Hvordan opdaterer autoriserede parter on-chain information om brugere?

 

Harbor

Harbor erklærer i deres whitepaper, at de vil være den eneste part, der er autoriseret til at opdatere brugerinformation on-chain i øjeblikket. Centraliseringen af denne rolle betyder, at børser ikke vil opdatere data, der refereres af Regulatoren. De vil derfor ikke kunne godkende nye modtagere af tokenet, hvilket forhindrer tokens i let at blive handlet uden for Harbor-platformen.

 

Securitize

Securitize har allerede implementeret et system, hvor flere parter kan autoriseres, så investorer kan registrere deres overholdelsesinformation flere steder og ikke behøver at gå gennem Securitize selv. On-chain data opdateres derefter direkte af den autoriserede part og kan ses af alle Securitize’s tokens. Desuden, for at forhindre at investorer skal levere information flere gange, har Securitize designet en API, der tillader autoriserede parter at få adgang til de private oplysninger om investorer, som er gemt off-chain, så de nemt kan afgøre, om en person er i overensstemmelse, eller om der er brug for yderligere information.

 

Polymath

Polymath har en indfødt digital utility token kaldet POLY, som er påkrævet gennem hele deres platform for at udføre forskellige opgaver, herunder at få en autoriseret part til at opdatere dine on-chain data. For at en person kan KYC’e sig selv, skal de først købe POLY tokens, hvilket ikke har et likvidt fiat-til-POLY marked. I stedet skal personen købe en anden kryptovaluta som Ethereums “ether” (ETH) med fiat, og derefter bytte denne til POLY. Tokenene kan så bruges på Polymaths KYC-markedsplads til at afgive et bud til en KYC-udbyder. Hvis KYC-udbyderen godkender buddet, betales de i POLY tokens for at udføre KYC-kontrollen for personen. Denne proces er tydeligt en betydelig onboarding-friktion for Polymath-platformen og gør processen mere kompleks end nødvendigt.

 

  1. Hvordan gemmes og tilgås denne information om brugere derefter on-chain?

 

Harbor

Ud fra whitepaperet og smart contracts på GitHub er det teknisk muligt for mange af Harbors tokens at dele én fælles Regulator-kontrakt og én fælles kilde til brugerdata, men dette er usandsynligt på grund af forskelle i regulering mellem forskellige tokens. Manglen på live Harbor-tokens på Ethereum har ikke afklaret, om det er deres intention, at dette skal være tilfældet, eller om hver token vil blive implementeret med sin egen Regulator.

 

Securitize

Securitize’s protokol er designet sådan, at deres Regulator-kontrakt forespørger en tredje smart contract, som gemmer brugerinformation. Dette gør det muligt for hver token at have unikke reguleringer kodet i deres egen individuelle Regulator, mens de stadig deler en fælles kilde til brugerdata i den tredje kontrakt, så når en bruger KYC’er for én Securitize-token, er deres information gemt klar til at købe fremtidige tokens

 

Polymath

Det er ikke eksplicit angivet i deres whitepaper, om Polymath har en central kilde til overholdelsesdata gemt on-chain, som hver Regulator så interagerer med, eller om tokens har deres egen lokale informationskilde. Men baseret på Polymaths eksempelkontrakter ser det ud til, at hver token bruger en lokal informationskilde, som ikke deles mellem forskellige tokens. Selvom dette kan have fordele, risikerer denne opsætning datadublering og inkonsistens.

Tag følgende eksempel: Bob har udtrykt interesse for to Polymath sikkerhedstokens, ABC og DEF, og er blevet godkendt som investor for hver af dem. Denne information sendes til Regulator-kontrakten for hver af tokenene. En måned senere prøver Bob at købe flere DEF-tokens, men det viser sig, at han ikke længere er akkrediteret. Denne information sendes til DEF’s Regulator for at opdatere Bobs investorstatus til ikke-akkrediteret. Nu er der på-chain modstridende information: ABC mener, at Bob er en verificeret investor, men DEF er uenig. Det er let at se, at en central informationskilde ville forhindre sådanne uoverensstemmelser.

Interoperabilitet af protokollerne

Som diskuteret tidligere er der to hovedparter involveret i udstedelse og udveksling af sikkerhedstokens, som interoperabilitet vil betyde meget for: børser og investorer. Begge disse parter ønsker en gnidningsfri oplevelse, når de interagerer med forskellige sikkerhedstokens. Så, hvis man bruger protokollerne som de er, lad os se på, hvordan børser og brugere vil blive påvirket.

Børser

Som en børs er integration af disse protokoller for overførsler let: alle tokenerne bruger ERC-20 tokenstandarden, hvilket giver et ensartet interface til at udføre overførsler, godkendelser og saldoforespørgsler. Men yderligere integration med overholdelsesaspektet af hver protokol bliver meget mere kompleks. Du vil huske, at det i øjeblikket ikke er muligt for en betroet part at blive autoriseret på Harbors protokol – de vil i stedet skulle dirigere brugere til Harbor for at KYC’e sig selv. For så at integrere med Securitize’s protokol, skal den betroede part autoriseres af Securitize, som så vil give dem adgang til investor KYC-data via off-chain API’en, og til at opdatere on-chain information gemt i on-chain datalageret.

At integrere med Polymaths protokol er sandsynligvis den mest komplekse. Den betroede part skal registrere sig som KYC-udbyder på Polymaths KYC-markedsplads og sætte sig op til at modtage bud i POLY tokens som betaling for at levere KYC-tjenester. Når de leverer KYC-tjenester til investorer, skal den betroede part derefter organisere en måde at sikre, at de duplikerede on-chain data, der er gemt om en bruger i hver sikkerheds Regulator④ ikke bliver inkonsistente.

Ikke kun har protokollerne forskellige interfaces, som den betroede part skal integrere med, men hver protokol har også en anden måde at levere fejlrapportering til børsen. Når man bygger et interface, er det vigtigt at kunne oversætte eventuelle fejl, der opstår, til noget forståeligt for brugerne. For eksempel, hvis en bruger ikke kan købe et token, kan det skyldes en lang række årsager: sikkerheden kan have en holdingperiode, der endnu ikke er opfyldt, eller kan begrænse det maksimale antal tilladte indehavere. For at kunne kommunikere disse beskeder til brugerne, skal børsen integrere med en anden metode til fejlrapportering for hver protokol.

Investorer 

De forskellige metoder, hvormed onboarding af investorer i øjeblikket er designet i protokollerne, betyder, at investorer sandsynligvis vil skulle levere personlige oplysninger mange gange til forskellige platforme og på forskellige måder. Dette skyldes, at Harbor ikke har autoriseret andre parter, og at Polymath kræver, at investorer byder på KYC-processer ved hjælp af POLY tokens. Friktionen forårsaget af håndhævelsen af disse overholdelsesmetoder kan gøre investorer uvillige eller ude af stand til at købe værdipapirer, de ellers ville købe.

Omfanget af denne protokolinducerede friktion på investorer kan delvist afhjælpes af den måde, børsene integrerer hver af protokollerne på. For eksempel, hvis en investor vælger at KYC’e på en børs for at købe et Polymath-token, kunne den børs, hvis den er autoriseret, vælge at opdatere Securitize’s datalagring på samme tid. Dette ville betyde, at investorens information er on-chain i tilfælde af, at den er nødvendig i fremtiden. Men hvis der ikke foretages ændringer i de nuværende protokoldesigns, vil processen med at registrere og købe værdipapirer forblive skræmmende.

Løsninger

Løsningen på dette problem behøver ikke at være kompleks. Faktisk er det muligt at introducere visse løsninger uden at ændre nogen tokens, der allerede er live på Ethereum. En ideel løsning, der medfører minimal friktion for både børser og investorer, og som forhindrer datainkonsekvenser forårsaget af mange forskellige kilder til overholdelsesdata, ville ligne Securitize’s centraliserede on-chain datalager; dog skal en sådan opsætning så vedtages på tværs af branchen.

Ved at have en central kilde til information on-chain fjernes risikoen for datainkonsekvenser, og investorer kan købe forskellige værdipapirer gennem kun én overholdelsesverifikation. Denne centrale kontrakt ville udføre verifikationen af, at overførslen var i overensstemmelse for alle sikkerhedstokens, og overførslen ville fortsætte eller rulle tilbage. Off-chain API’en, som er tilgængelig for alle autoriserede børser, betyder, at investorens overholdelsesinformation kan kommunikeres til børser og reducerer antallet af gange, investorer skal blive bedt om at levere data. Disse aspekter reducerer også massivt den mængde integrationsarbejde, som børser skal udføre.

Indførelsen af et nyt system som dette medfører naturligvis nogle komplikationer, og en række problemer skal stadig udlignes. For eksempel i designet af, hvordan hver børs bliver autoriseret: hvem træffer beslutningen om, at en børs skal være betroet? Der skal afsættes tid til at designe et system, der tillader konsensus at blive nået.

Konklusion

Tokenisering af værdipapirer er stadig et område, der er i en tidlig fase af udvikling og adoption, hvilket delvist skyldes kompleksiteten i regulatorisk overholdelse. Selvom offentliggørelsen af protokoller forenkler overholdelsen af mange af disse reguleringer ved at muliggøre, at de håndhæves i udførelsen af hver overførsel, er der stadig lang vej igen, før dette er en problemfri proces. Indtil vi har en aftale mellem protokollerne om, hvordan investorinformation gemmes og opdateres både on-chain og off-chain, vil der fortsat være betydelig friktion gennem registrerings- og investeringsprocesserne for alle involverede parter.

Alice Henshaw er en smart kontrakt ingeniør hos Fluidity. Fluidity er et New York-baseret selskab, der arbejder med DeFi, og er bedst kendt for at have skabt den decentraliserede udveksling Airswap. Tidligere arbejdede Alice hos ConsenSys, hvor hun designede og implementerede smart kontrakt systemer, der var ansvarlige for over $100M USD i transaktionsvolumen. Hun er uddannet fra Oxford University med en grad i datavidenskab.