For builders

Everything a firm publishes about itself is readable without our permission, and that is deliberate. This page is for people integrating with the protocol directly: indexers, dashboards, explorers, bots that read state, and anyone who wants to verify a claim rather than repeat it.

Start with the boundary, because it saves time: there is no trading API, and there will not be one. Order entry is browser-only for every account on the platform, which is what makes "no bots, no copy trading" enforceable rather than a term of service nobody checks. Everything below is read access and on-chain state.

The programs

Five Anchor programs, same addresses on every cluster:

Each publishes its IDL on-chain, so anchor idl fetch <address> gives you the account and instruction layout without a repo checkout. Each also carries security.txt metadata, so explorers show a contact route without an off-chain lookup.

Verifying the deployed bytecode

Source is mirrored at github.com/dylanpersonguy/decentralprop-onchain-programs, and it is the source the deployed programs are built from rather than a description of them.

To check that yourself:

solana-verify verify-from-repo \
  --url <cluster> \
  --program-id <address> \
  https://github.com/dylanpersonguy/decentralprop-onchain-programs \
  --library-name <program>

Two gotchas worth knowing before you conclude something is wrong. Builds must come from solana-verify build rather than a plain anchor build, because the two are not guaranteed to produce identical bytecode across host platforms. And the challenge program on devnet is built with a devnet-fast feature that shortens its fraud window to five minutes for testing, so its devnet hash will not match a mainnet build of the same source. Mainnet never uses that feature.

Solana Explorer, Solscan, and SolanaFM all read the same verification and show a badge when it matches.

The public read API

A read-only HTTP surface sits at /api/v1/public on the platform API, no key and no auth. It is rate limited to 300 requests per minute per IP by default, because several routes proxy to a paid RPC. Responses are { success, data } or { success, error: { code, message } }.

/firm/:slug/proof is the one most integrations want. It is the difference between a firm's claimed payout total and the portion carrying an on-chain receipt, which is the number the firm directory ranks on and the number no firm can inflate.

Verifying a single fill

GET /verify/:fillId returns the execution receipt for a fill together with the batch commitment covering the price tick it was filled against, and the signing public keys.

That bundle is what makes a fill checkable rather than merely reported. Each account gets its own seeded random stream, so a fill can be reconstructed independently and compared against what the engine claims happened, and the price it was filled against either hashes into the committed batch root for that hour or it does not. Neither check requires trusting the firm or us.

How fills are actually fair is the mechanism. How settlement actually works covers the two-root transcript, the challenge window, and the five specific fraud proofs.

Reading firm state directly from the chain

Everything the API reports about a firm's solvency is derived from accounts you can read yourself:

• Treasury balance is a real token account, readable by address from any RPC.
• Token supply and mint authority are on-chain facts. The mint authority is revoked at launch, and that revocation is permanent and inspectable rather than a promise.
• Curve reserves live in the bonding_curve program and are what actually back a payout, so depth is readable rather than reported.
• 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. is a real balance in the dispute program.
• Batch roots are the hourly commitments in the batch program, and they are what a settlement is checked against.

If the API and the chain ever disagree, the chain is correct and the bug is ours.

Recomputing a firm's risk score

Every score the risk engine publishes carries the exact inputs it was computed from, and a public endpoint recomputes the score from those inputs and flags a mismatch. That means a published health tier cannot be quietly edited without the discrepancy surfacing, and you can run the check yourself rather than trusting the number. See How the risk engine thinks.

What to build

The obvious gaps, in case you are looking for one: a firm-solvency dashboard that ranks on proof rather than claims, an independent watchtower that checks proposed settlements during their challenge window, a payout-receipt feed, and token analytics that read curve depth rather than the last print. The watchtower is the one with a bounty attached, in the literal sense: a successful fraud proof seizes the operator's bond and pays half of it to whoever produced the proof.

The specification

The whitepaper is the reference the checks above verify against: the determinism contract the execution engine commits to in §5, the settlement proofs in §6.4, the trust assumptions that remain in §6.8, and every protocol constant in Appendix A.