Behovet for interoperabilitet i sikkerhetstoken-protokoller – Thought Leaders

En kort historie om tokens

Det har gått mer enn 10 år siden Bitcoin først introduserte blokkjedeteknologi for verden. I løpet av den tiden har listen over potensielle bruksområder for distribuerte registre vokst raskt, fra digitale valutaer til forsyningskjeder til identitetsstyring. I kjernen har mange av disse bruksområdene en lignende struktur: de gjør det mulig for brukere å holde og overføre digitale eiendeler på en peer-to-peer-basis. Enkelt sagt kan vi nå handle og spore digitale eiendeler uten å trenge en sentral, pålitelig autoritet som styrer prosessen.

Denne utviklingen av området førte naturlig til oppfinnelsen av «tokens» – digitale eiendeler på en blokkjed som kan eies og overføres mellom individer. Tokens er delt inn i to hovedkategorier: de som representerer en innfødt digital eiendel, og de som representerer en underliggende virkelighetsbasert eiendel. Ved å utnytte dette nye paradigmet har hundretusener av forskjellige tokens allerede blitt opprettet på Ethereum alene, med en samlet markedsverdi på over 15 milliarder dollar på tidspunktet for skrivingen.

En av de mest lovende anvendelsene av tokens er representasjonen av virkelige verdipapirer på kjeden, noe som gjør det mulig å fraksjonere og overføre tradisjonelt illikvide eiendeler som kommersielle eiendommer peer-to-peer. Denne prosessen, kjent som «tokenisering», har fått betydelig oppmerksomhet fra både etablerte institusjoner og nye oppstartsbedrifter, på grunn av sitt potensial til å lindre mange eksisterende smertepunkter i kapitalmarkedene.

Regulatorisk etterlevelse

Selv om blokkjed kan gjøre det enklere å overføre eierskap i en teknisk forstand, er sikkerhetstoken fortsatt underlagt de samme lovene og reguleringene som tradisjonelle verdipapirer. Å sikre at sikkerhetstoken er i samsvar med regelverket er derfor kritisk for enhver potensiell tokenisering, og har vært en barriere for adopsjon så langt. Som vist i diagrammet nedenfor, blir regulatorisk usikkerhet bredt ansett som den største hindringen for blokkjed-adopsjon.

Tallrike prosjekter har dukket opp i blokkjedområdet, hver med en protokoll som forsøker å forenkle og standardisere hvordan sikkerhetstoken reguleres, handles og administreres. Når man ser kun på Ethereum, inkluderer prosjekter som har publisert standarder for å løse dette problemet Securitize, Harbor, Polymath og flere. Imidlertid vil investorer og børser fortsatt oppleve betydelig friksjon ved kjøp og salg av tokeniserte verdipapirer uten endringer i hvordan disse protokollene er designet i dag. Hvorfor er dette? Interoperabilitet.

Interoperabilitet er avgjørende

Interoperabilitet er en av de mest betydningsfulle fordelene med tokenisering. Den gjør det mulig for et helt økosystem av kapitalmarkedsapplikasjoner og -produkter å integrere med hverandre fordi de deler felles programvarestandarder. Men for å muliggjøre interoperabilitet på applikasjons- og produktnivå, må det begynne på det laveste nivået med selve tokenene. I sikkerhetstokenområdet er interoperabilitet essensiell for to nøkkelparter: børser og investorer.

Som en børs ønsker du å kunne autorisere investorer til å kjøpe ethvert sikkerhetstoken de er kvalifisert til å kjøpe – uansett hvilket selskap som opprettet tokenet. Dette betyr at du ikke trenger en skreddersydd integrasjon med hvert sikkerhetstoken, men en enkel og generisk integrasjon som er uniform på tvers av alle sikkerhetstoken.

