07DarkBook documentation
Status
Written for someone trying to decide whether to believe the rest of this site. Everything below is either a state read from a chain or a thing that has not happened yet.
DarkBook runs on Solana devnet and nowhere else. The program is deployed, executable and reachable; the economics on the cost page come from a simulation rather than from trades on this venue; and the two parties a size-privacy claim depends on, the rollup validator and the settler, are both trusted rather than constrained. Those three sentences are the whole status, and the rest of this page is the evidence for each.
What is live
| Thing | State | How that was established |
|---|---|---|
| Program on Solana devnet | Deployed, executable | solana account against api.devnet.solana.com returns Executable: true, owner BPFLoaderUpgradeable |
| Program id | 3F99U2rZ2fob5NBgVTqQYqMq8whF4WUqiZXgeaYPE7yf | declare_id! at programs/darkbook/src/lib.rs:17, matching [programs.devnet] in Anchor.toml |
| Matching venue | MagicBlock Ephemeral Rollup, devnet | delegate_book targets the validator passed in remaining accounts, with a 1000 ms commit frequency |
| Oracle | Pyth pull oracle, 60 second staleness limit | MAX_ORACLE_AGE_SECS in constants.rs, enforced on every price read |
| Off-chain services | settler, liquidation watcher, funding cron, rollup broadcaster | source under services/ in the repository |
$ solana program show 3F99U2rZ2fob5NBgVTqQYqMq8whF4WUqiZXgeaYPE7yf --url https://api.devnet.solana.com
Program Id: 3F99U2rZ2fob5NBgVTqQYqMq8whF4WUqiZXgeaYPE7yf
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: GVFPkW36M8NbWN2fasRphwaw7DHxH7pFTt2wYLV4k8xx
Authority: 74Lo5GRC3TkHAENVo2yrt8Lnyxn2UuHPGYxg95bUEmHD
Last Deployed In Slot: 461760686
Data Length: 801176 bytes
What is not live
| Thing | State | How that was established |
|---|---|---|
| Mainnet deployment | None | the same program id on api.mainnet-beta.solana.com returns AccountNotFound; Anchor.toml has no [programs.mainnet] entry |
| Security audit | None | no audit has been commissioned or completed |
| External market makers quoting | None | the devnet book is empty and no outside desk has quoted into it |
| Desk validation of the 0.2 bps figure | Not done | the cost number is a simulation result; interviews with real makers are the intended validation step and have not happened |
| Burned upgrade authority | Not burned | the deployed program is upgradeable under authority 74Lo5GRC3TkHAENVo2yrt8Lnyxn2UuHPGYxg95bUEmHD |
Who you still have to trust
Size privacy here is a property of an operational setup, not a cryptographic guarantee. Two parties can read a size without breaking anything.
- The rollup validator. It holds the full delegated
OrderBookaccount. That account never carries a plaintext size, so the validator cannot read one from state, but it is the machine ordering and executing every match, and a compromised operator is outside the guarantee. - The settler. It is given the salt and the size for both legs in order to
submit
claim_fill. It cannot forge a size, because the program re-derives the hash and would reject a mismatch, but it can read every size it settles. This is trusted, not defended.
Neither of these is an implementation gap that a careful review would close. They are consequences of choosing a commitment scheme and a single settler over a threshold or zero-knowledge construction, which was a latency decision.
What the evidence does and does not cover
The cost figures on this site were produced by a simulation with a break-even Bayesian maker, run at 56 configurations across 16 seeds, and they carry self tests that would reject the model if the mechanism were not doing the work. What they do not carry is a single real quote. There is no venue statistic here, because there is no venue volume.
| Claim on this site | Kind of evidence |
|---|---|
| Which fields are public and which are sealed | Read from the program source, verifiable by reading the same files |
| Each leg is bounded by its own band at settlement | Enforced in ix/settlement.rs and covered by the test suite |
| Program is deployed on devnet | Read from the devnet RPC |
| Size blindness costs about 0.2 bps | Simulation output, awaiting validation against real desks |
| A risk-averse maker stops quoting the Block band | Simulation output at one risk-aversion parameter |
| Matching is under 50 ms | A property of the MagicBlock rollup the book is delegated to, not something measured on this deployment |
What would change this page
These are the concrete steps, in the order they have to happen, and none of them are in-progress claims.
- Quotes from a real desk on a size-blind book, so the 0.201 bps figure is either confirmed or replaced. If real quotes widen by materially more than 0.2 bps, the model is wrong about magnitude.
- An audit of the settlement path, which is where every check that matters is concentrated.
- A threshold settler, so one party cannot alone learn sizes. Today a single settler can.
- An optional zero-knowledge reveal, proving a commitment opens correctly without handing the plaintext to anyone.
- Mainnet deployment with the upgrade authority handled, which is the last step rather than the first.
One roadmap item with a published price
Storing a per-session trader hash on the book instead of the pubkey would reduce public whale labelling. The study measured it as wallet rotation and the result is not flattering: breaking pubkey linkability widens the transparent baseline from 1.790 to 1.936 bps, because the maker loses the split detection it runs off the trader key, and widens the banded book to 2.173 bps at the same time. The gap moves from +0.201 ±0.075 to +0.237 ±0.065. Pseudonyms are a privacy upgrade for the trader that costs everyone spread, and they do not make size privacy cheaper.