Solana Foundation offentliggjorde den 6. oktober en open source-standard for delivery-versus-payment-afregning, hvilket giver udviklere et program, der flytter en handels betalings- og aktivben enten sammen eller slet ikke. Designet kræver, at begge sider er fuldt finansieret før eksekvering — ingen delvise udfyldninger — og placerer hvert ben i sin egen escrow, indtil en tredjepart, afregningsmyndigheden, godkender. Det er et smalt, men bevidst stykke infrastruktur til tokeniserede markeder på Solana, og det udelader flere ting med vilje.
Sådan fungerer den to-benet udveksling faktisk
Når en handel oprettes, låser programmet det aftalte antal af hver sides tokens i separate escrow-konti. Begge ben skal være token-konti på Solana. En bankkontobetaling foretaget via en anden kanal kvalificerer ikke — den falder helt uden for den atomare udveksling. Afregningskoden, ved det dokumenterede source commit, kontrollerer, at hver escrow-saldo dækker det aftalte beløb for det pågældende ben, før den overfører noget. Hvis den ene side mangler midler, mislykkes det hele.
Finansiering er ikke noget eksotisk. Det er en almindelig checked token-overførsel, hvilket betyder, at et custody- eller treasury-system kan levere tokens uden at kalde en særlig finansieringsfunktion. Destinationer er fastlåst, når handelsposten oprettes. Hvis en påkrævet overførsel ikke kan gennemføres, vender afregningstransaktionen tilbage — men de tidligere finansieringsoverførsler er separate transaktioner, så de rulles ikke tilbage med den. Eventuelle overskydende tokens går tilbage til den navngivne part i stedet for at øge, hvad modparten modtager.
Netting er eksplicit udelukket
Programmet udelukker netting, praksissen med at udligne forpligtelser, før man betaler den resterende saldo. Det er en bevidst afvejning, og det er en, som Bank for International Settlements og Committee on Payments and Market Infrastructures påpegede i deres tokeniseringsrapport fra oktober 2024 på side 12 og 13: øjeblikkelig bruttoafregning kræver mere likviditet, mens netting-ordninger strækker den samme likviditet længere. Men BIS-rapporten peger også på den anden side af regnskabet — hurtigere adgang til penge og aktiver kan reducere alternativomkostningen ved kapital bundet under afregning.
En CryptoSlate-analyse af tokeniserede indlån foretog en beslægtet sondring mellem at flytte kontanter hurtigere og reducere mængden af kontanter, du har brug for. Dets Roughrider-dækning den 2. oktober beskrev en bankbetalingsordning på Solana, hvor token-overførsler og burning eksisterer side om side med daglig netting af bankkontobevægelser. Det er en anden form for problemet, og Solana DvP forsøger ikke at løse det.
Hvad atomar afregning dækker og ikke dækker
Programmet beskytter mod principal delivery-risiko inden for token-udvekslingen. Hvis du er køber, kan du ikke betale uden at modtage aktivet, og omvendt. Hvad det ikke gør, er at rydde op i det finansielle forhold omkring handlen. En långiver kunne finansiere begge positioner gennem en separat ordning, men det finansieringsforhold ligger uden for DvP-programmet — det økonomiske ansvar forbliver hos deltagerne og dem, der bakker dem op.
Instrumenterne selv bærer også bagage. Et cash-token bærer sin udsteders kredit- og indløsningsrisici. Et reguleret aktiv-token kan bevare kontroller — freeze, pause, permanente delegate-beføjelser — der påvirker overførsler, selv mens tokens ligger i escrow. Atomart eller ej, du holder stadig på en andens krav.
Hvor går det hen nu
Programmet er open source, med afregningslogikken fastgjort til et dokumenteret source commit for alle, der ønsker at revidere escrow-kontrollerne. Det interessante spørgsmål nu er, hvem der bygger oven på det. En custody-udbyder, et treasury-desk eller en udsteder af tokeniserede indlån kunne tilslutte finansiering uden ændringer i selve programmet, da finansieringsvejen blot er en standard checked transfer. Hvorvidt nogen af dem gør det — og hvorvidt bruttoafregning på dette detaljeringsniveau finder reel volumen på Solana — er den del, der endnu ikke er besvaret.