Som investor ønsker du at onboarding-prosessen skal være så enkel og friksjonsfri som mulig. For øyeblikket, når en investor vil kjøpe aksjer fra flere steder, må de oppgi sin personlige informasjon gang på gang i en prosess kalt Know Your Customer (KYC). Blokkjed har potensialet til å transformere denne prosessen ved å lagre denne informasjonen uforanderlig på kjeden, hvor den deretter kan refereres av alle sikkerhetstoken. Dette ville bety at du ikke trenger å gjenta den samme personlige informasjonen hver gang du ønsker å kjøpe et nytt token, men kun tilleggs- eller oppdatert informasjon etter den første registreringen. Imidlertid vil dette kun være mulig hvis interoperabilitet mellom sikkerhetstoken er designet inn i standardene som styrer systemet.

Protokollene

Tre av Ethereums ledende sikkerhetstoken-protokoller ble publisert av Securitize, Harbor og Polymath. Alle disse tre protokollene er bygget på Ethereums ERC-20 token-standard, som de deretter utvider for å håndheve etterlevelse i handelen med sikkerhetstoken. Dette oppnås ved å spørre en sekundær kontrakt om lovligheten til hver handel på tidspunktet den skjer.

Selv om den kalles forskjellig i protokollene, er bruken av en sekundær kontrakt konsistent i alle tre, og oppnår samme resultat: å forhindre ikke‑kompatible handler. Denne andre ‘Regulator’-kontrakten holdes oppdatert med brukernes KYC‑ og akkrediteringsinformasjon av off‑chain‑tjenester som er autorisert til å gjøre det – for eksempel en børs eller token‑utstederen.

Selv om disse tre komponentene kan virke som alt du trenger for å regulere et sikkerhetstoken (og i sin enkleste form er de det), er det hvordan komponentene er programmert som virkelig bestemmer interoperabilitet. Dessverre mangler protokollene interoperabilitet i to nøkkelområder, noe som vil fortsette å skape friksjon og bremse adopsjonen av denne teknologien:

1. Hvordan oppdaterer autoriserte parter on‑chain‑informasjon om brukere?

Harbor

Harbor erklærer i sin hvitbok at de vil være den eneste parten som er autorisert til å oppdatere brukerinformasjon on‑chain for tiden. Sentraliseringen av denne rollen betyr at børser ikke vil oppdatere data som refereres av Regulator. De vil derfor ikke kunne godkjenne nye mottakere av tokenet, noe som hindrer tokenene i å bli lett handlet utenfor Harbor-plattformen.

Securitize

Securitize har allerede implementert et system der flere parter kan autoriseres, noe som betyr at investorer kan registrere sin etterlevelsesinformasjon på flere steder og ikke trenger å gå gjennom Securitize selv. On‑chain‑dataene oppdateres deretter direkte av den autoriserte parten, og kan sees av alle Securitize‑tokens. Videre, for å hindre at investorer må oppgi informasjon flere ganger, har Securitize designet et API som gjør det mulig for autoriserte parter å få tilgang til privat informasjon om investorer som er lagret off‑chain, slik at de enkelt kan avgjøre om en person er i samsvar eller om mer informasjon er nødvendig.

Polymath

Polymath har et eget digitalt nytte‑token kalt POLY som kreves gjennom hele plattformen for å utføre ulike oppgaver, inkludert å få en autorisert part til å oppdatere dine on‑chain‑data. For at en enkeltperson skal kunne KYC‑seg selv, må de først kjøpe POLY‑tokens, som ikke har et likvidt fiat‑til‑POLY‑marked. I stedet må personen kjøpe en annen kryptovaluta som Ethereums «ether» (ETH) med fiat, og deretter bytte dette til POLY. Tokenene kan deretter brukes på Polymaths KYC‑markedsplass for å legge inn et bud til en KYC‑leverandør. Hvis KYC‑leverandøren godkjenner tilbudet, betales de i POLY‑tokens for å utføre KYC‑sjekken for den enkelte. Denne prosessen er tydelig en betydelig onboarding‑friksjon for Polymath‑plattformen, og gjør prosessen mer kompleks enn nødvendig.

