Solana Foundation has released code for settling an asset and its payment in the same transaction. That is the real development. The part still missing is evidence that financial institutions are using it for production trades.
The distinction matters because the October 6 announcement uses launch language while also inviting design partners and early participants ahead of a production release. Solana DvP is more than a concept: there is public code, a devnet demo, documentation and a security review. It is not yet a documented adoption story.
What actually shipped
The Foundation's announcement describes Solana DvP as an open-source escrow program for delivery-versus-payment settlement. In a DvP trade, one party delivers an asset while the other provides payment. The intended protection is atomicity: both transfers complete together or neither completes.
The public product page provides a browser illustration, a devnet demo and links to the program guide. The source repository is public under the MIT license. Its code and README describe a trade account with two token escrows, one for each leg.
Each party funds its leg through a token transfer. A designated settlement authority can then release the asset and payment in one Solana transaction. The parties can reclaim their own funded leg or reject the trade, while the authority can cancel it. The record includes amounts, token mints, destinations, an expiry, an optional earliest settlement time and a client reference.
That design makes the release inspectable in a way a press statement alone is not. It also gives integrators a concrete list of things to verify before moving value.
Atomic does not mean authority-free
The program removes the risk that one programmed transfer succeeds while its paired transfer fails inside the same settlement transaction. It does not remove every counterparty, issuer or integration risk.
Only the named settlement authority can call the settlement instruction. The authority does not own either user's escrowed tokens, but it controls when both legs are released. Parties therefore need an agreed process for who holds that role, which evidence authorizes settlement and what happens when a deadline or off-chain condition is disputed.
The repository also warns that creating a DvP record is permissionless. A record onchain is not proof that the named parties accepted its terms. Before funding, clients must verify the program owner, account size, derived address, amounts, mints, authority, destinations and time limits. A polished interface that skips those checks could make a genuine program display attacker-chosen terms.
The token layer adds another boundary. Solana DvP supports legacy SPL Token and Token-2022, but it rejects extensions that can change transferred amounts or prevent movement. Other accepted controls, such as freeze, pause and permanent-delegate authorities, can still affect an escrowed asset. The README tells integrators to surface those authorities as trusted parties rather than treating every supported mint as equivalent.
What the audit establishes
The repository links to a Cantina review conducted from May 21 to May 28, 2026. The published report lists four medium-risk findings, all marked fixed; six low-risk findings, three fixed and three acknowledged; and eleven informational findings, five fixed and six acknowledged.
The fixed medium findings addressed recovery and stale-deposit problems, including a route by which an old escrow address could have been reused with different terms. The verified fix keeps a permanent nonce record so the same trade address cannot be recreated after closure. Another fix lets either party reclaim a healthy leg independently after expiry rather than depending on the other token path.
The acknowledged items are not proof of an exploit. They are integration assumptions that remain relevant. The report notes that issuer-controlled token features can freeze, pause or move assets, and that some TransferHook account requirements are not fully represented in the generated interface description.
An audit is useful evidence about the reviewed code and the findings disclosed by the reviewer. It is not a guarantee about every future version, deployment, client, token or settlement workflow.
J.P. Morgan advised; it did not certify
Solana Foundation says J.P. Morgan supplied input about institutional settlement practices and requirements. Its own disclaimer narrows that role: the bank did not design, develop, operate, approve, certify, warrant, endorse or guarantee Solana DvP.
That wording should stay attached to the headline. Input from a large settlement institution is relevant to requirements gathering. It does not establish that J.P. Morgan has adopted the program, processed a live transaction through it or accepted responsibility for its performance.
The same discipline applies to the Foundation's statement that the program is ready for real funds. The announcement identifies no production institution, completed trade volume or onchain address for a named institutional settlement. The source code does identify a deployed program address, but the presence of deployed code is different from documented production usage.
Released, reviewed and still unproven
| Status | What the reviewed record supports |
|---|---|
| Released | Public MIT-licensed code, documentation, client libraries and a devnet demonstration exist. |
| Reviewed | Cantina published a May 2026 security review with fixed and acknowledged findings. |
| Institution-informed | Solana Foundation says J.P. Morgan gave settlement-practice input, with an explicit disclaimer limiting the bank's role. |
| Not yet demonstrated | The reviewed sources do not identify a completed production institutional trade, volume figure or adopting institution. |
| Next evidence | A named production participant, a verifiable settlement record, published integration controls and a clear production-release notice. |
Solana DvP deserves attention because readers can inspect the program that was announced. The next story should not be another claim that atomic settlement is faster. It should show who used this exact release, under which token controls, with which settlement authority and what public record proves completion.
For related context, see our guide to Solana account ownership and token authority, our explanation of transaction assertions, and the chain comparison learning path.
Reporting and artwork notes
Original Dev.Cooking news analysis based on Solana Foundation's dated release, public product documentation, source repository and linked Cantina report, all reviewed on October 6, 2026. Independent reports were used to identify the launch, but factual claims were checked against the primary records above. No interview, private deployment data, live-funds test or institutional adoption is claimed. The cover uses the official Solana gradient logomark under the Foundation's published rules for article use. The mark was rendered from the official SVG without recoloring, distortion or effects and placed on a plain dark background. Solana Foundation retains ownership of its marks, and no sponsorship or endorsement is implied. Corrections: Hello@dev.cooking.