The published design of Solana’s new institutional settlement program requires the full cash and asset legs of a trade to be available before it can execute the trade.
Its atomic transaction can prevent a buyer from paying without receiving the asset, but the program supplies neither the cash nor the financing needed to reach that point.
The Solana Foundation announced Solana DvP on Oct. 6 as an open-source standard for delivery-versus-payment settlement. The published design puts each side’s tokens into a separate escrow, then moves both agreed amounts together. It also explicitly excludes netting, the process of offsetting obligations before paying the remaining balance.
Institutions may benefit from a shorter wait for proceeds, while still needing to source the full amount for every trade they submit.
The announcement provides no measured capital-saving result or total-cost comparison.
Full funding and faster reuse
Under the published program limits, one trade record covers one exchange between two parties. Both legs must be token accounts on Solana, and partial fills are not allowed. A bank-account payment made on another rail falls outside this atomic exchange.
The settlement code at the documented source commit checks that each escrow balance is at least the amount agreed for that leg before transferring either agreed amount.
An underfunded side causes settlement to fail, and excess tokens are returned to the named party rather than increasing what the counterparty receives.
The economic responsibility remains with the participants and whoever finances them. A buyer must arrange the cash token, a seller must arrange the asset token, and a lender could finance either position through a separate arrangement, but that would leave the financing relationship outside the DvP program.
Funding itself uses an ordinary checked token transfer, according to the funding instructions. A custody or treasury system can supply the tokens without a special funding call.
Both balances must meet the agreed amounts at settlement, and the settlement authority must sign to exchange them.
That authority, a third address named in the trade, must sign the settlement instruction. The destinations are fixed when the record is created.
If a required transfer cannot complete, the settlement transaction reverses, and the earlier funding transfers are separate transactions.
Gross funding asks how much must be available for a trade, while funding duration asks how long it remains unavailable for other uses. Solana DvP’s bilateral design requires the full amounts at settlement but does not require institutions to keep those balances idle permanently.
A participant that receives usable cash or assets sooner may be able to put them into a subsequent trade sooner. That could reduce how long it needs external financing or how much liquidity it holds against a sequence of obligations.
The benefit depends on when funding is required and when the proceeds can actually be used.
Offsetting obligations can reduce the amount that needs to move in the first place. Solana DvP does not perform that calculation across trades. Institutions that need netting or credit must arrange those functions elsewhere before deciding how much to send to their escrows.
The Bank for International Settlements and the Committee on Payments and Market Infrastructures describe this tradeoff in their October 2024 tokenization report, on pages 12 and 13. Immediate gross settlement can require more liquidity than netting arrangements.
The report also identifies the countervailing benefit: quicker access to money and assets can reduce the opportunity cost of liquidity tied up during settlement.
For Solana DvP, the resulting total cost depends on the funding arrangement and the timing of usable proceeds.
A CryptoSlate analysis of tokenized deposits examined the same distinction between moving cash faster and reducing the amount needed. Its Oct. 2 Roughrider coverage described a bank-payment arrangement on Solana in which token transfers and burning sit alongside daily netting of bank-account movements.
That service combines token movement with a separate process for offsetting obligations.
What the atomic exchange protects
The protection is principal delivery risk within the token exchange: neither side hands over its agreed leg without the other leg also moving. The source repository describes that exchange, but the broader financial relationship still depends on the instruments being exchanged.
A cash token carries its issuer’s credit and redemption risks, and a regulated asset token can also retain controls that affect transfers. Freeze, pause, and permanent-delegate powers remain relevant while tokens sit in escrow.
The unwind instructions let either party reclaim its own leg while leaving the trade open, or reject the trade and refund both legs. The settlement authority can cancel it, and a separate recovery instruction handles deposits arriving after closure, subject to the token’s transfer rules.
These powers do not override an issuer that freezes an escrow or blocks transfers. A fully funded trade can still fail to complete, and refunds can depend on issuer cooperation. The authorized settlement signer must also be available.
Under the trade-creation terms, refunds and reclaims return to the named party’s token account even when a custodian supplied the deposit. Agreed settlement destinations can receive proceeds, but the refund route may differ from the funding route.
| Function | Program behavior | Remaining dependency |
|---|---|---|
| Exchange | Both agreed token legs move atomically | Full balances and a valid authority-signed settlement |
| Funding | Separate escrows hold the agreed amounts | Participants arrange tokens, financing and any netting |
| Recovery | Parties can reclaim or reject; authority can cancel | Issuer and token transfer controls still apply |
The documentation tells operators to recognize settlement when the transaction reaches Solana’s finalized commitment. Whether that also constitutes legally final settlement depends on the parties’ agreements and applicable regimes.
Deployment, audits and institutional use
The Foundation’s documentation lists an upgradeable program on mainnet-beta and devnet using observations dated Oct. 2. The mainnet table identifies an upgrade authority, an address with the power to change the deployed program. Institutions depend on its governance and settlement rules.
The client documentation points to a specific public source revision, with the latest revision dated Sept. 30 in the public version history.
Security reviewer Cantina’s May 21-28 audit covers an earlier repository and specific fixes. Its four medium findings are marked fixed, while three low-risk and six informational findings are acknowledged.
The Foundation says the program is ready for real funds, while inviting design partners and early participants ahead of production release.
JPMorgan’s role is limited too. The bank supplied securities-settlement-practice input, and the announcement expressly disclaims any role in the program’s design, development, operation, approval, endorsement, or guarantee.
For institutions, the useful next evidence would connect actual settlement use with the amount and duration of funding, the financing cost, and whether proceeds become spendable sooner.
Solana DvP offers a defined atomic exchange, and turning that exchange into a capital-saving service still depends on the cash, assets, and financing surrounding it.