2. Hvordan lagres og aksesseres denne informasjonen om brukere on‑chain?

Harbor

Ved å se på hvitboken og smarte kontrakter på GitHub, er det teknisk mulig for mange av Harbors token å dele én felles Regulator‑kontrakt, og dele én felles kilde til brukerdata, men dette er usannsynlig på grunn av regulatoriske forskjeller mellom ulike token. Mangelen på levende Harbors token på Ethereum har ikke avklart om dette er deres intensjon, eller om hver token vil bli distribuert med sin egen Regulator.

Securitize

Securitize‑protokollen er designet slik at deres Regulator‑kontrakt spør en tredje smart kontrakt som lagrer brukerinformasjon. Dette gjør at hver token kan ha unike reguleringer kodet i sin egen individuelle Regulator, samtidig som de deler en felles kilde til brukerdata i den tredje kontrakten, noe som betyr at når en bruker KYC‑er for en Securitize‑token, blir informasjonen lagret klar for at de skal kunne kjøpe fremtidige token.

Polymath

Det er ikke eksplisitt angitt i deres hvitbok om Polymath har en sentral kilde til etterlevelsesdata lagret on‑chain som hver Regulator deretter interagerer med, eller om tokenene har sin egen lokale informasjonskilde. Basert på Polymaths eksempelkontrakter ser det imidlertid ut til at hver token bruker en lokal informasjonskilde, som ikke deles mellom ulike token. Selv om dette kan ha fordeler, medfører oppsettet risiko for datadublisering og inkonsistens.

Ta følgende eksempel: Bob har uttrykt interesse for to Polymath‑sikkerhetstoken, ABC og DEF, og har blitt godkjent som investor for hver av dem. Denne informasjonen sendes til Regulator‑kontrakten for hver av tokenene. En måned senere prøver Bob å kjøpe flere DEF‑token, men det viser seg at han ikke lenger er akkreditert. Denne informasjonen sendes til DEFs Regulator for å oppdatere Bobs investorstatus til å være ikke‑akkreditert. Nå er det på kjeden motstridende informasjon: ABC tror at Bob er en verifisert investor, men DEF er uenig. Det er lett å se at en sentral informasjonskilde ville forhindre slike avvik.

Interoperabilitet av protokollene

Som diskutert tidligere, er det to hovedparter involvert i utstedelse og handel med sikkerhetstoken som interoperabilitet vil være svært viktig for: børser og investorer. Begge disse partene ønsker en smidig opplevelse når de interagerer med ulike sikkerhetstoken. Så, hvis vi bruker protokollene som de er, la oss se på hvordan børser og brukere vil bli påvirket.

Exchanges

Som en børs er integrering av disse protokollene for overføringsformål enkelt: alle tokenene bruker ERC-20‑standarden, som gir et ensartet grensesnitt for å utføre overføringer, godkjenninger og saldo‑sjekker. Videre integrering med etterlevelsesaspektet i hver protokoll blir imidlertid langt mer kompleks. Du vil huske at det for øyeblikket ikke er mulig for en betrodd part å bli autorisert på Harbors protokoll – de må i stedet dirigere brukere til Harbor for å KYC‑e seg selv. For å integrere med Securitize‑protokollen må den betrodde parten bli autorisert av Securitize, som da vil tillate dem å få tilgang til investor‑KYC‑data via off‑chain‑API‑et, og oppdatere on‑chain‑informasjon lagret i on‑chain‑databutikken.

Å integrere med Polymaths protokoll er sannsynligvis den mest komplekse. Den betrodde parten må registrere seg som KYC‑leverandør på Polymaths KYC‑markedsplass og sette seg opp til å motta bud i POLY‑tokens som betaling for å levere KYC‑tjenester. Når de leverer KYC‑tjenester til investorer, må den betrodde parten deretter organisere en måte å sikre at den dupliserte on‑chain‑dataen som lagres om en bruker i hver sikkerhets Regulator ikke blir inkonsistent.

