Programs and architecture
Three Anchor programs, one keeper, and what lives on chain versus off.
Live, and clear about what is not.
A trade on the degen.zone curve pays about 4.19% all in. About 0.34% of that goes to degen.zone, about 0.84% to Meteora, and the rest, about 3.02% of volume, reaches the protocol. After graduation, at about 80 SOL raised, trading moves to a Meteora DAMM v2 pool that charges 1% regardless of the curve tier. Meteora keeps 20% of that, and the rest is split by liquidity share between the protocol's locked position and degen.zone's, so about 0.52% of volume reaches the protocol. The protocol's take per trade falls at graduation. It funds holder payouts in tokenized stocks, protocol-owned liquidity, a staking reserve and operations, in a fixed ratio the treasury program enforces. Staking itself is planned, phase 2: the allocation is set aside, but no staking program is deployed and nothing accepts a deposit. Values that have not been read from the chain render as a dash with the reason beside them.
Every address, on the explorer
The accounts this protocol runs on. Each links to the explorer, because a claim about a program is only worth what an independent reader can check.
These are read from the deployment file the keeper itself loads, not written into this page, so a redeployed program cannot leave a stale address in the documentation.
Exists after the curve graduates
The programs
| Program | Responsibility |
|---|---|
| dr_treasury | SOL vault; the fixed split between holder payouts, liquidity, staking and operations; the stock allowlist with Pyth feeds; the flash-fill buy; epoch funding pinned to the distributor; the liquidity vault with per-market positions and per-asset daily caps; the authority-only emergency exit from a position; governance pause and the seven-day recovery path |
| dr_distributor | Epochs, Merkle roots, claims and receipts; weighted baskets (PayoutPref); publish, fund, activate, claim, push, sweep, close. The holding-time weights are computed by the keeper and published in the epoch file; the chain stores their sum as total_shares |
| dr_staking | Phase two. Stake pool and stake accounts with checkpointed rewards; designed, not deployed |
On chain
- The split ratios, the allowlist, the basket rules, the funded-before-active rule, the one-claim-per-leaf rule and the expiry floor.
- Every position NFT and every vault, owned by program-derived addresses, and no instruction can transfer or burn a position NFT. The keeper is a signer for fees and a delegate for claims, never an owner or a destination.
- Two-step authority transfer, initialise gated on the upgrade authority, append-only account layouts and error codes, an event on every authority action.
Off chain
- The keeper: one process, one cycle every 30 minutes. Claims fees, distributes, buys, snapshots, folds the snapshot into the last 48 epochs' balance tables to weight every holder by holding time, allocates, builds the tree, writes the epoch file, publishes, funds, activates, pushes, sweeps, closes. It re-asserts every pool's fee configuration each cycle.
- The epoch files: leaves, proofs, prices, the baskets that were applied, and every wallet’s balance sample and holding-time weight. Served by this site, verified by your browser against the on-chain root; the weights can be recomputed from the files alone.
- This site: a Next.js server with a hardened RPC proxy (method allowlist, per-client windows, one shared upstream budget), the proof-file endpoint and the pages. It holds no key.
Operator limits
The keeper can spend only from the two reserves, only on allowlisted stocks, only through the guarded buy, and only up to per-asset daily caps. A quote below the oracle-implied output fails the whole transaction, so released SOL can never leave without stock arriving. The authority is separate and stronger: it can withdraw liquidity from a pool at any time, and those proceeds land only in protocol accounts. Governance can pause new operations and change operators; there is no timelock on governance itself, and that is stated rather than hidden.
Source and verification
The programs, keeper and this site are in one public repository. Program ids and every derived address are published in the deployment file the site reads; the page footer links to the repository. Tests are not an audit.