security

this page lists every key that can touch the program, what it can and cannot do, what is fixed in code, and how the code was checked. read it with the program reference.

the short version

• no admin instruction writes a user's balance. the program has no admin credit, no redeem and no raw passthrough.
• the vault pays out through withdraw and through the dev's own fee claim. nothing else.
• withdraw, closes, liquidations and claims cannot be paused.
• the upgrade key can replace the program. it is one key. read the next section.
• the program has been reviewed internally by several models, tested heavily and run on devnet with real ticks. there has been no third party audit.

the keys

key	one account holds it	where it lives in the program
upgrade authority	the program's upgrade key	the program's ProgramData account
owner	Exchange.owner	the Exchange account
pause guardian	Exchange.pause_guardian	the Exchange account
risk keeper	Exchange.risk_keeper	the Exchange account
house keeper	Exchange.house_keeper. the zero key at launch	the Exchange account
dev recipient	Exchange.dev_recipient	the Exchange account

on devnet every one of these except the house keeper is the same deploy wallet. mainnet custody of each key: set at launch.

upgrade authority

it can deploy new code to the program id. an upgrade replaces the whole program, so everything on this page is only as strong as this key. the owner and the upgrade authority are single keys. there is no multisig and no timelock.

in the current program no role can move a user balance. an upgrade could change that. this is the largest trust you take on, and it is why the key is listed first.

initialize itself can only be called by the upgrade authority. nobody else can win the race to set up the program.

owner

can:

• run genesis_finalize once
• set the win fee and the loss fee, each at most 5%
• set the reward cap C between $250,000 and $100,000,000
• set the DUST MODE mint basis, 0 to 10000 for each leverage
• list instruments, with the oracle pinned to the official verifier's storage
• set impact, timing, DUST MODE cell values and the oracle quality gate, inside compiled bounds
• set a wallet's referral tier to 0 or 1
• turn DUST MODE on, switch cells on, and reopen the opens gate
• use every risk keeper power
• reassign any role, including itself

cannot:

• move or write any user balance. a tier never touches one
• change F or S after genesis
• change a feed id or a channel after listing
• pause withdraw, harvest, closes or liquidations
• set anything past its compiled bound

risk keeper

a hot key for parameters that move fast.

can:

• set the minimum margin, the max notional and the max DUST MODE margin
• set open interest caps, up to max(20 × D0, $100,000)
• set DUST MODE exposure caps, up to 2 × D0
• set the settle delay D, with G + D staying at least 2000 ms
• switch DUST MODE off
• switch DUST MODE cells off
• lower the per wallet limits

cannot:

• switch DUST MODE or any cell on
• raise a wallet limit
• touch fees, impact, referral tiers or roles
• retire an instrument

every risk setter emits a RiskParamChanged event, so each change is a public record.

pause guardian

a hot key with two one way powers.

can:

• close the opens gate. this stops new bets, DUST MODE rounds, limit orders and limit fills
• retire an instrument. permanent. it must present a verified tick at or after the hwm, so it cannot freeze at an old price

cannot:

• reopen anything
• change a parameter

a retire is one shot per instrument, and the guardian picks which recent tick to freeze at. the control over that is custody of the guardian key.

dev recipient

it receives the dev fee and nothing else. claim_dev can be sent by any wallet, but it pays only a token account owned by the dev recipient, and only the amount accrued.

house keeper

it can authorize one thing: a fallback settle that picks a tick inside a 2P window when the exact tick is missing. at launch the key is the zero key, so no signer can match it. the fallback is off. it also closes the moment the chain has recorded any tick at or after the target time. DUST MODE rounds never use it.

your own keys

key	set by	can	cannot
session key	the owner, at most 30 days	open, close and request DUST MODE rounds, place and cancel limit orders, set triggers	withdraw, stake, unstake, claim, cancel a request, change keys
agent key	the owner, at most 30 days, with caps	the same, inside the per trade margin, leverage and total budget the owner set. closes, triggers and cancels only on what it opened	everything the session key cannot

both are revocable by the owner. a revoked agent key stops new requests at once but does not close open positions. see AI agents.

what is fixed in the program

compiled in. an authority cannot change these. only an upgrade could.

