Verify it yourself

Everything in Trust & architecture is a claim about how the protocol behaves. This page is for readers who'd rather check than take the claim on faith.

The programs are public

All five on-chain programs, firm, bonding_curve, challenge, batch, and dispute, are deployed with matching source published to a public verified-build mirror: github.com/dylanpersonguy/decentralprop-onchain-programs. The published source is what's actually running on-chain, not a representative sample, program explorers (Solana Explorer, Solscan, SolanaFM) can verify a deployed program's bytecode against that repository directly and show a verified badge when it matches.

What to check, concretely

• A firm's treasury balance is a real token account on Solana, viewable by anyone through any Solana block explorer using the firm's public address, not a number a dashboard reports on trust.
• A settlement's trade history is committed into hourly batch roots on-chain; the underlying transcript a settlement claims to represent either hashes to the committed root or it doesn't; that check doesn't require trusting the firm or the protocol team.
• An operator's security bond is a real, inspectable account balance in the dispute program, not a claimed number.
• Token supply and mint authority for any firm's $FIRMA$FIRMAA firm's own fixed-supply token, minted at launch. Used to fund and deliver payouts via the firm's bonding curve. are on-chain facts: the mint authority is revoked at launch, which is itself a verifiable, permanent on-chain state, not a promise.
• A firm's risk score doesn't have to be taken on trust either. Every score the risk engine publishes carries the exact inputs it was computed from, and a public endpoint independently recomputes that score from those same inputs and flags it if they don't match, so a firm's published health tier can't be quietly edited without the mismatch showing up. See How the risk engine thinks.

Current status

The protocol runs on Solana devnet today, ahead of a mainnet launch. Every mechanism described in this documentation, the payout waterfallPayout waterfallThe ordered sequence a payout draws from: a firm's own treasury, its token reserve, its backstop pool, then the Universal Treasury Pool., the settlement and fault-proof flow, the operator bondOperator bondA 50 SOL collateral stake every firm posts, self-funded from its own fee revenue, seized if a settlement is proven fraudulent., has been exercised against real deployed devnet programs with real, verifiable transaction signatures, not simulated locally or reasoned about only on paper. See Security & audit status for what that testing does and doesn't cover, most importantly, that an independent third-party audit hasn't happened yet.

For builders

If you're integrating with the protocol directly rather than through a firm's storefront, the verified-build mirror above is the place to start, it's the same program source the deployed bytecode is built from, not a separate description of it.

The deployed program addresses, identical across clusters:

Each program publishes its IDL on-chain and carries security-contact metadata, so explorers show both the interface and where to report an issue without any off-chain lookup.

If you want the specification these checks are verifying against, the whitepaper has it: the determinism contract the execution engine commits to (§5), the settlement proofs (§6.4), and every protocol constant in Appendix A.