Contents

Abstract

The funded-trader industry — prop firms that charge traders a fee to prove their skill, then fund the winners — generates billions of dollars per year across more than a million evaluations annually. It is also structurally broken: every firm is a trusted black box. Traders must believe on faith that fills are fairly priced, pass/fail decisions follow the published rules, the firm holds enough reserves to pay, and the operator will actually release winning payouts. None of these promises can be independently verified.

DecentralProp rebuilds this industry on Solana. The core thesis: replace each of the four invisible trust assumptions with something publicly verifiable. The funding side — every treasury, fee split, payout, token, and stake — lives in five Anchor programs whose logic is program-enforced and whose events are permanently public. The trading simulation runs off-chain, as it must for latency and cost reasons, but is wrapped in a seven-layer trustless architecture: signed execution receipts, hourly Merkle trade roots (distinct from the 72-hour fraud-proof window that gates each settlement), an optimistic fraud-proof settlement protocol, an operator bond that is slashed for dishonesty, permissionless watchtowers paid to catch lies, a guardian key on insider-reachable paths, and a 7-day public wind-down timelock.

Each firm is its own tokenized economy: payouts are backed by the firm's SOL treasury, which purchases $FIRMA — a fixed-supply per-firm token on a constant-product bonding curve — off the open market and delivers it directly to the winning trader's wallet. $FIRMA is the delivery medium, not the backing asset. An Autonomous Risk Engine (ARE) manages each firm's risk posture by rule, continuously, with no human discretion. The protocol token, $DPROP, is designed to accrue value through buy-and-burn sinks fed by every deployment, evaluation, and graduation event; $DPROP has not launched, and §13B states exactly what those sinks are and are not doing in the meantime.

1 · Introduction

The funded-trader industry

In the modern prop-firm model, a trader pays a fee — typically $50–$500 — to take a simulated trading evaluation. The evaluation tests whether the trader can hit a profit target (commonly 7–10% of the account) without breaching a drawdown limit. Traders who pass are funded: they receive a virtual account and earn a share (typically 70–90%) of any simulated profit they generate.

This model has scaled to a multi-billion-dollar industry. Firms like FTMO, Topstep, and FundedNext collectively process over one million evaluations per year. The demand is real and durable: millions of retail traders worldwide cannot access institutional capital but have demonstrable edge. The prop firm converts retail skill into access to scale.

The structural problem

The industry's growth has been shadowed by a chronic trust problem. The evaluation runs on the firm's own private servers — an unauditable black box. Four things are invisible to the trader: execution fairness, judgment integrity, solvency, and payout enforcement. The industry's response has been social: review aggregators, influencer "trust scores," occasional audits. These are lagging, gameable, and structurally insufficient. Reviews can't see inside the engine.

Worse: because the simulation is off-chain, even an honest firm cannot prove it didn't cheat. The deeper problem is incentive alignment — in a centralized firm, the operator profits when traders fail and pays out of pocket when they win. The financial incentive is structurally against the customer. No branding or compliance overhead changes this math.

The DecentralProp thesis

DecentralProp's thesis: every one of the four trust assumptions can be replaced with something publicly verifiable — the trader can check each claim instead of taking it on faith. This is a new DeFi category: a skill-gated funding protocol — a permissionless, tokenized system where operators deploy capital to fund skilled traders, all trust is replaced by program-enforced guarantees, and the economics run themselves via an autonomous on-chain engine. The demand side is proven. The innovation is trustlessness.

2 · The problem with "trust me" funding

Four invisible trust assumptions

Trust 1 — Execution: The simulation engine runs on the firm's private servers. The fill formula is opaque. A firm adding 5 basis points of extra spread systematically against open positions could turn a passing account into a failing one — undetectable by the trader.

Trust 2 — Judgment: Pass/fail is declared by the firm's own software. Whether the rulebook was actually applied to that account on that day is a matter of faith.

Trust 3 — Solvency: Some firms pay early winners with later buyers' fees — a Ponzi structure invisible from the outside. No firm publishes audited reserve levels.

Trust 4 — Payout Enforcement: Even if funds exist, no code compels the operator to release them. The only recourse is a chargeback dispute or public complaint — both slow and ineffective.

Why social fixes don't work

Review aggregators document trader experiences but cannot provide structural assurance. Reviews are lagging (document the past, not the present), biased (losers complain more), gameable (firms can manufacture reviews), and — most critically — they cannot see inside the engine. They can only report whether someone got paid, not whether the fills were fair or the rules were honestly applied. The fix must be systemic, not social.

3 · What DecentralProp is

A prop-firm factory on Solana

DecentralProp is a decentralized funding protocol — a set of on-chain programs plus an off-chain execution engine, joined by a cryptographic protocol that keeps the engine honest. Any operator can deploy a "firm" by paying a one-time launch fee. The protocol instantiates the firm's treasury, fixed-supply token, bonding curve, insurance fund, and staking pools — all governed by the same on-chain programs, all subject to the same trustlessness guarantees. The operator configures a few parameters at onboarding; the Autonomous Risk Engine manages everything else.

The result is a permissionless prop-firm factory: anyone can launch a firm, traders interact with every firm through the same trustless interface, and the protocol earns a fee on every deployment and evaluation without owning or managing any firm.

3.1 — Six objections, pre-answered

A sophisticated reader raises the same six objections immediately. Each is answered by a structural property of the protocol, not a policy promise.

3B · A new organizational model

For the first time in the history of commerce, the operating company itself — not just an intermediary in a flow of capital — can be replaced, as far as is technically and legally feasible, by a shared autonomous protocol. Humans build brands, interfaces, and communities on top. They do not make the business decisions.

Most DeFi replaces an intermediary between participants: an AMM replaces the market maker, a lending pool replaces the bank's matching desk, a perps venue replaces the exchange. DecentralProp replaces something different — the operating company that runs a skill-based funding business. There is no risk desk, no payout-approvals team, no compliance officer with a discretionary override. Those functions are encoded in Solana programs and an autonomous control loop, with no discretionary override reachable by any operator key. This is not a DAO (vote-governed, human-in-the-loop); it is a rules-encoded-in-programs enterprise where operational policy runs without any human waking up to decide anything.

3B.1 — The organizational evolution

At each stage of this evolution, the locus of operational control moved further from individual humans and closer to structured, scalable systems. The autonomous protocol is the next step.

The franchise analogy

Imagine a franchise restaurant chain. Corporate decides the recipes, the supply chain, the pricing ranges, the branding standards, and quality control; the franchise owner runs the location. Now remove the corporate executives entirely — corporate exists only as Solana programs. No operator can wake up tomorrow and raise leverage limits, secretly approve a payout, drain the Universal Treasury Pool, bend the evaluation rules for a specific trader, or disable the integrity engine: none of those are instructions any operator key can call. The programs themselves are not yet frozen, and §6.8 states plainly who can still upgrade them and on what path that ends. The franchise owner's role becomes brand, community, and distribution. The protocol is the headquarters that cannot be corrupted, called in sick, or bribed.

3B.2 — Brand liquidity vs. financial liquidity

A DeFi reader's instinct is that launching thousands of independent firms fragments liquidity — and fragmentation reduces efficiency. That instinct is correct in general and wrong here, because the protocol separates two things that are usually fused: brand liquidity from financial liquidity. Every firm has its own branding, community, marketing, and per-firm $FIRMA token. But all firms share the same risk engine, integrity posture, Universal Treasury Pool, execution engine, and payout waterfall. Only the brands are fragmented. The capital infrastructure is not.

3B.3 — The network becomes the company

In a normal market, every company builds its own treasury, staff, management, and systems from scratch. Here, every new deployment joins one continuously improving financial network. Each new firm brings concrete, shared upside:

• 1% of every eval fee → the Universal Treasury Pool, deepening last-resort liquidity for every firm automatically.
• 3% of the deployment fee → the Universal Treasury Pool at launch — a contribution made before a single trader buys.
• 10% of every eval fee → the $DPROP staking pool, raising SOL yield for protocol-token holders across all firms.
• A franchise slice of the deploy fee → a dividend to existing same-tier firms — a network income stream isolated firms never had (see §8.1).
• More behavioral data → sharper integrity detection (cross-firm rings are invisible to an isolated firm; the network sees them).
• More trading patterns → better ARE posture calibration; more $DPROP burned with every deploy and eval → deflation that scales with the network.

In most DeFi, adding users deepens one shared pool. Here, adding firms deepens the protocol-level pools (Universal Treasury, $DPROP staking, $DPROP burn) while each firm keeps its own independent $FIRMA curve — so participants are incentivized to grow the whole network without ever competing for the same liquidity. The network itself becomes the operating company.

