How a DVP desk works

One transaction. It burns your token deposit, pays a surcharge in SOL and issues the desk. If any part of it fails, none of it happened.

The desk is a Metaplex Core NFT, issued into a collection whose update authority is the config account rather than a person. No human key signs your mint.

Two things come with it: a desk record, which stores where your desk stands against the counter, and a vault address, which is what will hold whatever rounds buy for it. Both are derived from the NFT's address. That is the whole trick behind section 06.

The burn sits in the same instruction as the issuance, deliberately. There is no ordering in which supply goes down and no desk comes out, or a desk comes out and supply does not go down.

Those first three amounts are chosen once, when the program is initialized, and are readable from the config account from that moment. They have not been chosen yet. See section 07.

A vault needs one token account per stock in the rotation, and each one is a separate instruction.

That is a transaction size limit, not a flourish. A full rotation of account creations does not fit alongside a mint, so the client opens as many as fit and calls open_vault_account for the rest. Anyone can open one for any desk; it costs the rent and nothing else.

Waiting costs you nothing. Crediting happens on the config, not inside your vault: a round moves one number, and your desk's share of it is already yours. The token account is only needed when the tokens themselves move.

So delivery to a desk with no account for that stock does nothing, and once the account exists the next delivery pays the whole gap at once, back to the moment the desk was minted. Nothing accrued while you waited is forfeited.

A round is two instructions with a swap between them, and the program does not care what the swap was.

It can only open once the pot holds more than the round threshold, above the rent that keeps the pot account alive. Below that, nothing runs.

1. 01begin_round

   Takes lamports out of the pot, hands them to the executor, and records what the reservoir held beforehand. Both the executor and protocol authority must sign. It refuses unless a matching end_round for this program is queued later in the same transaction, which it checks by reading the instructions sysvar. Solana transactions are atomic, so a round that cannot settle cannot start, and the pot does not move.

2. 02the swap

   Whatever the executor built. In every run that has used a real router, that was Jupiter. It is not part of this program, and the program never reads what it reports.

3. 03end_round

   Reads the reservoir again and settles on the difference: the measured balance change, not the number the router reported. If that difference is under the min_out the round was opened with, the whole transaction reverts and the pot is exactly where it started.

Crediting is a single write. The measured amount is scaled, divided by the number of live desks, and added to that stock's counter. One desk, one share, not weighted by anything. A round costs the same to settle for fifty desks as for five thousand, because no desk is touched.

Your desk carries a stamp, the place it last stood against that counter. Counter minus stamp is what it is owed.

deliver moves that gap from the reservoir into the desk's vault and advances the stamp by exactly what it paid, so the fraction below a whole unit stays credited rather than being rounded away every time. It is permissionless: anyone can settle any desk, and the owner receives it either way. It is idempotent: run it twice and the second one moves nothing, because the gap is now zero. We run a crank that does this. If the crank stops, the debt does not.

what it buys

The rotation is a list on the config. Rounds walk it in order and wrap at the end. It is append only: there is no instruction to remove a stock, so anything added is something every desk is owed a share of forever, including desks minted long before it was added.

add_asset rejects active transfer fees, a set transfer hook, frozen-by-default, paused and non-transferable mints. The same policy is checked again before rounds, vault-account creation and delivery because Token-2022 authorities can change configuration after admission.

Issuer-backed equities remain issuer-controlled. A permanent delegate can claw back or burn balances, and issuer freeze or pause controls can block movement. DVP prevents incompatible active configuration from changing its own accounting; it cannot remove the issuer's authority. Nothing has been added to a live deployment.

One source works today, and it is the mint.

So the honest version is short: the pot fills from mints, from the declared royalty when a marketplace pays it, and from whoever chooses to send it something.

The protocol slice of the mint surcharge. That is the list.

Remainders below a whole unit stay in the reservoir until they grow into one. They stay credited to the desk, not to us: delivery pays whole units and advances the stamp by exactly that much, so the fraction is still owed on the next pass.

what the keys can do

Worth stating plainly, because it is the sharpest edge in this design.

The program is upgradeable, so an upgrade could add an instruction that does any of the above. That is why moving the upgrade authority to a Squads multisig is a prerequisite for mainnet here and not a cleanup task. It is a single key today, on devnet.

Nothing in the program implements "transfer the vault", and that is the point.

The desk record and the vault are program derived addresses seeded by the NFT's address, and no instruction anywhere reads who owns the NFT. There is nothing else the vault could belong to. A plain Core transfer moves the desk, and everything derived from the desk moved with it because it never pointed anywhere else.

There is no withdraw step before selling and nothing left behind after. Whoever holds the desk when a delivery runs receives what that delivery pays.

A listing changes none of it. The desk address, the stamp and the accrued balance are untouched by a transfer, so a desk sitting on a marketplace accrues exactly like one sitting in a wallet.

Held by tests under LiteSVM, not by a mainnet sale: after a transfer the desk and vault addresses are unchanged, the balance is untouched, the next round still credits the desk, a third party can settle it for the new owner, and the seller cannot move it again.

None of the economic values are chosen yet.

The first six are chosen once, when the program is initialized on mainnet, and no instruction in this program changes them afterwards. From that moment anyone can read them off the config account. The last two are compiled into the program and are the same on any deployment.

The art set is fifty desks. max_desks is the on-chain cap and is a separate number that has not been set.

Everything the program uses, and what does not exist yet.

config, pot and collection are program derived addresses. They come from the program id and a fixed seed, so anyone can recompute them and check that these are the ones the program uses.

Each rotation stock also gets a reservoir, an associated token account owned by config, created by add_asset when the stock joins the rotation.