CROWNRIDGE
--:--:--Z
CROWNRIDGE/DOCS/RISK
[RISK]Risk← ALL DOCS

Crownridge Risk Analysis

Read this first.

  • Crownridge is not audited. No external security audit or independent economic review has occurred. An audit is a mandatory pre-mainnet gate (spec §88; founder action list item 9), and it has not happened yet.
  • Crownridge is not deployed to mainnet. Nothing in this repository is live.
  • CRWN is not redeemable and has no guaranteed floor, return, or yield. There is no redemption mechanism in V1. Backing determines NAV; NAV is not a claim you can exercise.
  • The founder holds a real, disclosed authority to withdraw the Treasury reserve (§2 below). Read that section before depositing anything.
  • "USDG ≈ $1" is an assumption, not a guarantee.
  • Crownridge is built on Robinhood Chain. That is a statement about infrastructure. It is not a partnership with, or endorsement by, Robinhood or any affiliate.

Everything in this document traces to the contracts in contracts/src/ or is explicitly labeled as planned/future. Live parameters, addresses, the founder-authority mode, and cumulative founder withdrawals are published on the public transparency page (website: /transparency) once deployed.

This is the honesty document. Every risk below is stated as what happens if it occurs, what the protocol does about it (in code, not intention), and what it cannot do about it.


1. Risk index

# Risk Severity if realized Protocol response
§2 Founder withdraws reserve (disclosed authority) Up to total loss of NAV backing in UNCAPPED mode Disclosure, on-chain events, guardian pause, timelocked revocation
§3 USDG depeg / freeze / issuer failure NAV overstated or reserve inaccessible Pause Genesis, timelocked writeDownRecognized, buyback fails closed
§4 No redemption / market price collapse CRWN market price can go to ~0 regardless of NAV None — by design, NAV is reserve-based and not a floor
§5 DEX liquidity disappears CRWN becomes hard or impossible to sell Buyback fails closed; Genesis/Treasury unaffected
§6 Oracle failure or manipulation Buyback could overpay if unguarded Fails closed: TWAP + cardinality + deviation + accretion checks
§7 Smart-contract exploit Loss of funds in the affected subsystem Immutable core limits blast radius; per-subsystem pause; no audit yet
§8 Admin-key compromise Malicious parameter/role changes 48h timelock + guardian CANCELLER_ROLE veto + narrow role design
§9 Chain/platform failure (Robinhood Chain, Arbitrum Orbit L2) Downtime, reorg, bridge/sequencer risk None at protocol level — inherited platform risk
§10 Regulatory / legal characterization Enforcement, geo-restrictions, forced changes Unreviewed — counsel required before mainnet (founder action item 10)

Severity is stated for the realized scenario, not its probability. No probability estimates are offered; inventing them would be false precision.


2. Founder Treasury withdrawal authority — the primary trust assumption

This is the most important risk in the protocol and it is deliberate, disclosed, and on-chain.

What it is, exactly

FounderTreasuryController.withdraw(recipient, amount) — callable only by the immutable founder address — instructs CrownridgeTreasury.founderWithdraw(asset, recipient, amount) to transfer USDG out of the Treasury. Effect, per Core Invariant 10:

founder withdraws X USDG  →  recognizedReserve ↓ X  →  NAV ↓  →  NAV/CRWN ↓
                             CRWN supply UNCHANGED
                             emits FounderTreasuryWithdrawal(asset, recipient, amount)

The withdrawal reduces the backing of every circulating CRWN immediately. It does not mint, burn, or move CRWN, and it cannot be hidden: the Treasury emits FounderTreasuryWithdrawal, the controller emits FounderWithdrawExecuted, and Treasury.cumulativeFounderWithdrawn is a public counter surfaced on the transparency page and monitored by the indexer's alert rules.

Modes (fixed at deployment, immutable)

Mode Meaning
CAPPED Withdrawals bounded by immutable constructor limits: maxPerWithdrawal, rollingLimit per rollingWindow, minTreasuryFloor (recognized reserve that must remain), and cooldown between withdrawals. withdrawableNow() publishes the current bound.
UNCAPPED The founder can withdraw the entire recognized reserve, at any time, in one transaction. withdrawableNow() returns the full recognized reserve.

The deployed mode and its parameters are published in the deployment manifest and on the transparency page before Genesis opens. If you deposit into an UNCAPPED deployment, you are trusting the founder with the whole reserve. That sentence is the disclosure; do not deposit if you are not prepared to accept it.