3B.4 — Distribution without a marketing team

The sections above remove the staff a prop firm needs to operate. They do not remove the one it needs to be heard, and an autonomous firm that nobody has heard of is a well-run business with no customers. Marketing is the last department, and it is the hardest one to automate honestly, because the usual automation is a scheduler posting copy nobody reads.

This protocol splits that problem into publishing and distribution, and solves them separately.

Publishing is event-driven. Nine on-chain events already known to the protocol trigger a post: a payout delivered, a trader funded, a first payout, an unusually large trade, a win streak, a lifetime-payout milestone, a liquidity milestone, a curve graduation, and a generic milestone. The copy is the operator's own template, approved once, with live values (treasury depth, token price, the firm's happiness score) resolved at post time, and the payout certificate attached where one exists. The firm never posts a claim about itself that an event did not cause, which is a stricter editorial policy than most firms manage with a staffed account.

Distribution is the firm's own traders. Every post lands in the earn feed described in §11.4, where the traders at that firm can like, repost, quote or reply to it for airdrop points. That is the whole mechanism: the audience most credible to a prospective trader is a real trader with a real account, and their timeline reaches people the firm's own account never will.

Three properties make this a marketing budget rather than a giveaway.

• It is paid in a currency the protocol issues, not in the firm's money. Amplification costs points, drawn from that firm's monthly pool. Nothing leaves the treasury, no SOL is spent, and the operator is not writing cheques to an agency. The pool is granted by the protocol to every deployed firm and scales with its deploy tier (5,000 a month at Starter up to 60,000 at Enterprise). At the protocol's own anchor of one point per dollar of evaluation fee, a Growth firm's 10,000 points a month is the same distribution credit $10,000 of evaluation spend would earn. What that converts to in dollars is deliberately not claimed anywhere in this paper: the $DPROP supply share and claim mechanics are unset (§11.2, §13B).
• It is bounded before it is spent. Each firm has a fixed monthly allowance and no rollover, so the cost of the channel is known in advance and cannot scale with its own success. The trader-side ratio in §11.4 applies on top, which is why most engagement below meaningful revenue is issued locked and never counts at all.
• It cannot be bought. A firm cannot pay for more reach than its allowance, and a trader cannot convert engagement into anything without having spent real money themselves. The two ceilings that stop the airdrop being farmed are the same two that stop this becoming a paid-promotion market.

The loop closes on the same event that makes the firm worth talking about. A payout settles on-chain, the post that announces it is caused by the settlement rather than written about it, the firm's traders amplify it to people who are deciding where to buy an evaluation, and the receipt for the claim is a transaction anyone in that audience can open. Nobody runs the campaign, and the thing being advertised is the thing that actually happened.

4 · Architecture

The funding side is fully on-chain. The trading simulation is off-chain — and wrapped in a verifiability layer that reduces it from a trusted authority to a checkable worker.

4.1 — Five on-chain programs

4.2 — Off-chain components

The following run off-chain — not because they could be moved on-chain, but because on-chain execution of a realistic trading simulation would be prohibitively expensive and slow:

• SimCore / execution engine. Consumes Pyth price feeds via Hermes, simulates fills with configurable spread and slippage, applies the live risk-rule evaluator each tick, and produces a deterministic, replayable transcript.
• ARE compute loop. Reads on-chain treasury balance, pass rates, payout exposure, and market volatility every ~15 minutes; computes a risk score; applies lever updates.
• Settlement keeper. Proposes settlements, drives the fraud-proof window, finalizes clean settlements, cranks queued payouts and buy-backs. Critical roles are permissionless.
• Watchtower. Replays every Provisional settlement; submits fault proofs when fraud is detected. Anyone can run this and earn the prover bounty.

4.2b — Access surfaces

The protocol is one thing; the ways in are several, and they matter because the audience a prop firm recruits from does not universally arrive holding a funded Solana wallet. None of these change protocol behaviour — every one of them lands on the same instructions described elsewhere in this paper — but a description of the system that omitted them would understate how a trader actually reaches it.

• The web terminal and per-firm storefronts — the primary surface. Sign-in is wallet-only; there are no email accounts.
• A per-firm Telegram bot and Mini App, giving each firm a branded trading and payout surface inside Telegram, plus peer-to-peer tipping between traders.
• A platform-generated custodial wallet, for traders who want to start without bringing their own. This is a real custody tradeoff, offered as a choice rather than a default, and it is the one path in this list where a user is not holding their own keys.
• A fiat on-ramp, so an evaluation can be bought without first sourcing SOL elsewhere.

Trading itself is deliberately restricted to these interfaces. There is no public trading API and no programmatic order entry: an evaluation is a test of a person, and an endpoint that accepts orders from a script is a different product with a different risk model.

4.2c — The wallet hub: one record across every firm

A trader who evaluates at four firms is four database rows. User is unique per (firmId, walletAddress), and every read surface in the protocol is firm-scoped, because that scoping is what stops one operator reading another's book. From the operator's side that is isolation. From the trader's side it was amnesia: the protocol knew a wallet had passed at three firms and had no way to say so.

The wallet hub is the one authenticated surface deliberately not firm-scoped. It fans out on the wallet address itself — resolved server-side from the session, never from a caller-supplied parameter, and every route on it is a read. It shows one wallet's record across every firm it has traded at: Wallet Standing with the exact distance to the next band (§10B.4), cross-firm win rate, net P&L and payout history, the firm-token portfolio, payout readiness per funded account with the reason anything is blocked, and one public identity that travels with the wallet rather than with a firm.

Two of its screens are where a trader decides where to spend money, so they are built as evidence rather than as a shopfront. The directory compares every firm on the protocol in one table — payouts proven on-chain, treasury against what is owed, resolved pass rate, the backing composition, the live curve, entry terms — and every column is on-chain state or a settled aggregate that a stranger can check on an explorer. The per-firm page opens on the settled payout ledger, with each delivery linking to its signature. The ranking weights that order the table are published in the same response as the numbers they order, along with the list of claims the ranking engine refuses to make.

The comparison sites this resembles rank firms on affiliate economics and print whatever a firm claims about itself. The layout is the same and the medals are the same; the difference is that each figure here resolves to a transaction, and a firm cannot buy its position.

4.3 — The seam: how off-chain binds to on-chain

5 · The execution engine (SimCore)

Why off-chain is necessary

A realistic trading simulation requires sub-second fill execution, continuous price feed consumption, tick-level position tracking, and simultaneous state management for thousands of concurrent accounts. No blockchain satisfies these requirements at acceptable cost and latency. This is not a design choice — it is a physical constraint. The correct architectural response is to accept the off-chain constraint and solve the harder problem: making the off-chain simulation independently verifiable. This is what the seven trust layers in §6 accomplish.

How SimCore works

SimCore consumes real market prices via Pyth (via Hermes). For each position it: fetches the current Pyth mid-price and confidence interval; applies the ARE-snapshotted spreadMultiplier and slippageMultiplier to compute the fill price (fillPrice = basePrice + spread ± slippage); updates the account's equity, peak equity, daily P&L, and breach flags; emits a signed execution receipt containing the quoted bid/ask, neutral mid, base price, spread and slippage applied, and resulting fill price; and periodically commits all trade ticks to the batch program as a Merkle root.

Why closed-source is defensible

The fill formula and risk-rule evaluator are proprietary — the realism and anti-abuse heuristics are the moat, and publishing them would invite systematic gaming. Crucially: closed-source does not mean unaccountable. You do not need to read the engine to prove it did not cheat. The commitment architecture makes the engine's output checkable by anyone with the Merkle proofs, regardless of the engine's source code.

Determinism contract

For the fraud-proof to work, the on-chain verifier (Rust) and the off-chain engine (TypeScript) must compute identical results for any given step. This parity is enforced by a golden test vector lock: canonical inputs whose expected SHA-256 hashes are hard-coded in both Rust and TypeScript test suites. Any divergence — one digit, one rounding difference — breaks both test suites simultaneously. The contract covers: micro-USD amounts (1e-6), integer division truncating toward zero (i128 matches BigInt), SHA-256 over canonical decimal strings, and exact operation order in apply_step.

6 · Trustlessness, end to end

Trustlessness here is not one feature — it is seven independent layers, each closing a specific way an operator could cheat. They compose: to steal, an attacker must break all seven, in public, on-chain.

The goal stated plainly: a perfect-information, self-sustaining funding protocol where trust is replaced by verification, from end to end — including over its own creators.

