Solana DvP settlement requires 100% upfront cash for every trade

Solana’s newly released institutional settlement framework requires that both the complete cash and asset portions of any given trade are fully accessible prior to execution.

While its atomic transaction mechanism stops a buyer from paying without acquiring the asset, the framework itself provides neither the requisite cash nor any financing to achieve that state.

On Oct. 6, the Solana Foundation unveiled Solana DvP as an open-source standard designed for delivery-versus-payment settlement. The specified architecture places the respective tokens of each participant into separate escrow accounts before simultaneously transferring both agreed values. Furthermore, the design expressly leaves out netting, which is the procedure of balancing out obligations before settling any remaining difference.

Financial institutions might experience reduced waiting times for trade proceeds, but they must still acquire the total capital upfront for every submitted order.

The initial announcement fails to supply any quantified capital-saving metrics or comparative total-cost evaluations.

Full funding and faster reuse

Based on the outlined program constraints, a single trade record represents one exchange between a pair of participants. Both sides of the transaction must utilize token accounts hosted on Solana, and partial execution is prohibited. Any payment executed via bank rails on an external network stays outside of this atomic transfer.

The underlying settlement code, referenced at the documented source commit, verifies that every escrow account holds at least the predetermined amount for its specific leg prior to executing any asset transfer.

If either party is underfunded, the settlement fails, and any surplus tokens go back to the designated participant rather than augmenting what the counterparty takes in.

Financial accountability remains entirely with the participants and their respective financing partners. Buyers must secure the appropriate cash token, sellers must procure the correct asset token, and lenders can support either position through independent agreements—though such financing arrangements sit strictly outside the DvP framework.

According to the official funding guidelines, the funding process relies on standard, verified token transfers. A treasury or custody infrastructure can supply the required tokens without needing specialized funding functions.

At the point of settlement, both balances must satisfy the pre-arranged totals, and a designated settlement authority must provide a signature to clear the exchange.

This settlement authority—functioning as a third address identified within the trade—is required to sign off on the instruction. Destination accounts are locked in when the trade record is initially generated.

Should a mandatory transfer fail to execute, the settlement transaction is rolled back, while the initial funding deposits remain separate transactions.

Gross funding measures the capital required to execute a trade, whereas funding duration tracks how long those funds remain locked away from alternative uses. Although the bilateral design of Solana DvP demands full balances at the exact moment of settlement, it does not mandate that institutions keep those funds immobilized indefinitely.

A participant that gains access to usable cash or assets more rapidly may deploy them into subsequent trades sooner. This efficiency could decrease how long an entity relies on external funding or lower the overall liquidity it must maintain against a series of obligations.

Ultimately, these advantages hinge on precisely when funding must be provided and when the resulting proceeds become ready for deployment.

Offsetting obligations can minimize the volume of funds that actually need to move. Solana DvP does not calculate netting across multiple trades. Institutions requiring credit or netting functionalities must establish those processes externally before determining how much capital to route into their escrows.

In their tokenization report published in October 2024 (pages 12 and 13), the Bank for International Settlements and the Committee on Payments and Market Infrastructures outline this exact trade-off, noting that immediate gross settlement can demand higher liquidity than netting systems.

The report also highlights the corresponding advantage: faster access to funds and assets helps diminish the opportunity cost associated with capital tied up throughout the settlement cycle.

Regarding Solana DvP, the final overall cost is determined by the chosen funding structure and the availability timeline of usable proceeds.

An analysis conducted by CryptoSlate regarding tokenized deposits explored this identical division between accelerating cash movement and lowering required capital amounts. Its Oct. 2 Roughrider report detailed a Solana-based bank payment model where token transfers and token burning operate alongside the daily netting of bank account movements.

That particular service merges token transfers with a dedicated mechanism for offsetting financial obligations.

What the atomic exchange protects

The primary security feature is the elimination of principal delivery risk during the token swap: neither participant surrenders their side of the trade unless the counterparty’s leg moves simultaneously. While the source code repository details this exchange mechanism, the broader financial relationship continues to rely heavily on the specific instruments being traded.

Cash tokens carry the inherent credit and redemption risks of their issuers, while regulated asset tokens often retain compliance controls that can influence transfers. Capabilities like freezing, pausing, and permanent-delegate authorities remain fully active while tokens reside in escrow.

The unravelling instructions allow either party to recover their respective leg while keeping the trade active, or to cancel the transaction entirely and refund both sides. The settlement authority can also terminate the deal, and a distinct recovery process handles deposits that arrive following closure, subject to the transfer rules governing the token.

These functionalities do not bypass an issuer that decides to freeze an escrow account or block specific transfers. A fully funded transaction can still fail to finalize, and issuing refunds may rely entirely on the cooperation of the token issuer. Furthermore, the designated settlement signer must be accessible.

Based on the trade-creation protocols, refunds and reclaims are routed back to the named party’s token account, even if a custodian originally provided the deposit. Although agreed settlement destinations can capture trade proceeds, the refund pathway might differ from the original 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 instructs operators to view a settlement as complete once the transaction achieves Solana’s finalized commitment status. Whether that status satisfies legal finality depends on the agreements established between the parties and the relevant legal jurisdictions.

Deployment, audits and institutional use

Documentation provided by the Foundation outlines an upgradeable program operating on mainnet-beta and devnet, referencing observations recorded on Oct. 2. The mainnet data specifies an upgrade authority, representing an address possessing the privilege to alter the deployed code. Institutions must therefore rely on its established governance and settlement parameters.

Client instructions direct users toward a specific public source repository revision, with the most recent iteration noted as Sept. 30 within the public version history.

An audit conducted by security reviewer Cantina between May 21 and 28 evaluated an earlier version of the repository alongside subsequent patches. All four medium-severity issues were marked as resolved, while three low-risk and six informational findings were formally acknowledged.

The Foundation asserts that the program is prepared to handle actual funds, and it has welcomed design partners and early adopters ahead of a wider production rollout.

JPMorgan’s involvement remains restricted as well. The financial institution offered input regarding securities settlement practices, but the official announcement explicitly distances the bank from any responsibility regarding the design, development, operation, approval, endorsement, or guarantee of the program.

For institutional players, the most valuable subsequent proof points will link actual settlement activity with funding volumes and durations, financing expenses, and the speed at which proceeds become fully accessible.

While Solana DvP delivers a structured atomic exchange, transforming that technical capability into a true capital-efficiency tool still depends heavily on the underlying cash, assets, and financing frameworks tied to it.

?Frequently Asked Questions

01What is Solana DvP?

Solana DvP (Delivery-versus-Payment) is an open-source standard introduced by the Solana Foundation designed to execute atomic settlements where the cash and asset legs of a trade are transferred simultaneously.

02Does Solana DvP provide financing or cash for trades?

No. The program does not supply cash or financing. Participants must ensure that 100% of the required cash and assets are fully funded and available in escrow prior to trade execution.

03Does Solana DvP support netting?

No, netting—the process of offsetting obligations before paying a balance—is explicitly excluded from the Solana DvP design. Institutions must handle netting through separate arrangements.

04What happens if a trade is underfunded?

If either side of the transaction lacks the agreed token balance, the settlement fails completely, and excess tokens are returned to the originating party rather than passed to the counterparty.