BUILD · Research → story
Anyone can write the ticket
Solana DvP makes the final exchange atomic. Permissionless creation moves the harder control earlier: verify the ticket before funding it.
A stranger can write a trade ticket with your name on it.
They can name the asset, the payment, the deadline, the settlement authority and the wallet that should receive each leg. They can place that record onchain without your signature.
This sounds like the beginning of a heist. In Solana Foundation’s Delivery versus Payment program, it is the beginning of a proposal.
No trade token moves when the record is created. The stranger cannot make you fund it, and cannot settle it as you. The sharp edge appears only if your software mistakes the existence of a record for evidence that you agreed to its contents.
The final exchange may be atomic. Consent still needs a checkpoint.
The safest button comes last
Delivery versus Payment solves a precise problem. Once both legs are funded, the named settlement authority can move the asset and payment in one transaction. Both transfers succeed together or the transaction reverts. Solana DvP guide
That removes the half-trade at the final step. It does not certify the ticket that arrived at the first step.
CreateDvp is permissionless. Only the rent payer signs creation. The two parties and the settlement authority do not. The resulting SwapDvp account is therefore a proposed instruction sheet, not a signed agreement. Pinned source
The design makes this distinction explicit. Funding is a separate token transfer controlled by each party. Settlement is a separate instruction controlled by the authority. Creation can be cheap and open because the later actors are expected to read before they act.
The address is a label, not the contract
The trade account’s address is derived from the authority, the parties, the two mints and a single-use nonce. The economic terms live inside the account. Amounts, timing and delivery destinations are stored data; the address does not bind them.
That is useful. Two parties can use the same identities and tokens for many different trades. It also creates a trap for a careless integration: deriving the expected address is not enough.
Before funding, a client needs to establish three different things.
First, is this a real DvP record? The account should belong to the DvP program and have the fixed 458-byte layout.
Second, is this the intended record? Its address should match the authority, parties, mints and nonce stored in the record.
Third, is this the intended deal? The parties must compare the amounts, time window, authority and both settlement destinations with the agreement they actually made.
The generated clients provide checked readers for ownership, layout and address derivation. They cannot know the commercial agreement in somebody’s inbox, order system or signed document. That last comparison belongs to the integrator.
Funding is where the proposal becomes real
The important moment is easy to miss because it looks ordinary. A party funds a leg with a checked token transfer into escrow. The transfer instruction does not pause to ask whether the trade record matches an off-chain order. It moves tokens to the escrow address it was given.
So the safety control has to sit before transaction construction, not in a warning after the transfer lands.
A useful integration gate can be small:
- fetch the record from a trusted RPC response;
- verify program ownership, layout and derived address;
- compare every material term with the approved order;
- inspect the token program and authorities that can affect movement; and
- build the funding transaction only after every comparison passes.
If a field is missing or different, the client should stop with the mismatch visible. It should not replace an unknown value with zero, infer consent from a familiar address, or invite the user to “continue anyway” through a generic confirmation screen.
Test the rejection path first
The smallest useful build is not a happy-path demo. It is a pair of fixtures.
Fixture A contains the expected parties, amounts, times and destinations. Fixture B changes one material field—perhaps the payment amount or the destination that receives the asset—while keeping the familiar identities and mints.
The verifier should accept A and reject B before it constructs a funding instruction. Then repeat the test one field at a time. This can run against serialized account fixtures or devnet records with no real assets. The point is to prove that the client notices the wrong ticket, not merely that the chain can settle the right one.
I did not submit a trade or reproduce the deployed program build. The source research traced the published state machine, audit and live program accounts read-only. The proposed fixture test remains a design for an integration team to execute and record.
Atomic settlement makes the last button safer. A good client makes the earlier refusal boring.
Anyone can write the ticket. Your software should decide whether it deserves the first token.