6.1 — Layer 1: custody & accounting

What it closes: can the firm pay out money it doesn't have, or create tokens out of thin air?

• Fixed token supply, mint authority burned. $FIRMA is minted once at deployment and the mint authority is permanently revoked (distribute_supply → revoke mint authority to None). No one can ever mint additional $FIRMA. Payouts buy $FIRMA from the bonding curve — they never create it.
• Payouts bounded by real reserves. The program refuses any payout exceeding the actual treasury balance, with additional layers: daily cap max(20% treasury, floor), an 8% concentration guard on single payouts, and a Critical-tier circuit breaker that queues all payouts until stress passes.
• Everything is public. Every fee split, payout buy, and balance change is emitted as a public on-chain event. Solvency is a number any wallet can read from chain state in real time.

6.2 — Layer 2: provably-fair execution

What it closes: can the engine give a trader worse fills than the market showed?

Every fill emits a signed execution receipt containing the quoted bid/ask, neutral mid, base price (tied to the committed Pyth feed tick), spread and slippage applied, and resulting fill price. The signature makes numbers tamper-proof. The fill formula (fillPrice = basePrice + spread ± slippage) is checkable: a verifier reproduces the math and any fill that violates the disclosed rule is provably bad. Every receipt's tickHash is committed into the batch program's hourly Merkle roots — immutable evidence that cannot be silently revised.

6.3 — Layer 3: Merkle trade evidence & disputes

What it closes: can the operator ignore a winning trade, or drop a losing one to shape a result?

Every trade is a leaf in an hourly Merkle tree whose root is committed on-chain and is append-only (a second commit for the same hour fails). If a trader believes a trade was omitted or misrepresented, they submit a Merkle inclusion proof (dispute.open_dispute) showing the trade was in the committed root. The proof is verified on-chain. If the operator stalls past the deadline, the trader force-resolves in their own favor. A proven fraudulent outcome slashes the operator's bond.

6.4 — Layer 4: verifiable settlement (F5)

What it closes: can the operator declare a fake result — fabricated pass, inflated profit, wrong starting balance?

This is the crown jewel. Layers 1–3 keep inputs honest. Layer 4 keeps the output honest through an optimistic fraud-proof protocol:

What a settlement commits

propose_settlement writes four independent commitments plus the chain's own derived genesis, and the separation is what makes the fault proofs sharp rather than all-or-nothing:

• transcript_root — Merkle root over this cycle's state chain, rebaselined from genesis to final.
• step_root — root over bare step_hash leaves. Transition faults verify against this one.
• bound_step_root — root over provenance-bound leaves, each tying a step to the trade evidence that produced it. Input and provenance faults verify here. Two roots rather than one is what lets a prover attack a step's arithmetic and a step's origin as separate claims; a single root would force every proof to re-establish both.
• genesis_state_hash — the starting state the chain derived at propose time (a rebaseline of the previous cycle, or genesis_state(rules) for cycle 0). The keeper never gets to choose it.
• final_state_hash — the state the payout amount was bound against, alongside the transcript length and the highest batch epoch the cycle consumed. That epoch boundary is what makes consecutive cycles partition the trade timeline instead of overlapping or leaving gaps.

The fault proofs (all permissionless)

Six proofs cover the evaluation-settlement path:

• prove_settlement_fault (Transition). Reveals one step where the committed history is internally inconsistent — chain recomputes apply_step(prev_state, step, rules) and faults if the result hash doesn't match.
• prove_result_fault (Result). For a consistent transcript with a wrong claimed pass/profit — chain recomputes derive_outcome from the committed final state.
• prove_genesis_fault (Genesis). Faults any claim that the evaluation started with a different balance than the rules deterministically produce — closes the "fabricated starting equity" attack.
• prove_input_fault (Input). Faults a step whose committed inputs don't match the evidence they claim to come from.
• prove_provenance_fault (Provenance). Faults a step bound to trade evidence that does not exist in the committed batch — the proof that catches an invented fill rather than a miscomputed one.
• prove_integrity_fault (Integrity). Routes a proven integrity violation to the same slashing path.

A second family of five covers the withdrawal path, which settles a funded trader's payout rather than an evaluation's outcome and therefore needs its own genesis, amount, transition, input and provenance proofs (prove_withdrawal_*). A payout is where money actually leaves, so it gets the same adversarial treatment as the evaluation that produced it rather than inheriting its result on trust.

Every cheating vector is closed

6.5 — Layer 5: operator bond & slashing

What it closes: is cheating ever rational?

Before settling any account, an operator must post a bond of ≥ 50 SOL (init_operator_stake, MIN_OPERATOR_STAKE_LAMPORTS). If a settlement is proven fraudulent, the permissionless slash_settlement_fault seizes the entire bond:

A lying operator loses their bond and receives no payout (it never finalized). After any slash the operator's stake is marked suspended and cannot settle again until it is re-bonded to the full ≥ 50 SOL minimum (reinstate_operator_stake) — so cheating is not only unprofitable, it halts the operation until fresh collateral is posted. An honest operator cannot be falsely slashed — the substituted_step_is_not_a_fault test proves soundness runs both ways.

6.6 — Layer 6: watchtower & permissionless verification

What it closes: what if no one is watching?

DecentralProp runs a default settlement keeper. But security does not depend on it: prove_*_fault, finalize_settlement, and slash_settlement_fault are all permissionless — any funded wallet can call them. The 50% prover bounty makes running an independent watchtower economically rational. The honest liveness assumption: the 72-hour window, economic bounty, and DP default keeper provide defense in depth. Independent watchtower ecosystem is the target; DP keeper is the floor.

6.7 — Layer 7: insider hardening

What it closes: can an insider with the firm's keys drain it?

• Two-key rule. Closing a firm, drawing the backstop, paying a dispute — require two signatures: firm authority and an independent platform guardian.
• 7-day shutdown timelock. initiate_close starts a public countdown before finalize_close can run. Traders and stakers have time to exit.
• Zero-obligation gate. finalize_close is hard-gated on open_payouts == 0. A firm cannot close while it owes a single queued payout.
• Insurance never goes to the owner. Insurance residual routes to the DP treasury (future: cross-firm mutual pool), never the operator.
• Vesting clawback on bankruptcy. clawback_vesting pulls unclaimed, unvested owner fee batches back to the treasury — owner forfeits unvested income so traders are made whole first.

6.8 — Remaining trust assumptions

A credible whitepaper states its residual trust assumptions. The trust model has three tiers:

The upgrade-authority migration: (1) Squads multisig before mainnet value — no single key can ship upgrades; (2) Timelock before meaningful TVL — upgrades announced N days ahead; (3) Revoke (--final) after audit — settlement-critical programs become permanently immutable. As of this paper's date, programs are pre-mainnet with a single deployer key — maximum residual trust. Credibility comes from the committed, observable path, not from pretending it's already revoked.

7 · Market structure: player vs. protocol

The incentive flip: everyone wins on a payout

In a centralized prop firm, the operator's financial interest is structurally against the customer: the owner profits from a blown account and pays out of pocket when a trader wins. In DecentralProp, the firm admin has no direct access to the treasury. When a payout fires, value flows across every stakeholder simultaneously:

• The trader receives their earned $FIRMA.
• Normal stakers earn their stakeholder yield (via sync_firma_yield).
• The $FIRMA supply decreases via the burn share — price support for all holders.
• The treasury reserve thickens via the $FIRMA buy-back leg.
• The firm owner participates through owner fee legs, $FIRMA appreciation, and franchise dividends — not by raiding the vault.

A payout is proof that the firm pays, and that proof attracts the next wave of traders, whose fees refill the treasury.

7.2 — The hidden dangers of PvP DeFi protocols

Beyond the structural zero-sum problem, PvP on-chain trading environments like pump.fun-style token launches expose participants to a second layer of systemic risks that are baked into how public blockchains operate. These risks are not theoretical — they are observable, documented, and actively exploited every day on every chain:

7.3 — The asset universe: deep markets only

DecentralProp eliminates the thin-market problem entirely by design. Traders evaluate their skill against deep, globally traded markets — instruments with billions of dollars in daily volume that no individual actor or coordinated group can realistically manipulate:

• Major Cryptocurrencies: BTC/USD, ETH/USD, SOL/USD, and other top-tier crypto pairs with deep global order books.
• Forex Majors: EUR/USD, GBP/USD, USD/JPY, AUD/USD, and other G7 currency pairs, with daily volume exceeding $7 trillion.
• Popular Stocks & Indices: S&P 500, NASDAQ, and major equities with deep institutional liquidity and regulated price discovery.

