The Solana Foundation announced its open-source DvP escrow program on October 6, 2026. Its atomic settlement moves the two agreed legs together or neither, but creating a trade and funding escrow are separate steps. Before sending tokens, verify the stored terms, the named settlement authority and the return destination. The existence of a trade record does not establish that you agreed to it.
Where the atomic step starts
The launch announcement presents a reusable delivery-versus-payment program for institutional settlement. Its statement about J.P. Morgan’s input should not be read as a bank operating or guaranteeing the program; the announcement explicitly limits that involvement. This article does not independently certify a deployment or the assets used in a trade.
The current program documentation separates the two parties from a third named settlement authority. Parties fund their legs, while that authority signs settlement. Atomicity applies to the exchange within the settlement transaction. It does not mean that a successful earlier funding transfer has already delivered the counterparty’s asset.
| Stage | What it establishes | What to check next |
|---|---|---|
| Create | A program trade record exists | Whether its stored terms match the actual agreement |
| Fund | Tokens reached the relevant escrow | Correct mint, amount, parties and still-applicable trade terms |
| Settle | Both agreed legs execute together if settlement succeeds | The recorded result and intended settlement recipients |
| Return or unwind | Funds move under the applicable return instruction | Who owns that leg and where the returned tokens actually go |
A record address is not a substitute for the terms
The funding guide warns that record creation is permissionless and that escrow addresses do not encode all trade terms. Receiving an apparently valid record or an escrow address from another party therefore does not establish the amounts, timing and destinations you intended. Read the stored fields and compare them with the agreement before funding.
A fictional treasury operator can make this concrete: two screens may show the same token pair while naming different settlement destinations. Checking only the pair would miss the difference. A useful review names both parties, both assets, quantities, relevant times, settlement authority and settlement destinations, rather than treating an attractive trade summary as the authoritative record.
Who funded a leg may differ from who receives its return
The unwind guide states that returned funds go to the leg’s party and its token account, regardless of who originally funded escrow. If a custodian or treasury account sends on someone’s behalf, do not assume a return will automatically go back to that original sending account. Establish the intended ownership and operational handling in advance.
Expiry is not an automatic refund instruction. The documentation distinguishes reclaiming a leg, cancelling or rejecting a trade, and recovering a qualifying late deposit. It also notes that token restrictions can affect a return. This is a reason to understand the applicable path, not a promise that any escrow can always be emptied at a fixed moment.
Program support and asset support are separate checks
The docs distinguish this escrow program from the delegation-based DvP pattern. They are not interchangeable implementations just because both aim for two-leg atomic settlement. A tutorial for one should not be used as the operating instructions for the other. The current program also has mint-configuration constraints, so a broad Token-2022 label is insufficient to establish compatibility.
- Identify the actual program, cluster and implementation rather than a generic DvP label.
- Read the stored trade fields against the agreed parties, assets, amounts, times and destinations.
- Confirm the role of the settlement authority and distinguish escrow funding from a successful settlement result.
- Understand who receives a return if the trade does not settle, especially where a different account funds a party’s leg.
The next evidence for a particular trade is its actual state and transaction result, not a headline about settlement in seconds. No live funds, signing commands or deployment tests were used to write this report. The program’s documentation and version need rechecking before operational use or publication.
For an unrelated coin exchange, consult supported assets and the exchange procedure instead of inventing a DvP integration. KOT.CASH is not described as a settlement agent or participant in this program. An escrow transaction also does not establish an off-chain delivery or another service’s account credit.
FAQ
Does the Solana DvP settlement tool launch make funding and settlement one transaction?
The program documentation separates creating, funding and settling a trade. Atomicity describes the two-leg exchange inside successful settlement.
Does a Solana DvP record prove both parties accepted its terms?
Record creation is permissionless. Read the stored terms and compare them with the actual agreement before funding.
Does Solana DvP always refund the account that sent the tokens?
The documented return paths pay the leg’s party and its token account. That may differ from a custodian or treasury account that originally funded the leg.