What it can NOT do (enforced in code, not policy)

  • Cannot mint CRWN or change supply — the controller has no role on CrownridgeMintController.
  • Cannot withdraw CRWN or protocol liquidity — Treasury.founderWithdraw reverts with UnsupportedAsset for any asset != USDG.
  • Cannot exceed recognized reserve — reverts with InsufficientRecognizedReserve.
  • Cannot make arbitrary calls, delegatecalls, approvals, upgrades, or role changes — the controller contract contains exactly one state-changing external function.
  • Cannot replace itself or the founder address — both are immutable.

Emergency response if the founder key is compromised (or the founder acts maliciously)

  1. Immediate (T+0): the Guardian (security multisig, GUARDIAN_ROLE) calls Treasury.setFounderWithdrawPaused(true). All founder withdrawals stop in that block. This is a safety pause, not an approval gate.
  2. Durable (T+48h): revoking FOUNDER_CONTROLLER_ROLE from the controller is a DEFAULT_ADMIN_ROLE action and therefore goes through the 48h TimelockController. Revocation is not immediate — the immediate lever is the pause; revocation is the follow-up.

Note the residual risk honestly: if the Guardian multisig fails to act (or is itself compromised), nothing else stops an UNCAPPED withdrawal. In CAPPED mode the immutable limits still bind.

What "permanent capital" means — and does not mean

"Permanent capital" describes the vehicle structure: the Treasury has no maturity date, no redemption schedule, and no obligation to return capital on demand — capital is not periodically callable the way a fund's is. It is not a promise that reserves can never leave the Treasury (they can: buybacks, and the founder authority above), and it is not a guaranteed floor under the CRWN price. Anyone using "permanent capital" to imply either of those is misreading the design.


3. USDG reserve risk — depeg, freeze, issuer failure

The entire recognized reserve is one asset: USDG (0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168, 6 decimals, verified on-chain). Robinhood Chain documentation describes USDG as a dollar-backed stablecoin with Paxos as its stablecoin infrastructure provider. Crownridge has no independent claim on USDG's backing and performs no verification of it. This is concentrated, uncompensated issuer/counterparty risk.

What happens if USDG depegs: NAV is denominated in USDG units and assumes USDG ≈ $1. On a depeg, every USD-denominated figure (NAV, NAV/CRWN) is overstated until governance acts. The protocol's accounting does not self-correct.

What happens if USDG is frozen or the Treasury's balance is seized/impaired: the reserve may be unspendable or partially gone while recognizedReserve still reports the old number. The conservation invariant (recognizedReserve ≤ USDG.balanceOf(Treasury), checked by conservationHolds() and re-checked on every recognize()) catches balance reductions: a Genesis deposit that would recognize more than the Treasury actually holds reverts (ConservationViolated), so a failed or impaired transfer can never produce CRWN (Invariant 8).

The write-down path: Treasury.writeDownRecognized(newRecognized, reason) — held by RESERVE_MANAGER_ROLE, i.e. behind the 48h timelock — reduces recognizedReserve to reflect an impairment. It can only decrease the figure (CannotIncrease otherwise) and emits ReserveWrittenDown; there is no code path that inflates NAV. Expected incident sequence: Guardian pauses Genesis immediately (issuing CRWN against an impaired reserve at the old rate would be mispriced) → timelocked write-down → NAV reflects reality. During the ~48h window, published NAV is stale and marked accordingly on the dashboard. Buybacks in a depeg regime fail closed on their own price-sanity checks (§6) and can be paused.

What the protocol cannot do: recover value USDG loses. A write-down is recognition of a loss, not a remedy. If USDG goes to zero, NAV goes to zero.


4. No redemption, no floor — market price vs NAV

Four distinct quantities, never to be conflated:

Term Definition Where computed
Backing Recognized USDG reserve held by the Treasury Treasury.recognizedReserve
NAV Backing normalized to 1e18 USD; liabilities are 0 in V1 Treasury.nav(), CrownridgeAccounting
NAV per CRWN NAV ÷ circulating supply Treasury.navPerToken()
Market price Whatever the Uniswap v3 pool clears at the market, not the protocol

There is no redemption mechanism in V1. No contract lets a holder exchange CRWN for USDG. NAV per CRWN is an accounting quantity, not an exercisable claim, and nothing forces market price toward NAV.

What happens if the market price collapses: NAV does not move — it is reserve-based, not market-based. CRWN can trade at any discount to NAV indefinitely, including approximately zero. The only protocol response is the buyback engine (§6), which is discretionary, executor-triggered, ships disabled, and is hard-capped (per-tx, per-day, and ≤ maxTreasuryBps of the reserve per rolling day — 2% proposed). Buybacks are designed to be accretive to remaining holders, not to defend any price level. They cannot and do not create a floor.