By restricting the instrument universe to these deep markets — all priced via Pyth's high-frequency oracle feeds — the protocol ensures that price discovery is external and credible, manipulation is economically implausible, and the evaluation tests genuine market-reading skill, not the ability to exploit thin liquidity. A trader who demonstrates edge against BTC/USD is demonstrating real skill, not pump-and-dump timing.

7.4 — sSOL and sUSD: the simulated asset layer

This distinction sits at the heart of how DecentralProp works and why it eliminates so many traditional DeFi risks. The protocol operates on two conceptual layers simultaneously:

The simulated layer (sSOL / sUSD)

During an active evaluation, everything inside the trading terminal operates on simulated balances. When a trader "opens" a 2 SOL long position on BTC/USD, no real SOL moves on-chain. The account is denominated in sSOL (simulated Solana) and sUSD (simulated US dollars) — virtual notional balances that reflect the trader's account size and P&L calculated against live Pyth price feeds. This is what makes the evaluation environment:

• Free from MEV and sandwich attacks — there is no mempool, no real transaction to front-run, no ordering to exploit.
• Free from real on-chain fees per trade — SimCore processes fills internally; no Solana transaction is submitted for each position. Gas costs are irrelevant to trading performance.
• Accessible to any skill level — traders can open large notional positions (e.g. $100,000 sUSD equivalent) to test institutional-scale strategy without needing institutional capital.
• Replayable and verifiable — because sSOL/sUSD state transitions are deterministic and use committed Pyth prices, they can be replayed on-chain step by step for the F5 fraud-proof. A simulated env that produces real receipts.

The real layer — payouts in real assets

When a trader completes their evaluation successfully and reaches the Funded phase, the simulated performance converts into a real on-chain payout. This is the moment the two layers meet:

1. The settlement finalizes on-chain (F5 fraud-proof window closes clean → Final status).
2. The payout is drawn through the waterfall: the firm's SOL treasury buys real $FIRMA off the bonding curve in a single on-chain transaction.
3. The $FIRMA tokens are delivered to the trader's wallet address — one transaction, visible on-chain, from the payout page in the trading terminal.

The trader's sUSD virtual profit becomes real $FIRMA (or real SOL, depending on the routing), deposited directly and trustlessly — no withdrawal form, no KYC gate, no operator discretion. The payout is program-enforced to the recorded wallet and nowhere else.

This architecture achieves something that neither pure DeFi trading nor centralized prop firms accomplish: the evaluation environment is as clean and fair as a spreadsheet (simulated, deterministic, manipulation-proof), while the payout is as real and trustless as any on-chain transfer.

8 · The economic engine

There are two inflows into the entire protocol: a firm's one-time deployment fee and the per-evaluation fee paid by traders. Everything else is a redistribution of these two inflows.

8.1 — Firm deployment fee

8.2 — Evaluation fee splits

Two notes on legs that used to appear here. Loss-back is no longer a fee leg. Until July 2026 a fixed 2% left every fee for a comeback-credit vault whether or not the buyer ever returned. It is now computed as a notional accrual inside pay_challenge_fee: the 2% stays in the treasury remainder by default and costs the firm nothing unless a trader actually comes back and redeems a discount. The affiliate rate is platform-locked at 10%, not firm-set — the firm cannot bid it up to buy volume, and 1% of it is the platform's share, so a referred purchase pays the affiliate 9% net and that slice stays in the treasury on every unreferred purchase.

8.3 — Per-actor value map

8.4 — Worked end-to-end example

Growth-tier firm · curve depth <$50k · backstop active · buyer unreferred · $100 eval fee · trader passes Phase 1 → Phase 2 → Funded · earns $10,000 virtual profit · 80% payout split.

8.5 — The treasury health split

Everything above describes the fee split at a firm whose treasury still needs filling. That is the right default and the wrong permanent answer: a firm holding 5,000 SOL against a handful of open evaluations is over-capitalized, and continuing to route the same share into its treasury under-pays the operator, the stakers, the buybacks and the shared pool for no gain in solvency.

So the split moves. Once a firm's own treasury_sol crosses tier-scaled thresholds, the marginal evaluation fee redirects away from the treasury across five zones — Growing → Healthy → Strong → Thriving → Saturated. The LP, backstop, affiliate, insurance and comeback-credit legs are untouched, because none of them exist to capitalize the treasury.

Starter, Growth and Pro deliberately share one ladder. Treasury health is a question about payout obligations, and obligations track the account sizes a firm actually sells — not which launch fee its operator once paid.

The total redirected at Saturated is derived rather than tabulated: boost_max_bps(tier) = 4400 − owner_bps_for_tier(tier), so a Pro firm redirects at most 3,500 bps. Each zone takes a linear fraction — 0%, 25%, 50%, 75%, 100% — and the redirected amount splits by fixed weight: Owner 20%, DecentralProp 20%, $FIRMA staking 15%, $DPROP staking 15%, buybacks 20%, Universal Pool 10%. For a Pro operator that means an effective fee share rising 9.00% → 10.75% → 12.50% → 14.25% → 16.00% as the treasury fills. The reward for capitalizing a firm is paid out of the same mechanism that proves it is capitalized.

9 · Payouts & solvency

9.1 — The payout waterfall

Payouts are delivered in $FIRMA (never minted; always bought or drawn from reserve). The firm never refuses a payout — over-cap and Critical-tier payouts queue and auto-release.

9.2 — The SOL coverage overlay

The treasury holds SOL but obligations are USD-pegged: a SOL price drop can leave the treasury short of what it owes. The ARE addresses this with a volatility-coverage rule: it requires the treasury to hold requiredCoverageRatio(vol) × outstanding_USD_owed, with the ratio rising with realized SOL volatility. As coverage thins, daily and weekly payout caps throttle proportionally; at the emergency floor, new eval sales pause (pauseSalesForSolvency) until coverage recovers. The backstop pool provides tail coverage.

9.3 — Why insolvency is engineered out

• Solvency-first reserves from day one. 20% of supply is minted straight into the Tier-2 $FIRMA reserve at deploy; the 1% $FIRMA buy-back leg continuously builds that inventory; insurance accumulates at 2% per eval; and a protocol-wide Universal Treasury Pool (1% of every eval + 3% of every deploy, across all firms) backs the final tier.
• The ARE as a homeostat. As a firm's obligations rise against its treasury (the obligationCoverage sensor, the heaviest of the eight at weight 33), the ARE tightens challenge rules, reduces payout caps, and queues payouts — converting stress into tightening, not collapse.
• Sales never halt. Lever 6 (availability) is always "open." Incoming fees are the recovery mechanism for a stressed treasury.
• No inflation. Every payout sources real $FIRMA through the waterfall. The firm never mints to cover obligations.
• Clean wind-down gate. A firm cannot close while it owes a queued payout. Bankruptcy claws back unvested owner fees first.

9.4 — What stops a run on the backstop

Tier 3 only works if the capital is there when Tier 1 and Tier 2 aren't. Backstop stake is real payout collateral, so the one failure mode that would hollow it out is the ordinary one: stakers reading stress correctly and leaving first. A pool that can be emptied in an afternoon is not collateral, it is a promise with extra steps.

Four controls bound the exit, and none of them lock capital indefinitely — they bound how fast it can move:

• Cooldowns scale with firm health. A firm under stress imposes a longer mandatory cooldown before a matured position can be withdrawn — exactly when the incentive to run is strongest.
• Cooldowns scale with position size. Holding a large share of the pool means a longer wait than holding a small one, so a single dominant staker cannot remove a meaningful fraction of a firm's payout collateral in one move.
• A daily cap limits aggregate outflow. No more than a set share of the pool may leave across all stakers combined on a given day, however many requests are queued.
• Withdrawals freeze during a firm-wide stress event — the same circuit breaker that throttles trader payouts also halts backstop exits, so stakers cannot outrun the traders whose payouts their capital underwrites.

The asymmetry is deliberate. Backstop stakers earn the 8% premium leg precisely because this capital carries real downside; the controls make sure the downside cannot be dodged at the moment it becomes real.

9.5 — Account sizes unlock from liquidity, not from a plan

Which account sizes a firm may sell is a solvency rail rather than a packaging decision. Every firm ships the full ladder automatically, and each size unlocks as the firm's combined liquidity grows, so a firm never sells an evaluation whose eventual funded-payout exposure it could not cover.