• the vault token account is debited only by withdraw and claim_dev. every other money move is an internal credit
• withdraw, harvest, closes, liquidations and claims have no pause
• no instruction accepts an arbitrary CPI payload
• a loss never exceeds the margin
• a DUST MODE round wins or loses at most its margin
• the stakers' share of a fee is 5000 bps. the referral tiers are 20% and 40% of the dev cut
• the referral bonus is 10% of the referee's mint
• a referrer is named once, before the first deposit, and never changes. nobody can refer themselves
• the price feed and channel of an instrument are fixed at listing
• the price comes only from the official Pyth Pro verifier. the storage account is pinned
• the test oracle instructions are compiled out of the production build
• G + D is never below 2000 ms
• every fee, impact and DUST MODE value has a compiled bound
• F and S are fixed after genesis, and genesis runs once

parameters has every bound.

the invariants the tests check

invariant	statement
vault identity	the vault token balance equals A + Mg + LP + SB + SF + SP + DF + RF
no admin balance path	no admin instruction writes a balance, a stake or a margin
outflows	the vault decreases only in withdraw and claim_dev
fee gating	a fee is paid only when the line is empty and the trader is paid in full
referrals	a referral never changes the stakers, the house or the line
fill xor expiry	a limit order can never be both fillable and expirable

K6 checks the vault identity against the live token balance every minute.

how it was reviewed

there has been no third party audit. the program has been reviewed internally. here is what that means.

reviews

• several rounds of internal multi model review. program revisions went through an independent security review pass and a final judge pass. the latest revision also had an outside model differential pass on its diff. each pass is a written report kept with the code.
• reviews found things, and the fixes are in the program. the security pass on the last revision stood on one high finding and said so. the judge accepted it as a bounded residual and named a measurement that gates mainnet.

what the reviews changed, by revision:

finding	what the program does now
a settler could void any pending open by omitting confidence or publisher count	a tick without them makes the transaction fail. it never voids
a guardian could freeze an instrument at an old signed tick	the freeze tick must be at or after the hwm
no freshness gate on requests, and a clock floor that was too low for the measured lag	the hwm freshness gate, and the floor G + D ≥ 2000
open interest caps had no upper bound	the risk keeper's caps are bounded
the house fallback could be used from day one	it starts disabled
the risk keeper could enable DUST MODE	only the owner can
a retire could refund a DUST MODE loss that was already decided	a decided round settles on its real ticks. the retire cannot cancel it
a close could settle over a bust the chain had already recorded	UseLiquidate, the close is refused and liquidate takes it
the fallback tick window stayed open after the exact tick was seen	it closes once the chain has recorded a tick at or after the target
a second trigger change could erase a stop that a recent tick still triggered	the second change waits for the lookback to pass

tests

• the real program in a test chain. the production binary runs in LiteSVM next to the real Pyth verifier, with real signed ticks. an upgrade test builds state under the previous binary and finishes every lifecycle under the new one.
• counts. cargo test --workspace passes 291 tests at the last program revision, with no clippy warnings.
• mutation testing. the tests were run against 87 deliberately broken copies of the order and settle logic. 85 were caught. the other 2 are equivalent changes that do not alter behaviour.
• a reference model. every worked example in the spec is generated from a pure integer model, and the program replays each value. rounding is checked against exact fractions.
• the SDK is checked against the program. its math is compared with vectors computed by the Rust code.

devnet with real ticks

the program runs on devnet with the keeper fleet and real Pyth Pro ticks. after each upgrade a gate is run. examples from the devnet runs:

• stops close at the first tick past the stop, 8 of 8, and a take profit closes at exactly its price
• a stop armed after the move is refused with BadTrigger
• a limit fill on a tick already past the bust is refused with UseLiquidate, and the order keeps resting
• DUST MODE rounds settled 72 of 72 on the first attempt
• the vault identity held at every check of the smoke run, 51 checks and none off

what is still open

mainnet waits for these:

• keeper timing. the escaped order rate and the landing time of the order keepers must be measured. the mainnet lookback comes from it
• the mainnet clock. the in transaction clock lag is measured again on mainnet before trading starts. G + D is set from it
• mainnet feed counts. the publisher floor for SOL is set from at least 24 hours of measurement

reporting a bug

send bug reports to @Dust_bid on X. use a direct message. include the transaction, the accounts and what you expected.