Do not deposit on the theory that NAV is a minimum exit price. It is not.


5. DEX liquidity risk

CRWN's only market is the protocol's Uniswap v3 CRWN/USDG pool (factory 0x1f7d7550B1b028f7571E69A784071F0205FD2EfA, position held by CrownridgeLiquidityManager, full-range in V1), plus any third-party LPs.

What happens if liquidity disappears: CRWN becomes expensive or impossible to sell at any predictable price. Since there is no redemption, DEX liquidity is the only exit; its absence means no exit. The protocol-owned position is not obligated to remain at any depth, and third-party liquidity can leave at will.

Protocol behavior: CrownridgeBuyback refuses to trade into a thin pool (PoolLiquidityTooLow below minPoolLiquidity; CardinalityTooLow below minCardinality), so the Treasury cannot be tricked into buying through an empty book. Genesis and the Treasury are unaffected — backing does not depend on the pool (LP is valued at zero in NAV; pool-held CRWN counts as circulating — both conservative choices that understate rather than flatter NAV/CRWN).


6. Oracle failure and manipulation — why the buyback fails closed

The only oracle in V1 is the Uniswap v3 pool's own TWAP (UniV3TwapLib; no Chainlink dependency — decision D3). A pool TWAP on a small pool is manipulable; the design assumes an adversary will try to make the Treasury overpay for CRWN, and answers by making every doubt a revert:

executeBuyback() reverts unless ALL hold:
  enabled (ships FALSE; enabling is timelocked)     deadline not passed, cooldown elapsed
  observation cardinality ≥ minCardinality (60)     pool.liquidity() ≥ minPoolLiquidity
  TWAP(window=1800s) and spot both nonzero          |spot − TWAP| ≤ maxDeviationBps (200)
  TWAP ≤ NAV/CRWN × (1 − minDiscountBps) (10%)      spend ≤ per-tx, per-day, and ≤2%-of-treasury/day caps
  minOut ≥ max(accretive floor, TWAP − slippage)    POST-SWAP: measured USD paid / measured CRWN received ≤ NAV

The last line is the backstop: accretion is verified on actual balance deltas after the swap (NotAccretive reverts the whole transaction), never on a formula, so even a manipulated price that slipped past every prior check cannot produce a dilutive buy. Parameter bounds in setRiskParams prevent any admin from configuring the guards away (e.g. deviation cap ≤10%, treasury cap ≤10%/day).

What happens if the oracle fails or is manipulated: nothing. The buyback reverts and the Treasury keeps its USDG. The failure mode is a missed buyback, not a drained reserve. No other subsystem consumes the price — Genesis mints at a fixed rate and NAV never reads the market.


7. Smart-contract risk

Crownridge has not been audited. The code has 73+ tests (unit, fuzz, invariant, economic-attack, and fork tests against live Robinhood Chain mainnet state), an internal multi-agent adversarial review, and static analysis — none of which substitutes for an independent audit, which is a non-negotiable pre-mainnet gate that has not yet occurred. Until it has, assume residual bugs.

What happens if a contract is exploited: the blast radius is bounded by architecture rather than by upgrade keys, because the reserve has exactly three exits:

                    ┌──────────────────────────────┐
    Genesis ───────►│      CrownridgeTreasury      │
   (deposits)       │   recognizedReserve (USDG)   │
                    └──────┬─────────┬─────────┬───┘
                           │         │         │
              fundBuyback  │  founderWithdraw  │  rescueToken
              (Buyback     │  (Founder-        │  (foreign tokens ONLY —
               contract    │   Controller      │   reverts for USDG/CRWN)
               only)       │   only, §2)       │
                           ▼         ▼         ▼
                    accretive     founder    never the
                    buy + burn    recipient  reserve

There is no withdrawAll, no arbitrary call/delegatecall, no proxy, and no upgrade path (immutable core, D2). A compromise of one subsystem does not automatically reach the others: a Genesis bug cannot move existing reserves (Genesis only deposits and triggers mints, and a mint without a completed reserve transfer reverts); a Buyback bug is capped by the per-day and %-of-treasury spend limits; CrownridgeAccounting is a stateless view lens holding no funds. Unauthorized minting requires compromising CrownridgeMintController's ISSUER_ROLE, held only by Genesis (Invariant 1).

Response levers: Guardian PAUSER_ROLE pauses Genesis, MintController, and Buyback immediately, per subsystem; founderWithdrawPaused stops the founder path. Immutability cuts both ways: a bug in deployed core contracts cannot be patched — only paused around, or abandoned by deploying a successor. CRWN transfers themselves can never be paused or blacklisted (CrownridgeToken is a plain OZ ERC20 + Burnable) — deliberate, and it means a stolen balance cannot be frozen.