Combined liquidity is the same figure the public solvency endpoint publishes: treasury SOL plus the $FIRMA reserve plus backstop stake plus the firm's claim on the shared pool — the four tiers of the waterfall, counted once. The deployment tier an operator paid for sets their fee share and features; it does not buy the right to sell a larger account. Enforcement is server-side at purchase, and each size's availability tracks live liquidity in both directions, so a size that unlocks on a rising treasury pauses again if that treasury falls.

10 · The Autonomous Risk Engine (ARE)

Where a normal firm has risk managers making discretionary calls — which is another thing to trust — DecentralProp has the ARE: a closed-loop control system that reads each firm's live signals and sets its risk posture automatically, every ~15 minutes, with no human in the loop.

10.1 — Hard invariants

• House-edge floor (HOUSE_EDGE_FLOOR = 1.08). The ARE never offers zero-edge or trader-favorable terms. At Trusted tier, where every lever delta is zero, the ARE injects a minimum execution spread to maintain structural positive edge.
• Difficulty ceiling (DIFFICULTY_CEILING = 3.5). Evaluations always stay winnable. Stacked levers are proportionally scaled down when combined difficulty load exceeds 3.5× — so Critical tier is challenging but never statistically unwinnable.
• Sales never halt. Lever 6 (availability) is always "open." A sales halt starves the very treasury you're protecting. The solvency control is the payout circuit breaker, not a sales halt.
• Earned payouts never cancelled. Over-cap payouts queue and auto-release — they are never refused.

10B · The Integrity Engine

The same published flags, under the same published posture, always produce the same enforcement action — and anyone can recompute it. Fraud defense is autonomous, deterministic, and verifiable, not a human moderator's judgment call.

The ARE manages a firm's financial risk; the Integrity Engine manages its behavioral risk — collusion, copy-trading rings, multi-account farming, and evaluation gaming. It runs autonomously alongside the ARE, scoring traders from on-chain and behavioral signals and escalating its own strictness as gaming pressure rises. Its hardest design requirement is the one that breaks naive fraud detectors: it must catch coordinated cheaters without ever punishing a legitimate trader who simply trades at several firms or from several devices.

10B.1 — Advisory detectors & the conjunction gate

A naive cross-firm detector flags any wallet active at multiple firms — and immediately punishes the most valuable honest traders. The Integrity Engine solves this structurally by splitting its detectors into two classes:

• Behavioral flags (gaming evidence): copy-trade similarity, hold-time violations, account-symmetry / pattern-matching. These describe how an account trades.
• Advisory flags (association signals): cross-firm correlation, device-cluster, IP-velocity, multi-account. These describe who an account is near.

The key rule — the conjunction gate: an advisory flag scores 0 on its own. It only contributes to an enforcement score when a behavioral gaming flag co-fires. The result is a clean separation:

This is reinforced by a cross-firm beneficial-owner graph (a tiered union-find over shared funding wallets, devices, and behavioral fingerprints) and a calibrated copy-trade detector (similarity + lead-lag + a null-model false-positive bound + the conjunction gate), so coordinated rings spanning multiple firms are visible even though each firm in isolation is blind to them.

10B.2 — Four self-escalating postures

Like the ARE, the Integrity Engine is autonomous: it raises and lowers its own strictness based on measured gaming pressure (the behavioral-flag rate, with advisory flags excluded so legitimate multi-firm activity can never trigger an escalation). It escalates fast and relaxes slow (3-sweep hysteresis), and every posture is bounded so it can never become unwinnable for honest traders.

At gaming ≥ 30% the engine autonomously reaches STRICT within two to three 15-minute sweeps and holds there until pressure subsides. STRICT's higher false-positive rate (1.84% vs. 0.07% at STANDARD) is a deliberate trade-off — it tightens the HIGH band and catches a few legitimate "consistent algo" / "active scalper" patterns. Every false-positive enforcement is bounded to 7 days by an auto-revoke system, so an honest trader caught in a strict sweep is automatically released; persistent gaming is simply re-detected on the next sweep.

10B.3 — Verifiable enforcement

Every enforcement action (WARN / RESTRICT / PAYOUT_HOLD / FREEZE / BAN) is stored with the exact flags and posture that produced it. Anyone can call GET /api/integrity/proof/:actionId to recompute the action from its public inputs and confirm it matches what was executed — without accessing any trader PII. Enforcement is therefore deterministic and non-discretionary: no admin decides whether to escalate a flag, and the proof of every action is publicly recomputable. Frozen funds are held, not seized — auto-freezes are bounded (a 7-day expiry that auto-revokes) rather than confiscatory.

10B.4 — Wallet Standing: reputation as a payout rail

The integrity engine decides whether behaviour is abusive. Wallet Standing answers a narrower and more continuous question: how much should this wallet be trusted with, right now. It is a per-wallet reputation that moves with observed history and feeds the payout path directly rather than producing a score nobody acts on.

Standing scales six gates. The load-bearing two are a single-payout cap and a rolling withdrawal allowance: rather than refusing any request that lands inside a cooldown window, a wallet clears as many requests as fit under its allowance with no wait, and only the request that exhausts the allowance is capped, carried forward, and starts the cooldown. The remaining four are upside — payout speed, queue priority, size access, and points and badge multipliers — so standing is a ladder a trader climbs, not only a penalty box.

This matters most against the hedge geometry described in Appendix E.1. Standing acts on the payout after a win is banked, which bounds the rate at which a coordinated ring can extract value but cannot make a hedged pair unprofitable on its own. It is the interim mitigation, deliberately chosen over reinstating the blunt evaluation-geometry tax, and it is not a substitute for the structural per-owner cap that remains unbuilt.

11 · Tokenomics — $FIRMA & $DPROP

Tokens sit downstream of the fee economy and are fed by it — they can only add value to a firm's funding model, never compete with it. Every speculative dollar on $FIRMA pays 0.5% into the treasury that backs payouts. Contrast with emission-driven tokenomics where the token is the product and competes with the business.

11.1 — Staking

Normal staking (no loss risk)

Holders stake $FIRMA into the normal pool. They earn two yields: SOL yield funded by the 5% normal-staking leg of every eval fee (distribute_staking_usdc → claim_staking_yield); and $FIRMA yield — the stakeholder share of payouts routed into the reward vault (sync_firma_yield). Unstake anytime. No loss risk — this pool only receives rewards, never absorbs losses.

Backstop staking (higher yield, real downside)

Investors stake $FIRMA into the backstop escrow (stake_backstop). They earn the 8% backstop-premium leg of every eval fee. The risk: when draw_backstop fires (Tier-3 emergency payout), staked capital is drawn to pay the trader and the loss is mutualized across all backstop stakers via loss_acc. Higher yield, real downside — this is the capital that absorbs tail losses so the firm stays solvent.

Staker perks

• Daily Evaluation Giveaway. Each firm runs one provably-fair daily draw that awards a free evaluation ($1k–$25k ladder, treasury-gated by size). Winners drawn by diminishing-weight lottery (weight = stake^0.5) — more stake = better odds, with strong diminishing returns so whales can't monopolize it.
• Comeback Discount. A discount on re-buy after a setback, delivered via the breach-triggered reward-wheel spin.

11.2 — $DPROP design principles

Five principles drive every $DPROP tokenomics decision:

1. Real yield, not emissions. $DPROP has no inflation and no staking-emission printer. Its only value engine is a buy-and-burn fed by actual protocol revenue (SOL). Holders are paid in scarcity, funded by usage.
2. Fair, usage-weighted distribution. The largest single allocation is a usage airdrop earned at 1 pt/$1 of real evaluation spend. It cannot be farmed with simulated volume — because the protocol is a simulation, and volume is free to manufacture (§11.3). Every point costs real SOL.
3. Convergent incentives. Every $DPROP staker is incentivized to grow eval volume (more firms → more fees → more SOL yield); every operator is incentivized to drive trader volume (more evals → more owner fee → more curve depth → more $DPROP burned). No party is incentivized to defect.
4. No token needed to use the protocol. A trader buys an eval in SOL, trades, passes, and is paid in $FIRMA — without ever touching $DPROP. The token captures the protocol's upside without being a tax on using it.
5. Honest residual uncertainty. The $DPROP supply % allocated to the airdrop and the claim mechanism are not yet decided — and this paper says so. Undecided parameters are marked proposed; when chosen they will be documented in the economics source-of-truth in the same change.

11.3 — Airdrop anti-farming

Every evaluation is a simulated trading account, so simulated volume is free to fabricate — a single wallet could "trade" $100M and own the airdrop if points tracked volume. They don't. Points are anchored to the USD value of real evaluation fees paid (verified PAID on-chain). A simulated win is free; a real eval purchase costs real SOL — so the distribution lands with real users, not bots.

