✨ AI-sammendrag
- Blogginnlegget diskuterer den økende interessen for Real World Assets (RWA) i kryptovalutasektoren.
- Forfatteren tydeliggjør forskjellen mellom tokeniserte RWA-er og RWA Perpetuals, to fundamentalt forskjellige produkter som ofte forveksles med varianter av det samme tilbudet.
- Tokeniserte RWA-er er blokkjedeutstedte tokens som representerer eierrettigheter til reelle eiendeler, mens RWA Perpetuals er syntetiske instrumenter som tilbyr priseksponering mot underliggende eiendeler uten å endre eierskap.
- Innlegget understreker viktigheten av at utviklingsteam for børser forstår forskjellene mellom de to, ettersom de imøtekommer ulike brukerbehov og risikoprofiler.
- Forfatteren bryter videre ned de arkitektoniske kravene for å bygge børser for begge RWA-produktene og fremhever Oracle-utfordringene man står overfor i utviklingen av RWA Perpetuals-børser.
RWA, i likhet med AI, er noe alle bygger, men bare noen få er faktisk klare over hva de bygger.
Den virkelige verden av aktivafortellinger har blitt et av de mest overfylte områdene innen kryptoinfrastruktur. Kryptovalutabørser haster med å tilby RWA-produkter, og investorer ber om RWA-eksponering. Men de vanlige fellesbegrepene visker ut linjene mellom tokeniserte RWA-er og RWA-perpetualer, som fundamentalt sett er
- forskjellige produkter
- bygget på en annen infrastruktur
- betjener brukere med helt forskjellige behov og risikoprofiler
Antagelsen om at disse to kan behandles som en variant av det samme tilbudet er der de fleste utviklingsteam for kryptobørser gjør feil. Arkitekturbeslutninger, brukeranskaffelsesstrategi, orakeldesign og samsvarsholdning varierer betydelig for de to. Børsutviklingsteam som bygger uten en fokusert strategi og klar visjon, vil sannsynligvis ikke utføre noen av delene effektivt.
Dette innlegget beskriver infrastrukturrealitetene, kostnads-nytte-bildet, Oracle-utfordringer osv. for produktledere som bestemmer hvilken vei de skal ta for å utnytte den økende etterspørselen etter RWA.
Hva tokeniserte RWA-er og RWA-perps egentlig er
Tokeniserte RWA-er er digitale tokens utstedt på en blokkjede som representerer eierskap og kontraktsmessige rettigheter til obligasjoner, fondsandeler, eiendom eller en råvare. Disse blokkjedebaserte aktivaene i den virkelige verden kan administreres og handles i en digital hovedbok. Produktet er avkastningsgenerert og beregnet på brukere som ønsker regulert eksponering mot aktivaet på institusjonell nivå og blokkjedeaktivert oppgjør.
RWA evigvarende obligasjoner, er derimot syntetiske instrumenter som tilbyr eksponering mot prisen på det underliggende aktivumet uten å endre eierskapet. Traderen får retningsbestemt, gearet eksponering mot prisen på gull, olje, en aksje, en indeks eller et valutapar, uten å eie aktivumet. Det er ingen utløpsdato, ingen leveringsmekanisme og ingen KYC nødvendig for tillatelsesløse plattformer for evigvarende futureshandel. Produktet er bygget for spekulasjon, sikring og 24/7-tilgang.
Før lansering av noen av RWA-produktene på en kryptobørsprogramvare, må utviklingsteam og kryptoentreprenører forstå forskjellen mellom de to.
| Dimensjon | Tokeniserte RWA-er | RWA Perpetuals |
|---|---|---|
| Eiendelseierskap | Direkte eller indirekte krav på det underliggende aktivumet | Ingen eierskap, kun eksponering for syntetisk pris |
| Oppgjørsmekanisme | Oppgjør av reelt eiendeler på kjeden; ofte T+0 vs. tradisjonell T+2 | Kontinuerlig markedsverdi; ingen fysisk eller kontant oppgjør av underliggende |
| Forvaringsmodell | Depotmottakeren holder det underliggende aktivumet; tokenet representerer et krav | Selvforvaring; sikkerhet holdt i en smartkontrakt |
| Tilgangsmodell | Tillatelse; KYC/AML kreves; ofte jurisdiksjonsbegrenset | Tillatelsesløs; lommeboktilkobling er tilstrekkelig for de fleste evigvarende DEX-plattformer |
| Reguleringsprofil | Høy verdipapirlovgivning, forvaringsregulering og overføringsbegrensninger | Lav til moderat; varierer etter jurisdiksjon; avledede regler kan gjelde |
| Utnytt tilgjengelighet | Vanligvis ingen; kun brøkdelt eierskap for lang tid | Kjernefunksjon; 2x til 50x+ avhengig av plattform |
| Markedstimer | Begrenset av markedets åpningstider for underliggende aktiva for prising | Døgnet rundt; kjerneverdiforslag, muliggjort av Oracle-design |
| Brukerens hensikt | Avkastning, diversifisering, institusjonell porteføljeallokering | Retningsbestemt handel, makrosikring, spekulasjon med gearing |
| Infrastrukturkompleksitet | Samsvarslag, integrering av forvaring, standarder for smarte kontrakter, juridiske innpakninger | Oracle-design, likvidasjonsmotor, finansieringsratemekanisme, oppetid døgnet rundt |
| Typisk brukerprofil | Kapitalforvaltere, hedgefond, institusjonelle allokatorer og akkrediterte investorer | Detaljhandlere, kryptospekulanter og ikke-kryptobrukere som søker makroøkonomisk eksponering |
| Inntektsmodell for børs | Forvaltningsgebyrer, spread, utstedelsesgebyrer, inntekter basert på forvaltningskapital | Handelsgebyrer, innhenting av finansieringsrente og likvidasjonsgebyrer |
| Tid til inntekt | Tregere; oppbygging av samsvar, institusjonelle salgssykluser | Raskere; onboarding i detaljhandelen, volumdrevet, umiddelbar gebyrgenerering |
RWA perpetuals og tokenized RWAs kan handles på en kryptovalutabørs, men utviklerne av kryptobørsen må være klar over ICP-ene de bygger for.
To produkter, to helt forskjellige mål-ICP-er
Ocuco institusjonell bruker som har tilgang til tokeniserte RWA-er kommer fra en verden av mellomledd og compliance-avdelinger som investerer i henhold til sine kvartalsvise rapporteringssykluser. De forstår depotrisiko, ønsker avkastning og vil akseptere friksjon som oppstår fra KYC-køer, jurisdiksjonskontroller, akkrediteringsverifisering osv., hvis produktet oppfyller kriteriene deres. Brukeren er primært her for raskere oppgjør, programmerbar compliance og brøkdelt tilgang til tidligere illikvide eiendeler.
Ocuco detaljhandelsbruker, tiltrukket av RWA-forbrytere, har en helt annen kalkulus. De har kanskje aldri hatt en tradisjonell meglerkonto, men er godt kjent med selvforvaring og likvidasjonsmekanismer i kryptohandel. De venter ikke på at tradisjonelle markeder skal åpne og vil kreve umiddelbar eksponering mot makroaktiva som gull eller olje under et geopolitisk sjokk eller forsyningsforstyrrelse. Tillatelsesfri tilgang og tilgjengelighet døgnet rundt er de viktigste funksjonene for disse brukerne.
De kritiske feilene som utviklingsteam for kryptobørser gjør her inkluderer:
- Bygge en enhetlig onboarding-flyt
- En delt likviditetspool
- En enkelt samsvarsposisjon
For både RWA-produkter og brukertyper. Dette rokker institusjonelle brukeres tillit til den tokeniserte RWA-handelsplattformen, siden de synes den er underutviklet. Detaljhandelsbrukeren står også overfor strenge samsvarsforpliktelser under onboarding-prosessen og finner derfor RWA-fordelene utilgjengelige.
Kryptobørsprogramvaren ender derfor opp med to målgrupper, som begge delvis betjenes og aldri beholdes.
De arkitektoniske kravene bak bygging av RWA Perpetual og Tokenized RWA-børser
Tokenisert RWA-handelsinfrastruktur
Utvikling av tokeniserte RWA-børser krever at man setter sammen en compliance-stack før man skriver en eneste linje med smartkontrakt. Programvareutviklingsteam for kryptobørser trenger
- en integrering av depotet med en regulert depotmottaker
- en KYC/AML-leverandør
- en juridisk innpakning som kobler tokenet til RWA-eierskapskravet
- smarte kontrakter som håndhever overføringsbegrensninger på tvers av jurisdiksjoner
Standarder som ERC-1400 eller ERC-3643 brukes ofte for tillatt token-oppførsel.
Bortsett fra kravene ovenfor, er den løpende vedlikeholdsbyrden for utvikling av RWA-børser ganske betydelig. Programvare for kryptovalutabørser som tokeniserer RWAer kan ikke overse regulatorisk rapportering, hvitlistehåndtering, jurisdiksjonsoppdateringer og konstant koordinering med forvaltere.
RWA evigvarende handelsinfrastruktur
Utvikling av RWA-perpetual exchange krever en annen stabel med følgende kjernekomponenter:
- Et orakelsystem i kjernen som priser tradisjonelle eiendeler døgnet rundt.
- en likvidasjonsmotor som virker på foreldede eller gap-priser uten å ødelegge brukersikkerhet
- en finansieringsrentemekanisme som holder den evigvarende prisen på den risikovektede aktivert (RWA) forankret til det underliggende aktivumet
- et enklere smart kontraktslag fra et samsvarsperspektiv, men komplekst når det gjelder sanntidsnøyaktighet og oppetidsgarantier.
I utvikling av evigvarende utveksling av RWA er orakelproblemet det vanskeligste å avkode.
Hva er de Oracle-relaterte utfordringene for utvikling av RWA Perpetuals Exchange?
1. Prisforskjeller etter arbeidstid
Tradisjonelle prisfeeder antar at markedene er åpne når du trenger en pris. For kryptoaktiva er dette trivielt oppfylt siden markedene aldri stenger. For tradisjonelle aktiva som gull, råolje, aksjeindekser og valutapar, hvis markeder opererer 08:00-21:00 UTC mandag til fredag, brytes antagelsen umiddelbart siden det ikke finnes noen live regulert referansepris. Oracle må konstruere en forsvarlig merkepris ved å aggregere tilgjengelige data, inkludert OTC-kurser, futurespremier, relaterte instrumentspreader osv., i slike tider, ellers kollapser hele produktet. En dårlig implementering her skaper arbitrasjemuligheter mot likviditetsleverandørene dine og eksponerer brukere for urettferdige likvidasjoner.
2. Futures Roll Management
Vare evigvarende som råolje eller Brent-referansefutureskontrakter som utløper. Når frontmånedskontrakten går videre til den neste, hopper referanseprisen diskontinuerlig. Orakelet må kunne håndtere rulleringstiming, basisjusteringer og overgangen mellom kontraktsmåneder uten å skape en likvidasjonskaskade eller en finansieringsrenteøkning.
3. Risiko for åpningsgap
Tradisjonelle markeder åpner med hull når viktige nyheter har kommet over natten. En gullhandel på 2400 dollar på kryptobørsprogramvaren din ved markedets slutt kan åpne på 2,450 dollar om morgenen. Posisjoner som var solvente ved midnatt kan endre seg drastisk klokken 9:31 om morgenen. Likvidasjonsmotoren må håndtere dette scenariet uten å utslette brukere som hadde tilstrekkelig margin for normale markedsforhold.
Hvordan håndterer ledende RWA-plattformer Oracle-relaterte utfordringer med RWA Perps-tilbud?
1. Ostium+ Stork-nettverket
Bruker et tilpasset orakel som aggregerer markedsdata og bud-/salgsspreader og publiserer prisene på kjeden kun ved handelsutførelse. Dette minimerer gassforbruk og reduserer angrepsflaten for orakelmanipulasjon. Likvidasjoner og limitordre håndteres av et automatisert utførelseslag kjent som Gelato-funksjoner. Brukerne, i denne prismekanismen, kan modellere sin likvidasjonsrisiko med rimelig sikkerhet, selv i perioder etter stengetid.
2. Trade.xyz-Dobbel modus
Denne mekanismen opererer med to orakelmoduser. En av dem er for åpne markeder som bruker live regulerte feeder, mens den andre er for lukkede markeder som bruker en konstruert referansepris. Begge modellene mates inn i beregningen av finansieringsrenten og markprisen, basert på hva som er kontinuerlig tilgjengelig. Dette sikrer at plattformen aldri går inn i en tilstand med redusert funksjonalitet. Avveiningen er at orakelet i lukkede markeder introduserer mer basisrisiko og krever at sofistikerte brukere forstår prisregimet de opererer i.
Hvis du bygger en RWA perpetual kryptobørs for detaljhandlere, trenger du ikke å bygge Oracle Infra fra bunnen av. Du trenger bare å forstå det godt nok til å
- Evaluer hva du integrerer i programvaren din for kryptovalutaveksling
- Forhandle SLA-er med Oracle-leverandører
- Ta et informert valg mellom kapitalsikkerhet og kontinuerlig tilgjengelighet
Den avgjørelsen former hele produktarkitekturen og risikorapporteringen din. Orakelutfordringene vil imidlertid forsvinne etter hvert som NYSE og ICE går mot døgnkontinuerlig regulert markedsutførelse.
Tokeniserte RWA-er vs. RWA Perpetuals: Kostnads- og nytteanalyse for utbyggere
| Kategori | Tokeniserte RWA-er | RWA Perpetuals |
|---|---|---|
| Byggekostnader: | ||
| Infrastruktur | Regulert depotmottakerintegrasjon og juridisk strukturering | Oracle-integrasjon og konfigurasjon av tilpassede feeder |
| Samsvar | KYC/AML-leverandør og samsvarsinfrastruktur | Smarte kontraktsrevisjoner siden perps har en høyere utnyttelsesflate |
| Smarte kontrakter | Tillatte tokenstandarder (ERC-1400, ERC-3643); minimum to revisjonsrunder | Utvikling av likvidasjonsmotor og stresstesting; design av finansieringsrentemekanisme |
| Lovlig | Juridiske vurderinger per målmarked | Regulatorisk rådgiver for derivatklassifisering per jurisdiksjon |
| Driftsinfrastruktur | Verktøy for hvitelister og overføringsbegrensninger | Døgnåpen oppetidsinfrastruktur, varsling og oppsett av tekniske tjenester på vakt |
| Løpende kostnader: | ||
| Samsvarsoperasjoner | KYC/AML-fornyelse, overvåking og regulatoriske rapporteringssykluser | Kontinuerlig parameterjustering – finansieringsrater, marginnivåer, forsikringsfond |
| Tredjepartsgebyrer | Depotmottakergebyrer, vanligvis AUM-baserte og tilbakevendende | SLA-er for Oracle-feed og vedlikeholdskontrakter for leverandører |
| Markedsoperasjoner | Vedlikehold av hvitelister og overføringsbegrensninger etter hvert som brukerbasen vokser | Market maker-insentivprogrammer og risikostyring etter arbeidstid |
| Lovlig | Løpende juridisk rådgivning etter hvert som regelverket utvikler seg på tvers av jurisdiksjoner | Utvikling av derivatregulering, overvåking og tilpasning |
| Fordeler : | ||
| Inntektsprofil | Høyere ACV per institusjonell klient; forvaltningsgebyrer og spreadinntekter | Høyt handelsvolum med umiddelbare gebyr- og finansieringsinntekter |
| Brukerskala | Mindre adresserbart marked – tusenvis av kvalifiserte institusjonelle brukere | Detaljhandelsskala; millioner av potensielle brukere globalt, inkludert ikke-kryptobaserte brukere |
| Inntektsstabilitet | Lavere volatilitet; avkastningsprodukter er trege, avgifter basert på forvaltningskapital er forutsigbare | Volumdrevet; høy oppside under makrohendelser, variabel i rolige perioder |
| Strategisk verdi | Regulatorisk velvilje, lisensforsvarlighet og tilgang til institusjonell distribusjon | Førstegangsvinduet før regulerte markeder døgnet rundt fra NYSE/ICE tetter gapet |
| Tid til inntekt | Saktere siden institusjonelle salgssykluser er lange; 12–18 måneder er realistisk | Raskere, ettersom onboarding i detaljhandelen skjer umiddelbart; gebyrinntektene starter med den første handelen |
Valg av RWA-strategi: En sjekkliste for utviklingsteam for kryptobørser
Før du forplikter deg til å utvikle programvaren for kryptobørsen din, bør du jobbe deg gjennom disse fire spørsmålene:
- Hvem bygger du primært for?
Som nevnt tidligere:
- Hvis målgruppen din er institusjonelle allokatorer og kapitalforvaltere, er tokeniserte risikovektede aktiver i samsvar med deres samsvarsforventninger og avkastningskrav.
- Hvis målet ditt er detaljhandlere og kryptospekulanter, tilbyr RWA-gjerningsmenn den gearingen og døgnåpen tilgangen de leter etter.
Hvis svaret er «begge», må du definere primærbrukeren først, og sekundærproduktet kan følge når kjerneprogramvaren for kryptobørs er bygget godt for primærbrukerne.
- Hva er din etterlevelsesappetitt og jurisdiksjon?
Tokeniserte RWA-er krever vedvarende juridisk investering i alle jurisdiksjoner du betjener. I så fall:
- Har du intern advokat eller en etablert juridisk partner?
- Har dere klarhet i deres regulatoriske status i målmarkedene?
Hvis svaret er nei, kan samsvarskostnadene for tokeniserte RWA-er forsinke lanseringen av kryptovalutabørsprogramvaren din med 12–18 måneder.
RWA-brukere på tillatelsesløs infrastruktur har lavere regulatorisk friksjon, men det regulatoriske landskapet rundt RWA-brukere er i utvikling. Så alle må bygge med tanke på regulatoriske valgmuligheter og endringer.
- Skal man bygge eller integrere Oracle, Liquidation og Custody?
For programvareutvikling for utveksling av RWA-personer:
- Har dere en Oracle-leverandør som er evaluert og kontraktfestet?
- Har du stresstestet likvidasjonsmotoren din mot åpningsgap-scenarioer og futures-rull-hendelser?
For utvikling av tokeniserte RWA-børser:
- Har du bekreftet en depotmottaker og valgt en smart kontraktsstandard?
Å bygge fra bunnen av i begge kategoriene legger til 6–12 måneder til utvikling av kryptobørser tidslinje. Integrering av Oracle krever grundig evaluering av hva du integrerer, siden ikke alle leverandører håndterer priser etter arbeidstid med like stor kompetanse.
- Bygger du for å utfylle TradFi, eller tilbyr du erstatning uten tillatelse først?
Tokeniserte RWA-er er mest sammenhengende som et supplement til tradisjonell finans, siden de tilbyr raskere oppgjør, programmerbar samsvar og brøkdelt tilgang, noe som er et flott tillegg til tradFi-tjenester.
RWA-perper er mest sammenhengende som en erstatning for brukere som er ekskludert fra eller underbetjent av tradisjonelle derivatmarkeder.
Å vite hvilken tese du følger for utviklingen av kryptobørsen din endrer markedsstrategien din, partnerskapsstrategien din og budskapet ditt til brukere og investorer.
Din RWA-strategi er til syvende og sist en brukerstrategi
Perpifisering av reelle eiendeler er ikke en nisjetrend. HIP-3-markedene har allerede oversteget 10 milliarder dollar i kumulativt volum per desember 2025. Innen 2026 hadde de kumulative volumene nådd $ 25 milliarder, med en brukerbase som nådde 1.4 millioner aktive brukere, og en åpen interesse som nådde ATH-er på 1.2 milliarder dollar i mars 2026. Infrastrukturen modnes, etterspørselen skyter i været, og brukerbasen utvides utover web3-nerder.
Rett før NYSE og ICE bygger sine døgnåpne markeder, har RWA-børsen din fortsatt en sjanse til å gripe et konkurransefortrinn. Med en differensiert, men målrettet RWA-performer eller en tokenisert RWA-børsutviklingstilnærming, kan du vinne.
Hos Antier jobber teamet vårt med utviklere av kryptobørser med Oracle-evaluering, arkitekturdesign og markedsstrategi.
Ta kontakt i dag!
