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.founderWithdrawreverts withUnsupportedAssetfor anyasset != 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)
- Immediate (T+0): the Guardian (security multisig,
GUARDIAN_ROLE) callsTreasury.setFounderWithdrawPaused(true). All founder withdrawals stop in that block. This is a safety pause, not an approval gate. - Durable (T+48h): revoking
FOUNDER_CONTROLLER_ROLEfrom the controller is aDEFAULT_ADMIN_ROLEaction and therefore goes through the 48hTimelockController. 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:
- USDG ≈ $1 — assumption, not guarantee (§3).
- USDG remains transferable and unfrozen for the Treasury and depositors (§3).
- Robinhood Chain liveness and integrity (§9).
- 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).
- Multisig signers are honest, distinct, and available — especially the Guardian, whose availability backs both the founder-pause (§2) and the timelock veto (§8).
- OZ Contracts v5.1.0 and Solidity 0.8.30 are sound as used.
- 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 page —
website: /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 inCLAUDE.mdP13).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.