Accrual runs through a single choke point at purchase time, guarded by a (purchaseId, source) uniqueness constraint — a re-fired call can never double-count. An audit ledger records the USD anchor and purchase behind every point, so the whole distribution is independently auditable. Every airdrop point is backed by a real dollar that someone really spent.

11.4 — Engagement points, and the two ceilings that bound them

The rule above has an obvious cost: a distribution anchored entirely to spend can only ever reach people who have already spent. Engagement points are the one earning path that does not require buying anything, and the whole design problem is letting them exist without reopening the farm the previous section closed.

A trader connects their X account to the protocol and acts through it: like, repost, quote, reply, and a one-time follow of their firm's account and the protocol's. The action is performed by the protocol on the trader's behalf against the X API, so what is recorded is an action that happened, not a screenshot of one. Rates are deliberately small, and the largest award is the one that cannot repeat.

Rates alone do not bound anything, so two independent ceilings do. Neither is a fraud detector; both are arithmetic that holds whether or not anyone is caught.

• The ratio bounds one wallet. SOCIAL_POINTS_CAP_RATIO = 0.5: engagement points count toward a wallet's total only up to half that wallet's own purchase points. $200 of real spend admits at most 100 engagement points. It is measured against purchase points alone and never against the running total, because referral credit comes out of someone else's spend and counting it would rebuild the farm one level up. Points earned above the ceiling are not deleted — they sit locked in the ledger and are admitted, oldest first, as the ceiling rises with further spend.
• The pool bounds the total. The ratio bounds a wallet; it does not bound a protocol whose wallet count grows. Each firm gets a monthly pool for engagement on its own posts, scaled by deploy tier (5,000 / 10,000 / 20,000 / 30,000 / 60,000 from Starter to Enterprise), and the protocol's own account gets 50,000, since a protocol post reaches every trader rather than one firm's roster. The allowance is stored per month rather than read as a constant, so raising it cannot retroactively rewrite a month already under way, and there is no rollover.

