Solana Foundation lanserer åpen kildekode‑program for atomisk DvP‑oppgjør

Solana Foundation kunngjorde den 6. oktober 2026 Solana DvP, et åpen kildekode‑escrow‑program som gir finansinstitusjoner et åpen kildekode‑API for atomisk leveranse‑mot‑betaling‑oppgjør på Solana. New York-datert kunngjøring sa at J.P. Morgan ga innspill til institusjonelle oppgjørspraksiser og krav under utviklingen av programmet.

Programmet, som er utgitt under MIT‑lisensen, er distribuert på Solanas mainnet‑beta og devnet med program‑ID dvp34bdbcEm4f4FCUjGV4mDAkDshaQR4LkK8fdcsyZq, ifølge Foundationens programdokumentasjon. Koden er blitt revidert av Cantina, og Foundationen oppgir at programmet har gjennomgått eksterne sikkerhetsrevisjoner og er klart for bruk med ekte penger.

Foundationen beskriver leveranse‑mot‑betaling som grunnsteinen i verdipapiroppgjør, en struktur som sikrer at både aktivum og kontanter beveger seg samtidig for å eliminere risikoen for å tape hovedstolen. Tradisjonelle markeder oppnår dette gjennom en fler‑dags kjede av clearinghus, depotinstitusjoner og forvaltere som binder kapital i én til to dager, opplyser kunngjøringen, mens institusjonelle handler som oppgjøres on‑chain hittil vanligvis har vært avhengige av skreddersydde smarte kontrakter. Solana DvP er ment å erstatte disse skreddersydde kontraktene med en standardisert bane som atomisk oppgjøres, gir isolert escrow og håndhever tidsfrister, og komprimerer oppgjøret til én atomisk transaksjon med endelighet på sekunder i stedet for dager, sier Foundationen.

«Atomisk oppgjør fjerner motpartsrisikoen som er iboende i tradisjonell finans. Solana DvP‑programmet gir institusjoner én åpen standard på tvers av Solana‑økosystemet, på offentlig infrastruktur, med endelighet på sekunder i stedet for dager», sa Catherine Gu, produktansvarlig for digitale eiendeler i Solana Foundation.

«En delt, åpen standard for atomisk leveranse‑mot‑betaling er akkurat den typen grunnleggende infrastruktur institusjonelle markedsdeltakere trenger for å operere i stor skala uten å introdusere oppgjørsrisiko og motparts‑eksponering. Vi er glade for å kunne bidra med vår oppgjørsekspertise», sa Rhodel D’souza, leder for markeder for digitale eiendeler i J.P. Morgan. En ansvarsfraskrivelse i kunngjøringen oppgir at bankens engasjement var begrenset til å gi innspill til verdipapiroppgjørspraksiser og ikke utgjorde design, utvikling, drift, godkjenning, sertifisering, garanti, støtte eller påliteliggjøring av Solana DvP eller dets ytelse på noen måte.

Hvordan en handel oppgjøres

Foundationens produktside beskriver flyten i tre trinn. Først registreres partene, eiendelene, beløpene, oppgjørsmyndigheten og utløpsdatoen on‑chain. Deretter finansierer hver part sin escrow med en standard token‑overføring fra sin eksisterende lommebok eller forvalter, uten at den motstående partens lommebok eller forvalter krever tilpasset integrasjon. Til slutt frigir myndigheten begge ben i én atomisk transaksjon, eller handelen rulles tilbake.

Dokumentasjonen definerer rollene i handelen. Parten for aktivums‑benet og part for kontant‑benet finansierer hver sin side av handelen. Oppgjørsmyndigheten er en tredje adresse som navngis ved opprettelse og er den eneste signaturen som kan gjennomføre oppgjøret; den kan ikke omdirigere inntektene, som er fastsatt ved opprettelse. En leietaker betaler SOL‑depositumet som holder handelskontoene åpne. Programmet er symmetrisk, bemerker dokumentasjonen, slik at to eiendeler eller to stablecoins oppgjøres på samme måte som en aktivum‑mot‑kontant‑utveksling.