Ikke bare har protokollene forskjellige grensesnitt som den betrodde parten må integrere med, hver protokoll har også en annen måte å levere feilrapportering til børsen på. Når man bygger et grensesnitt er det viktig å kunne oversette eventuelle feil som oppstår til noe som er forståelig for brukerne. For eksempel, hvis en bruker ikke kan kjøpe et token, kan dette skyldes en rekke årsaker: verdipapiret kan ha en holding‑periode som ennå ikke er oppfylt, eller kan begrense maksimalt antall tillatte innehavere. For å kunne kommunisere disse meldingene til brukerne, må børsen integrere med en annen metode for feilrapportering for hver protokoll.

Investors 

De ulike metodene som onboarding av investorer er designet med i protokollene betyr at investorer sannsynligvis må oppgi personlig informasjon mange ganger til ulike plattformer og på forskjellige måter. Dette skyldes at Harbor ikke har autorisert andre parter, og at Polymath krever at investorer byr på KYC‑prosesser ved hjelp av POLY‑tokens. Friksjonen som påløper ved håndheving av disse etterlevelsesmetodene kan gjøre investorer uvillige eller ute av stand til å kjøpe verdipapirer de ellers ville ha kjøpt.

Omfanget av denne protokoll‑induserte friksjonen for investorer kan delvis reduseres av måten børsene integrerer hver av protokollene på. For eksempel, hvis en investor velger å KYC‑e på en børs for å kjøpe en Polymath‑token, kan den børsen, dersom den er autorisert, velge å oppdatere Securitize‑databehandlingen samtidig. Dette vil bety at investorens informasjon er on‑chain i tilfelle den trengs i fremtiden. Men dersom ingen endringer gjøres i de nåværende protokoll‑designene, vil prosessen med å registrere og kjøpe verdipapirer forbli skremmende.

Solutions

Løsningen på dette problemet trenger ikke å være kompleks. Faktisk er det mulig å introdusere visse løsninger uten å endre noen token som allerede er i drift på Ethereum. En ideell løsning som gir minimal friksjon for både børser og investorer, og som forhindrer datainkonsistens forårsaket av mange ulike kilder til etterlevelsesdata, ville ligne Securitize sin sentraliserte on‑chain‑datastore; men en slik oppsett må da tas i bruk på tvers av hele bransjen.

Ved å ha en sentral informasjonskilde on‑chain fjernes risikoen for datainkonsistens, og investorer kan kjøpe ulike verdipapirer gjennom kun én etterlevelsesverifisering. Denne sentrale kontrakten vil utføre verifiseringen av at overføringen er i samsvar for alle sikkerhetstoken, og overføringen vil fortsette eller bli reversert. Off‑chain‑API‑et som er tilgjengelig for alle autoriserte børser gjør at investor‑etterlevelsesinformasjon kan kommuniseres til børsene og reduserer antall ganger investorer må bli bedt om å oppgi data. Disse aspektene reduserer også kraftig mengden integrasjonsarbeid som kreves av børser.

Innføringen av et slikt nytt system medfører tydeligvis noen komplikasjoner, og en rekke problemer må fortsatt løses. For eksempel i utformingen av hvordan hver børs blir autorisert: hvem tar beslutningen om at en børs skal være pålitelig? Det må tas tid til å designe et system som gjør det mulig å oppnå konsensus.

Conclusion

Tokenisering av verdipapirer er fortsatt et område som er i tidlig utviklings- og adopsjonsfase, delvis på grunn av kompleksiteten i regulatorisk etterlevelse. Selv om publiseringen av protokoller forenkler etterlevelsen av mange av disse reguleringene ved å muliggjøre at de håndheves i utførelsen av hver overføring, er det fortsatt langt til dette blir en sømløs prosess. Inntil vi har en avtale mellom protokollene om hvordan investorinformasjon lagres og oppdateres både on‑chain og off‑chain, vil det fortsatt være betydelig friksjon gjennom registrerings‑ og investeringsprosessen for alle involverte parter.