8. Admin-key compromise

No single key can move the reserve. The control structure (V1, no token governance):

Holder Power Latency
OZ TimelockController (48h min delay) DEFAULT_ADMIN_ROLE on every contract: roles, parameters, write-downs, sweeps, enabling buybacks ≥48h, publicly visible on-chain during the delay
Protocol multisig Sole proposer to the timelock ≥48h via timelock
Security multisig (Guardian) PAUSER_ROLE (immediate subsystem pause), GUARDIAN_ROLE (immediate founder-withdraw pause), CANCELLER_ROLE on the timelock immediate
Buyback executor (ops) executeBuyback only — every safety check binds on-chain regardless of caller immediate but fully constrained
Founder (immutable address) §2 immediate, within mode
Deployer nothing — the deploy script transfers admin to the timelock and asserts, role-by-role across every contract, that the deployer retains no power

What happens if the protocol multisig is compromised: the attacker can propose malicious operations but must wait 48 hours in public. The Guardian's CANCELLER_ROLE vetoes the queued operation — turning a compromised-proposer drain into a cancellable stalemate (adversarial-review finding C1). What happens if the Guardian is compromised: it can pause subsystems (griefing, availability loss) but holds no path that moves funds; unpausing and role repair run through the timelock. What happens if both multisigs are compromised simultaneously: the timelock delay is the only remaining defense, and after 48h the attacker has admin. Multisig signer hygiene and distinct signer sets are therefore load-bearing operational requirements, outside what code can enforce.


9. Platform risk — Robinhood Chain

Crownridge runs on Robinhood Chain (chainId 4663), an Arbitrum Orbit L2. It inherits that platform's risks wholesale and can mitigate none of them: sequencer downtime or censorship (no transactions — including guardian pauses — while it lasts), the chain's bridge and upgrade/operator trust assumptions, and the canonical-ness of the USDG representation on this chain. A young chain also means a shallower validator/tooling/monitoring ecosystem than Ethereum mainnet. "Built on Robinhood Chain" is an infrastructure statement only — Crownridge is an independent project with no Robinhood partnership, endorsement, or support commitment, and Robinhood owes it nothing.


10. Regulatory and legal risk

The legal characterization of CRWN, the Genesis sale, the founder authority, and the protocol itself has not been reviewed by counsel. Depending on jurisdiction, Genesis may constitute a securities offering; the founder's withdrawal right may carry fiduciary or disclosure obligations beyond this document; marketing language may be regulated; participants may face geographic restrictions or tax consequences. None of this document is legal advice. Independent legal review is a mandatory pre-mainnet founder action (action list item 10) and has not occurred. Regulatory action against USDG/Paxos, Robinhood Chain, or Crownridge itself could impair or end the protocol.


11. Assumptions register

Stated plainly, because NAV and every dashboard figure rest on them:

  1. USDG ≈ $1 — assumption, not guarantee (§3).
  2. USDG remains transferable and unfrozen for the Treasury and depositors (§3).
  3. Robinhood Chain liveness and integrity (§9).
  4. Uniswap v3 contracts on Robinhood Chain behave as the canonical implementation (addresses verified against official docs and on-chain bytecode; behavior not independently audited by us).
  5. Multisig signers are honest, distinct, and available — especially the Guardian, whose availability backs both the founder-pause (§2) and the timelock veto (§8).
  6. OZ Contracts v5.1.0 and Solidity 0.8.30 are sound as used.
  7. Monitoring is running — alerting on FounderTreasuryWithdrawal, unexpected mints, supply mismatches, and treasury outflows is operational, not contractual.

If any assumption fails, the analysis above degrades with it.


12. Related documents

  • Transparency pagewebsite: /transparency: live addresses, founder-authority mode and parameters, cumulativeFounderWithdrawn, reserve and NAV figures, deployment manifest.
  • docs/ECONOMICS.md — issuance, NAV, buyback math, economic failure table (§8).
  • docs/SECURITY.md, docs/INCIDENT_RESPONSE.md — role matrix and emergency procedures (planned; see the build plan in CLAUDE.md P13).
  • contracts/src/ — the code is the authority; where this document and the code disagree, the code is what you are trusting.

Status: pre-audit, pre-mainnet. This document must be re-reviewed after the external audit and before any deployment, and updated with the deployed founder-authority mode and parameters.

F2TREASURYF3TRANSPARENCYF4DOCSF5WHITEPAPERF6STATUS