Programmet eksponerer instruksjonene CreateDvp, ReclaimDvp, SettleDvp, CancelDvp, RejectDvp og RecoverDvp. Finansiering har ingen egen instruksjon; et ben regnes som finansiert så snart escrow‑kontoen inneholder minst det avtalte beløpet, innskutt via en standard TransferChecked‑token‑overføring. Siden enhver lommebok eller forvalter som kan sende den overføringen kan finansiere et ben uten et DvP‑spesifikt programkall, oppgir dokumentasjonen at eksisterende forvaltnings‑ og treasury‑oppsett kan delta direkte. Atomisiteten kommer fra at begge oppgjørs‑overføringer ligger i én Solana‑transaksjon, slik at enten begge trer i kraft eller ingen gjør det. Inntil oppgjør kan hver part hente tilbake sitt eget ben eller rulle tilbake handelen, oppgjørsmyndigheten kan avbryte, og en gjenopprettings‑instruksjon henter innskudd som ankommer etter at en handel er avsluttet.

Ifølge kunngjøringen kan enhver to motparter bruke programmet med hvilken som helst oppgjørsagent, enten det er en bank, en forvalter eller en børs.

Token‑støtte, grenser og tilgang

Solana DvP støtter SPL Token og Token‑2022, inkludert token‑utvidelser som Foundationen sier regulerte utstedere er avhengige av, slik som permanent delegat, pause‑bare token og overførings‑hooks. Dokumentasjonen er mer spesifikk: mynter med utvidelsene TransferFee, InterestBearing, ScaledUiAmount eller NonTransferable avvises både ved opprettelse og oppgjør, mens PermanentDelegate, Pausable, DefaultAccountState, en fryse‑myndighet og MintCloseAuthority godtas. ConfidentialTransfer‑mynter godtas med forbeholdet at beløpene på det benet forblir offentlige, og TransferHook støttes opp til 32 ekstra kontoer per ben. Siden tokenisert‑sikkerhets‑malen i Mosaic, Foundationens utstedelsesverktøy, alltid legger til Scaled UI Amount‑utvidelsen, godtas ikke mynter opprettet fra den malen som ben.

Dokumentasjonen beskriver også hva programmet ikke gjør. Det tilbyr ingen matching, prisoppdagelse eller ordrebok; ingen nettsettelse, kun bilaterale handler; ingen delvise fyllinger; ingen off‑ledger‑ledd; ingen kontroll av berettigelse, hviteliste eller KYC; og ingen automatisk oppgjør, fordi oppgjørsmyndigheten må signere. Det finnes ingen protokollavgift utover transaksjonsgebyrer og leie. Handlens utløp er begrenset til ett år fra opprettelse, og kun oppgjøret blokkeres etter utløp; tilbakekalling, avbestilling og avvisning forblir tilgjengelige, noe som kode‑depotet angir forhindrer at en utløpt, men finansiert handel blir stående med låste midler.

Programmet fjerner risikoen for å tape hovedstolen mellom de to partene, ifølge dokumentasjonen, men det fjerner ikke utstederens kreditt‑ eller innløsningsrisiko på noen av tokenene, muligheten for en mynts myndigheter til å handle med de sperrede tokenene, eller avhengigheten av at oppgjørsmyndigheten er tilgjengelig for å signere.

Hver handel registreres i en 458‑byte program‑eiet konto. Kildekoden, IDL‑filen, genererte TypeScript‑ og Rust‑klienter, samt tester, publiseres i solana-foundation/dvp GitHub‑depot under MIT‑lisensen; programmet er et no_std Pinocchio‑program med klienter generert fra IDL‑filen ved bruk av Codama. IDL‑filen er på versjon 0.1.0 per 2. oktober 2026, og programmet kan oppgraderes på begge klynger.

DvP er tilgjengelig via Markets‑modulen i Solana Developer Platform, som med sine tre moduler Issuance, Payments og Markets dekker opprettelse av eiendeler, pengeflyt og oppgjør, ifølge produktsiden. En devnet‑demo gjennomfører en full handel fra opprettelse til atomisk oppgjør. Stiftelsen uttalte at den planlegger å legge til personvern i programmet slik at handelsoppgjør kan gjøres private og konfidensielle, og den ønsker designpartnere og tidlige deltakere velkommen før produksjonsutgivelsen.