The two ceilings are not the same size, and which one binds is worth stating rather than discovering. Issuable per month is sum(each firm's tier allowance) + 50,000, which at the current mix averages out near N_firms × 10,000; unlockable per month is half the month's purchase points, which is half the month's evaluation-fee revenue. At two dozen firms the pools only become the binding constraint once monthly evaluation fees pass roughly $580,000. Below that the ratio binds first, and the surplus engagement points stay permanently locked: issued, visible in the ledger, never counted, never diluting anyone's allocation. Whether firms may buy additional allowance is an open decision, and the reason it is still open is that an allowance a firm can mint is a token pre-sale wearing a marketing costume, while one drawn from a fixed pre-allocated slice is a bounded distribution right.

12 · The bonding curve & graduation

12.1 — Constant-product curve mechanics

Each firm's $FIRMA token trades on its own constant-product curve (x·y=k) in the bonding_curve program. Fixed supply (mint authority revoked at deploy). Buys push price up, sells push it down. Every curve trade (payout buys, buy-back cranks, speculation) pays a 1% fee split 50/50: 0.5% → firm treasury (firm_fees_accrued), 0.5% → DecentralProp.

12.2 — Deploy self-purchase reserve

On deploy, the firm buys a significant portion of its own coin:

• Treasury reserve (~20% of supply) is minted directly into the treasury_firma_vault (Tier-2 payout reserve) by distribute_supply — slippage-free payout inventory from block one, and it costs the deployment fee nothing.
• Owner-drip (~5% → ~10% of supply) vests to the firm owner over time — aligning the operator's interest with the token's long-term health.

12B · Trader-outcome prediction markets

Each firm can open a binary market on whether a given evaluation account passes or fails, settled off the same on-chain AccountPassed/AccountFailed signal that drives everything else. It exists because a firm's most interesting public data — who is close to passing, who is drawing down — is already published by the transparency layer, and a market is the honest way to price it.

The feature creates a fresh incentive on exactly the surface the integrity engine spends most of its effort defending, so it ships with two structural defences rather than a policy:

• A self-bet ban. A trader, and any wallet trustlessly linked to them — same person, shared funding wallet, or one directly referred the other — is hard-blocked from betting on that trader's own market. A trader paid for their own failure is the one position this market must never be able to take.
• A held win-cut. The trader's share of market rake sits held for 72 hours after settlement and is re-checked against enforcement state at release by its own keeper, rather than paying instantly. This is the market's rake, deliberately kept independent of the evaluation profit-split so it does not reopen the separate question of how funded profits vest.

The current design replaces an earlier parimutuel, custodially-settled version with pooled community liquidity and fully on-chain per-market AMM curves, so positions price continuously and settlement needs no trusted operator. The liquidity pool mirrors the backstop pool's structure, which means its withdrawal controls inherit the same anti-run reasoning as §9.4.

12C · Weekly competitions

An evaluation asks a trader to risk $50 on their own discipline before they have any reason to trust the firm holding it. A competition asks for less and answers the same question: it is a one-week profit contest on a $100,000 simulated account with the standard drawdown limits and no profit target, entered for a small fee, and the traders who finish ahead leave holding evaluations.

The contest belongs to the protocol rather than to any firm. A reserved tenant hosts it, and everything that would make that tenant read as a firm is withheld: it has no on-chain firm account, no token, no products, and no giveaway, so it cannot appear in the firm directory, cannot be picked as a prize venue, and cannot win its own prizes. Entrants trade it in the protocol's own terminal, which opens only while an entry is live.

The pool is accrued, never guaranteed. It opens at zero and grows only as entries sell, so a week nobody enters costs the protocol nothing and owes nobody anything. That also makes "up to 25 winners" a ceiling rather than a promise: the allocator works down from first place and stops when the budget is spent, which twenty entrants exhaust quickly and four hundred do not exhaust at all.

Four rules govern where those evaluations land, and each exists to stop the prize becoming a way around something the protocol already enforces.

• A prize can only be issued where it could have been sold. The allocator reads the same treasury ladder that gates what a firm is allowed to offer, so a $1M account can only be won at a firm deep enough to sell one. A test asserts the two tables match rung for rung, because a prize that skipped the ladder would be a loophole in the solvency rail rather than a marketing expense.
• Prizes spread rather than concentrate. Each award goes to the eligible firm carrying the fewest so far, ties broken by treasury depth. Twenty-five funded-track traders arriving at one firm in one afternoon is a liability that firm never planned for.
• Below the podium there is a performance bar — 10% on the account, inclusive. The top three are exempt: placing is the qualification.
• An award freezes at settlement. Firm, size, cost and terms are written onto the entry when the week closes, so a treasury dipping over the weekend cannot retroactively change what a winner was told they had won. When a preferred size is unaffordable the allocator steps down the ladder rather than skipping the winner.

A prize evaluation is not a comped account. The winner signs the purchase and the prize wallet signs and funds the fee in the same transaction, so the entire fee split runs: treasury credit, owner vesting, backstop premium, affiliate carve, curve buy-back, protocol legs. On-chain it is indistinguishable from an evaluation the trader bought, which means everything in §8 and §9 applies to it unchanged — including the part where the firm that issued it now has a real obligation it was paid for.

Three bounds keep the contest from becoming its own farm: one prize per person per week, a minimum number of closed trades so a single maximum-leverage coin-flip held to the bell is not a strategy, and a requirement that a winner actually finished profitable. A losing week pays nobody rather than rewarding the least-bad blow-up, and an unawarded tier is reported as unawarded rather than redistributed, so "first place pays 50%" stays literally true.

Competition accounts sit outside the risk machinery entirely. They cannot become funded, cannot create a payout request, and never acquire an on-chain challenge account, so no fee leg, treasury, curve or backstop is touched by the contest itself. They are also excluded from every firm-health signal the risk engine reads, for a reason worth stating: maximum-variance trading is the correct strategy in a profit contest, and feeding that behaviour into an engine that reads variance as risk would teach it something false about a firm that is fine.

13 · The ten flywheels

The protocol's economics form ten mutually reinforcing loops. Each input drives a loop that strengthens the output — and the outputs become inputs to other loops. The first nine operate within and across firms; the tenth is the one isolated firms structurally cannot have — the protocol gets stronger with scale.

13B · Protocol launch sequence

The strongest critique of any new token is "raise, hype, dump — before the product exists." DecentralProp inverts the sequence: the product generates real on-chain revenue before the token launches publicly. Each step gates the next.

The $DPROP launch is a load-bearing sequence — each step funds and validates the one after it. No step can be skipped.

The discipline is the point: no whitelist without a compelling project, no investor round without a live firm proving the economics, no public launch without the on-chain track record that makes the valuation credible.

14 · Governance, upgradeability & roadmap

14.1 — Parameter control today

Protocol constants (*_BPS values, thresholds, caps, tier bands) are currently hard-coded in the Anchor programs. The deployer key is the only upgrade authority — maximum centralization, consistent with pre-mainnet status. There is no token governance over parameters today.

14.1b — Feature gates: taking a product area dark

Parameters decide how a feature behaves. A separate control decides whether it exists at all. Each of the protocol's optional product areas — prediction markets, the Telegram surface, the on-platform games — carries a platform gate with three states: on, off, or pilot, where pilot means a named set of firms and nobody else. This is a different axis from the per-firm entitlement flags, which decide what a given firm may switch on for itself; a shut gate overrides every one of them at once.

Three properties make the gate worth documenting rather than treating as an internal switch:

• It fails to the last known-good state, not to the compiled default. The defaults are all "on", so a database blip that fell back to them would silently re-open a gate someone had deliberately closed.
• It fails closed at the boundary. A gated route refuses every method and answers as though it does not exist, rather than explaining what is being withheld. Ingress is gated at each entry point rather than only at the HTTP layer, because a Telegram bot that also long-polls has a path with no HTTP route to guard.
• It is a hard stop with no drain. Closing a gate parks whatever is open — live markets, pending bets, unresolved rounds, unswept fees — until it reopens. The control surface shows those in-flight counts before the flip, so nobody closes a gate without seeing what is standing behind it.

One limit is disclosed rather than papered over: transactions a browser builds and a user signs go to the program regardless of the gate, because the gate lives in the gateway and the program does not know it exists. Closing that gap needs a pause flag on-chain, and until it exists a gate should be read as "the protocol has stopped operating this surface", not "the instructions are unreachable".

14.2 — The upgrade-authority roadmap

14.3 — Live vs. planned ledger

15 · Security

Audit status

The programs are not yet audited by an independent third party. They are cargo-green and extensively simulation/unit-tested (44/44 workspace tests; 300-firm, 540-day Monte Carlo). An independent Solana security audit (OtterSec or Neodyme, estimated $80k–$150k) is planned before any mainnet value is held. The planned sequence: freeze programs → public devnet bug bounty → audit → fix all critical findings → re-audit → mainnet. The landing page's "Audited programs" language should be read as aspirational until this step completes.

Oracle dependency & failure modes

Prices come from Pyth via Hermes. The ARE's marketVolatility sensor (weight 3) consumes Pyth confidence intervals. Fill freshness is bounded by the maxPriceAgeSeconds lever (Trusted: 10s → Critical: 5s) — ticks older than the bound are rejected, so a stale feed cannot be used to manufacture a fill. On feed outage or wide confidence: the engine degrades to no-new-fills rather than mispriced fills. Settlement transcripts only contain attested prices.

Keeper liveness

The critical keeper roles (prove_*_fault, finalize_settlement, slash_settlement_fault, execute_dprop_buyback, burn_dprop_buyback, declare_bankruptcy) are permissionless — anyone can advance these states. The money-movement destinations are program-enforced; keepers only provide liveness, and the critical ones are not DP-dependent.

16 · Why Solana

• Throughput and cost. 65,000+ TPS, sub-cent transaction fees — making per-evaluation on-chain fee splits, per-account PDA lifecycle, and hourly Merkle root commits economically viable at scale.
• Pyth oracle. Pyth is native to Solana with sub-second confidence-interval data, a natural fit for the execution engine's freshness requirements and the ARE's volatility sensor.
• Raydium AMM. The graduation milestone migrates each firm's liquidity to Raydium — the deepest Solana DEX — giving every graduated $FIRMA token real, permissionless secondary market liquidity.
• Anchor. Solana's dominant smart-contract framework, with strong type safety, CPI support, and a mature testing ecosystem — enabling the five-program composition the protocol requires.
• Chain-boundary discipline. The codebase enforces a hard boundary between chain-neutral business logic and Solana-specific SDK calls. Multi-chain support is a contained job: replace the seam layer, not the business logic — §16.1 is that job, already done once.

16.1 — Chains as plugins: the DecentralChain proof

Only the five on-chain programs in §4.1 are Solana-specific. SimCore, the Autonomous Risk Engine, the Integrity Engine, and the full keeper fleet that governs a firm never call a Solana SDK — the chain-boundary discipline above means they don't have to. The protocol's architecture reflects that split directly: a firm deploys against a chain adapter, one interface that knows how to deploy a treasury, price an evaluation, settle a result, and deliver a payout on a specific chain. Solana's adapter wraps the original five programs unchanged. Any other chain is a new implementation of the same interface, and nothing above that line has to change to use it.

DecentralChain (DCC), a RIDE/Waves-family layer-1, is the first chain to prove this pattern besides Solana. On 2026-08-26, the full loop ran for real on DecentralChain's own mainnet: a firm deployed, an evaluation was purchased against it, the evaluation settled, and the payout delivered through the same multi-way stakeholder split the protocol runs on Solana — every step independently re-checked against DecentralChain's own chain state afterward, not only against the tooling that ran it. This is the first time DecentralProp's core loop has completed on a chain other than Solana.

The cost of that proof is a real, bounded number, not an open-ended rewrite: the five programs are roughly 22,500 lines of Rust, and porting them is the entire per-chain expense. Everything above the money layer inherits the new chain for free, the same day its adapter lands.

16.2 — Two custody models, one guarantee

The protocol's first trust layer (§6.1) rests on a single primitive: an account that holds funds but that no human can unilaterally drain. Everything else — the payout waterfall, the fraud window, the operator bond — assumes it. Porting to a second chain therefore meant reproducing that primitive on a virtual machine that has no notion of a Solana program-derived address, and the result is worth setting out because the two chains reach the same guarantee by opposite routes.

On Solana, a normal address is a public key: a point on the ed25519 curve with a corresponding private key. A program-derived address is constructed to fall deliberately off that curve, so no private key exists for it at all. Only the owning program can authorise movement, through invoke_signed. Custody is guaranteed by elliptic-curve mathematics.

On DecentralChain, the equivalent is an account-level script. A RIDE @Verifier decides whether a transaction sent from that account is admissible, and @Verifier(tx) func verify() = false refuses every one of them, permanently. A private key for the account does exist, but consensus declines everything it signs, so it is inert. Callable functions are governed separately and still execute, which is how funds move: only through contract logic, never through a signature. Custody is guaranteed by consensus rule rather than by curve geometry, and in practice the two are equally binding.

The asymmetry favours the second model in one specific respect. A program-derived address is keyless, but the program that governs it is upgradeable by default, so permanence is a separate discipline requiring its own multisig-then-timelock-then-revoke roadmap (§14.2). A false verifier delivers both properties from one mechanism: replacing an account's script requires a SetScriptTransaction sent from that account, which the verifier refuses, so the contract is frozen the instant it lands. Keylessness and immutability arrive together rather than in sequence.

That permanence is a liability as much as an asset, since a defect in a frozen contract can never be patched, and the DecentralChain deployment is shaped around that fact. FirmVault holds the money behind the immutable verifier and exposes exactly one callable, gated to a single caller: if (i.caller != registryAddress()) then throw("only the bound registry may move vault funds"). FirmRegistry holds every non-trivial rule and sits behind a 2-of-3 multisig verifier that admits SetScriptTransaction and nothing else — the direct analogue of a Solana upgrade authority under Squads. Irreversibility is applied only to the component small enough to verify by reading it; everything complicated enough to contain a bug stays governable.

The same guarantee, reached two different ways, on two virtual machines with nothing in common. That is the strongest available evidence that the plugin boundary in §16.1 was drawn in the right place: what crosses it is a property the protocol depends on, not an implementation detail it happened to inherit from Solana.

17 · Conclusion

DecentralProp takes the one component that is unavoidably off-chain — a realistic trading simulation — and wraps it in seven layers of on-chain commitment, public proof, economic incentive, and independent verification so that the people running it cannot make it lie.

Money cannot be printed or over-paid. Prices, trades, and starting balances are bound to committed, signed evidence. Results must survive a public fraud-proof window before a single token moves. Any lie is provable by anyone and punished by a slashed bond. Insiders cannot drain funds even with the firm's keys. And the whole economy — fees, treasury, token, payouts — runs itself through an autonomous risk engine and a self-sustaining set of reinforcing flywheels.

But the deeper claim is organizational, not just cryptographic. DecentralProp does not merely make a prop firm auditable — it removes the operating company itself. One brain, thousands of brands. The operator launches a brand; the protocol runs the business. No employee approves or denies anything — and if no human approved it, the protocol did. The network, not any company, becomes the operating entity, and it grows stronger with every firm that joins it.

This is the goal stated plainly: a perfect-information, self-sustaining funding protocol where trust is replaced by verification, from end to end — including over its own creators. Check us; don't trust us.

The funded-trader industry has proven the demand. DecentralProp provides the trust — and a new kind of company to deliver it. Together, they form a new DeFi category.

Appendix A · Protocol constants

Every figure in this paper traces to an on-chain constant. Source: onchain/programs/firm/src/lib.rs, bonding_curve/src/lib.rs, challenge/src/lib.rs, dispute/src/lib.rs. Last verified: 2026-06-30 against compute_fee_split / compute_deployment_fee_split and MONEY_FLOW.md.

Appendix B · Operator threat model

Appendix C · Glossary

Appendix D · Comparison matrix

Appendix E · Simulation methodology & results

Methodology

The ARE simulation suite (packages/are/sim/) drives the real @decentralprop/are engine against a Monte Carlo population of simulated firms and trader cohorts. Configuration: 300 firms, 540 days (18 months), 14 market scenarios. Variables are time-varying with correlated AR(1) volatility regimes, systemic shock events, population skill drift, and affiliate-rate variation.

Key findings: 100% solvency in all 14 scenarios. House edge positive in every scenario — 31–40% in normal/stress regimes, 1.5–2.9% in adversarial. ARE is homeostatic: sensors and hysteresis outperform any manual lever tuning. Best eval price ≈ 1.25× break-even anchor (payout-flow gate is the binding constraint, not price itself). Pass rate ~9.5% at Standard tier. The velocity breaker and 25/48/68 band tightening were the highest-impact single changes.

E.1 — What the calibrated re-run changed

Everything above was measured against a synthetic trader population. In July 2026 the same ARE pipeline was re-run against a population calibrated to a real operating firm's observed funnel — its measured pass rate and its measured rate of traders washing out before ever reaching a payout — rather than to modelled assumptions. The headline numbers move, and they move in one direction.

The baseline firm stays solvent under the calibrated population, and roughly half the modelled margin does not survive contact with a real funnel. The adversarial arm is the finding that matters: if a firm's population drifts toward skilled traders and whales while its per-archetype rates hold, the model shows real insolvency risk rather than a thinner cushion. The sample behind the calibration is small (95% CI ≈24–39% on pass rate, ≈58–84% on wash rate), and funded accounts take months to resolve, so an operating firm's first weeks of apparent health are weak evidence either way.

One structural caveat belongs next to these numbers. The evaluation geometry currently sets the profit target below the maximum drawdown, which makes a two-account hedge viable: a hedged pair's winner can pass while its loser is still alive. A geometry change that closed this was built and then deliberately reverted, because it taxed honest traders to price a small number of gamers; the structural replacement — per-owner detection acting on the beneficial-owner graph — is specified and not yet built. Until it ships, the production cost of a funded account is closer to one evaluation than to the several the solvency model assumes. This is a known, deliberate open position, not an oversight, and it is the single assumption most worth re-testing before trusting the margin above.

E.2 — ARE adversarial full-spectrum simulation

A second, deeper study drove the real ARE engine (zero stubs, seeded PRNG) through 12 adversarial phases — each designed to break a specific mechanism — followed by a 500-run Monte Carlo over 12 months comparing ARE ON vs. ARE OFF. Phases included scoring edge cases (25 pathological inputs), tier-boundary gaming, velocity-breaker precision, an oscillation attack, a payout spiral, a 42-combination SOL solvency stress, a 24-firm market shock (−35% SOL gap), a concentration bomb, and a 7-vector "perfect storm."

The headline is not "the ARE prevents insolvency" (100% solvency occurs in both conditions with a well-structured firm). It is that with identical fee/payout ratios, the ARE keeps 1.44× more capital on the balance sheet and serves payouts 7.7× more reliably — because it tightens before the treasury bleeds, not after. The single most important finding: the 7-vector perfect storm (pass-rate spike, treasury drain, SOL crash, thin LP, concentration bomb, demand surge, vol spike, staggered over six hours) peaked at composite score 64.5 (Warning) and never reached Critical — the layered lever response absorbed all seven vectors without cascading.

Honest limitation: an adversarial operator who reads the score each sweep and injects 15% treasury whenever the score nears a tier boundary can suppress escalation for up to ~28 days. This is documented and mitigated by the facts that suppression costs real capital, the underlying exposure accumulates anyway, and a time-averaged (EMA) treasury input would reduce susceptibility.

E.3 — Integrity Engine full-spectrum adversarial simulation

The integrity simulation swept gaming prevalence from 10% → 90% across 9 scenarios (20,000 traders each, 12 autonomous posture sweeps per scenario), with populations generated from 14 adversarial and 8 legitimate archetypes. Additional phases: a ring-penetration test (sizes 3–10 across 2–4 firms), a 10,000-pair copy-trade null-model test, an advisory-gate isolation test, and an escalating-attack stress test.

The decisive design property: the 0% legitimate-multi-firm false-positive rate is structural, not tuned — it follows from the conjunction gate (§10B.1), which scores advisory association flags at 0 unless a behavioral gaming flag co-fires. It holds regardless of posture level, gaming rate, or how many advisory flags a legitimate trader accumulates. All ring configurations were caught at 100% in the first sweep because a coordinated ring cannot avoid exhibiting behavioral symmetry while also tripping the cross-firm advisory.

Appendix F · Legal disclaimers & risk factors

General disclaimer

This whitepaper is for informational purposes only. Nothing herein constitutes financial advice, investment advice, trading advice, or any other sort of advice. DecentralProp makes no representation or warranty regarding the accuracy, completeness, or currentness of any information contained herein. All information is provided "as is." Forward-looking statements throughout this document reflect the team's current expectations and beliefs, not certainties. Actual results may differ materially.

Nature of the product

DecentralProp is a skill-evaluation and funding protocol. Payouts to traders are profit-shares on simulated funded accounts based on demonstrated trading performance — they are not returns on a passive investment or financial product. Participation requires active trading skill. The simulation environment does not guarantee results replicable in live markets.

Token posture

$FIRMA: A per-firm utility token with fixed supply, fed by protocol fee flows, and used as the payout and staking medium within a specific firm's ecosystem. $DPROP: A protocol-level token accruing value through buy-and-burn sinks fed by real protocol usage, with planned airdrop distribution to verified real-money participants. Nothing in this document should be construed as a promise of profit from holding either token. Both tokens carry the risk factors of all crypto assets.

Risk factors

• Smart-contract risk. Programs are unaudited by independent third parties as of this paper's date. Bugs in the on-chain code could result in loss of funds.
• Upgrade authority risk. Until the upgrade-authority migration to multisig + timelock + revoke is complete, the deployer key could theoretically ship a malicious upgrade. See §6.8 and §14.2 for the committed migration path.
• Oracle dependency. The protocol relies on Pyth for price data. Oracle manipulation, outages, or excessive confidence intervals could adversely affect fill pricing and settlement.
• Watchtower liveness. Fraud proofs require an active watcher during the 72-hour settlement window. If no watcher is active, a dishonest settlement could finalize.
• Token price volatility. $FIRMA and $DPROP are highly volatile assets. Payouts denominated in $FIRMA may lose value relative to USD between receipt and sale.
• Backstop staker loss. Investors in the backstop staking pool bear real loss risk: their capital can be drawn to cover funded-account payouts in emergency scenarios.
• SOL price risk. The treasury holds SOL against USD-pegged obligations. A significant SOL price decline could impair the treasury's coverage ratio, triggering payout throttling or sales pauses.
• Regulatory risk. The legal status of funded-trader protocols, their associated tokens, and blockchain-based financial products varies by jurisdiction and is evolving. Participation may be restricted or prohibited in certain jurisdictions.
• Raydium/graduation dependency. Post-graduation $FIRMA liquidity depends on Raydium's continued operation and the successful execution of Phase 4.4 (planned, not yet built).
• Protocol immaturity. The protocol is pre-mainnet with a single deployer key and unaudited programs. All figures and simulations are based on modeled and tested behavior, not live mainnet history.

Potential participants should conduct their own due diligence and consult qualified legal, tax, and financial advisors before participating. This document does not constitute an offer to sell securities in any jurisdiction.