THE MECHANISM

The mechanism, documented.

Robin is a DeFi mechanism that produces NFTs, not an NFT project with a DeFi mechanism attached. This technical whitepaper describes the hook, capture economics, token-bound objects, and integration paths.

contract source; each is linked to the named constant it came from.

1. Overview

ROBIN is a DeFi mechanism that produces NFTs, not an NFT project with a DeFi mechanism attached.

The system is a Uniswap v4 hook protocol on Robinhood Chain composed of three layers that share one state:

**Layer 1: Exchange.** A v4 hook that executes inside every swap in its pools: it measures price behavior, detects sandwich and just-in-time (JIT) liquidity attacks, charges the attacker, and adjusts pool fees dynamically under attack conditions.

**Layer 2: Economics.** A fixed-supply ERC-20 (ROBIN, 10,000 units), an ERC-4626 capture vault that streams captured MEV to participants, protocol-owned liquidity that deepens with every capture, and burn paths funded by attacker surcharges.

**Layer 3: Objects.** NFTs minted by swaps, rendered fully on-chain, each owning its own account (ERC-6551) containing locked ROBIN and accumulated ETH, redeemable by burning.

The fungible token is the raw economic material. The NFT is a composable economic object built from it: 1.0 locked ROBIN, a vault share position, accumulated ETH, deterministic traits, and provenance tied to a real market event. Everything below specifies how those pieces connect.

The thesis in one sentence: **ROBIN turns adversarial market behavior into productive protocol state.** The attacker is not merely stopped; the attack feeds every layer above it.

Why ROBIN is different

1. **MEV becomes protocol revenue.** Detected adversarial extraction stops being leakage from LPs and traders and becomes a distributable protocol resource. 2. **NFTs are economic objects.** Each object owns locked ROBIN, vault exposure, accumulated ETH, and provenance, not a pointer to an image. 3. **Scarcity is activity-dependent.** The rarest objects (Trophies, defeats, Ballads) can only be produced by real protocol events, not by rarity tables alone. 4. **Protection becomes infrastructure.** Third-party pools integrate the hook and convert the attacks against them into revenue. 5. **Every layer reinforces the next.** Trading → detection → capture → ETH → rewards and liquidity → more activity.

                    TRADING ACTIVITY
                           │
                           ▼
                  ┌─────────────────┐
                  │   ROBIN HOOK    │
                  │ MEV DETECTION   │
                  │ DYNAMIC FEES    │
                  └────────┬────────┘
                           │
                     CAPTURED MEV
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       LPs / POL       ROBIN NFTs       TREASURY
          │                │
          │                ▼
          │          ETH + WEIGHT
          │                │
          └──────► LIQUIDITY ◄─────────────┘
                           │
                           ▼
                     MORE ACTIVITY ──► (loop)

One object's lifecycle

A trader swaps ETH for 1.2 ROBIN through the official pool. The 1.0 mints a Robin in the same transaction, traits drawn from the swap's own hash, and the 0.2 renders as two arrows in their quiver. A week later a sandwich bot attacks the pool during their trade; the hook charges the bot's exit leg, and the trader receives an Intercept Trophy minted inside the attacker's transaction, carrying 2x weight. Both objects accrue ETH from every subsequent capture, visible as balances in accounts the NFTs themselves own. The trader sells the Robin on Sherwood Market, its locked ROBIN, ETH, and weight travel with it atomically, and later the buyer burns it, receiving 1.0 ROBIN back into circulation plus the accumulated ETH. The Trophy stays, fattening, its provenance naming the bot that paid to mint it.

2. Architecture

                        ┌────────────────────────────┐
  Trader / Bot / Router │   Uniswap v4 PoolManager   │
  ──────── swap ──────► │      (canonical, 4663)     │
                        └────────────┬───────────────┘
                                     │ hook callbacks
                          ┌──────────▼──────────┐
                          │      RobinHook      │
                          │  detection · fees   │
                          └──────────┬──────────┘
                                     │ captures
                          ┌──────────▼──────────┐
                          │   Capture Engine    │
                          └──┬─────┬─────┬────┬─┘
                     50%     │20%  │20%  │10% │
                  ┌──────┐ ┌─▼───┐ ┌─▼──┐ ┌─▼──────┐
                  │ LPs  │ │NFTs │ │POL │ │Treasury│
                  └──────┘ └─────┘ └────┘ └────────┘

Mint path:

qualifying swap ─► RobinObject mint ─► ERC-6551 account created
                        │                    │
                   traits from          1.0 ROBIN locked
                   swap hash            + vault shares

The protocol integrates with the canonical Uniswap v4 deployment on Robinhood Chain (chain ID 4663). It does not run a private fork of the AMM. All detection and fee logic executes in hook callbacks within the swap transaction itself.

3. The Object

Minting

Any swap through a Robin pool that delivers at least 1.0 ROBIN to the recipient mints one Robin NFT in the same transaction. Ordinary transfers do not mint. Fractional balances below 1.0 render as quiver arrows (Section 3.4).

At mint, the hook records the swap's parameters: pool, tick before the swap, size, block number, and recipient. The trait hash is derived from these values. This makes every object's appearance a deterministic function of a real market event, and makes the art re-derivable: anyone can recompute hash → traits → SVG from the stored parameters and verify byte-equality against the contract's output. A public verification script ships with the repository.

Token-bound accounts (ERC-6551)

Each transferable object owns an ERC-6551 token-bound account. The account holds:

  • the 1.0 ROBIN locked at mint or forge,
  • the object's ERC-4626 vault shares (Section 7),
  • accumulated ETH from captures.

Because the account belongs to the NFT rather than to a wallet, transfers require no custom bookkeeping: selling the object moves everything it owns, atomically. There is no path by which a holder's other balances affect an object's backing. Nothing a holder sells or transfers can invalidate an NFT they hold.

The account implementation address is pinned; substituting a foreign implementation is not possible.

Redemption

Burning a Robin pays out, in one transaction: its 1.0 ROBIN (returned to circulating supply) and the full ETH balance of its account (its redeemed vault position). Redemption is irreversible; the object and its art are destroyed, and its reward weight leaves the active weight denominator (Section 7.1).

Every Robin therefore has a **deterministic on-chain redemption value**, computable by any contract or indexer via `previewRedeem` plus the account's ETH balance. This is redeemability, not a guaranteed market price: an object can trade below redemption value due to gas, liquidity, urgency, or risk discounting. What the protocol guarantees is that the redemption value is observable, exact, and executable on-chain at any time.

The quiver

Balances below 1.0 ROBIN render as arrows: each 0.1 ROBIN fills one arrow slot in a 10-slot quiver, rendered on-chain like every other asset. A full quiver may be forged into a Robin, which locks the 1.0 ROBIN into the new object's account through the standard mint path.

Rendering

The renderer holds a single canonical 32×32 pixel grid. Traits select palette and layer substitutions; the figure never changes. Rendering is a pure view function over (trait hash, vault state, live pool state):

  • **Weather:** current pool price at or above the object's mint price renders a clear night (moon, stars); below by more than **1,000 bips (10%)** (`RobinArt.WEATHER_STORM_BIPS`; overcast begins at **200 bips (2%)**, `RobinArt.WEATHER_OVERCAST_BIPS`) renders storm.
  • **Hoard tier:** the object's accumulated value selects trim tiers at thresholds **0 / 1e15 / 1e17 / 1e18 wei** (`RobinArt.HOARD_STASH`, `HOARD_TROVE`, `HOARD_HOARD`; three thresholds, four tiers).

tokenURI is strictly view-only, bounded in gas, and cannot revert for any pool state.

4. MEV Detection

This section specifies what the hook stores, what it measures, and exactly when a charge occurs. It is the load-bearing mechanism of the protocol.

The state model

For each pool, the hook maintains a rolling window of per-block state:

| Variable | Meaning | |---|---| | `tickBlockOpen` | pool tick at the first interaction of the current block | | `tickPreSwap` | pool tick immediately before each swap begins | | `tickPostSwap` | pool tick after the swap settles | | `travel` | signed tick displacement of a swap: `tickPostSwap − tickPreSwap` | | `netTravel` | displacement of current tick from `tickBlockOpen` | | `swapDirection` | zeroForOne or oneForZero per swap | | `liquidityDelta` | per-address liquidity added/removed in the current window | | `WINDOW_BLOCKS` | evaluation window: **1 block** (`MEVProtection.WINDOW_BLOCKS`) |

All quantities are pool-state observations. No variable records or conditions on `msg.sender` identity for classification purposes; addresses appear only in accounting (who is charged, who is paid).

Sandwich detection

A sandwich has a shape in pool state, independent of who executes it:

1. **Front leg:** a swap displaces price in direction D (`travel` large, same sign as D). 2. **Victim leg:** one or more swaps continue in direction D at the worsened price. 3. **Exit leg:** a swap in direction −D walks price back toward `tickBlockOpen`.

The hook observes each leg as it executes. The front leg and victim leg update window state. The charge is applied on the **exit leg**: when a swap's `travel` opposes recent displacement and moves the price back toward the block-open tick by more than **60 ticks** (`MEVProtection.DEFAULT_REVERSAL_TICK_THRESHOLD`, per-pool as `PoolConfig.reversalTickThreshold`) within **1 block** (`WINDOW_BLOCKS`), the swap is classified as an attack exit and a capture surcharge of **300 bips (3%)** (`MEVProtection.DEFAULT_CAPTURE_BIPS`, ceiling **1,000 bips** via `MAX_SURCHARGE_BIPS`) is applied to it, collected in the swap's settlement.

Two design details matter:

  • **Measurement is from the pre-swap tick, not post-swap.** A back-run by construction moves price toward where it started; measuring displacement after settlement would systematically understate the attack. The implementation measures travel from `tickPreSwap`, and a regression test enforces this.
  • **The attacker pays at their own exit.** The hook never needs to see a future transaction. It waits for the pattern to complete and charges the completing leg. If the attacker never exits through the pool, they hold the inventory risk they tried to avoid, which is itself the deterrent.

Wallet-splitting

Classification is a function of pool-state transitions, not addresses. If wallet A executes the front leg and wallet C the exit leg around victim B, the state sequence (displacement, victim continuation, reversal toward block open) is identical to the single-wallet case, and the exit leg is charged identically. The test suite includes a named test that constructs exactly this three-address sandwich and fails if the charge is evaded.

What identity-independence costs: the protocol cannot "blacklist" attackers, and the Sheriff title (Section 9.2) tracks addresses only for narrative accounting, not for detection.

JIT detection

JIT liquidity is a different shape: liquidity that exists only around a victim swap.

The hook classifies a liquidity position as JIT when all of the following hold within the evaluation window:

1. liquidity is added to a range covering the current tick at most **5 blocks** (`MEVProtection.DEFAULT_JIT_MIN_BLOCKS`, per-pool as `PoolConfig.jitMinBlocks`, ceiling **300** via `MAX_JIT_MIN_BLOCKS`) before a swap, 2. that liquidity participates in the swap (earns fees from it), 3. the same position is removed within **5 blocks** (the same `jitMinBlocks` clock, the implementation has one window, not separate entry and exit windows) after the swap.

On the removal (the exit leg again), the position's fee earnings from the window are surcharged at **8,000 bips (80%)** (`MEVProtection.DEFAULT_JIT_CAPTURE_BIPS`, ceiling **9,000 bips** via `MAX_JIT_SURCHARGE_BIPS`) and routed to the capture engine.

What JIT detection is **not**: a tax on active liquidity management. Positions that remain through the exit window, positions that do not cover the swap tick, rebalances that remove and re-add across nearby blocks, and multiple independent LPs entering in the same block are all exempt, and each of these cases is a named test in the suite. Splitting the add and remove across transactions within the window does not change classification; splitting beyond the window escapes it, at the cost of holding the position through real price risk, which converts the JIT strategy into ordinary LPing.

False positives

The classifier's first design constraint is that honest flow must not be charged. Protections, each backed by a test:

  • **Size is not a signal.** A large honest swap displaces price but produces no reversal pattern. No charge attaches to displacement alone.
  • **Uncorrelated reversals.** A swap in direction −D following unrelated flow in direction D is only charged if it completes the full pattern within the window, including the victim-leg structure, price reverting through independent trading does not satisfy the victim condition. The suite includes the scenario: large buy, price moves, independent seller, price reverses, no charge (`test_AnUnrelatedSameBlockReversalIsNotCharged`).

The victim leg is identified by comparing transaction origins, which is the one place identity enters classification.

  • **Thresholds are calibrated for precision.** The reversal threshold and the JIT windows are tuned so that classification fires on genuine attack patterns while honest flow always trades at baseline.

Classification matrix

Each row corresponds to at least one named test executed against a fork of Robinhood Chain mainnet with the canonical PoolManager.

| Scenario | Outcome | Named test | |---|---|---| | Normal swap | no capture | `test_QuietPoolChargesBaseline` | | Honest large swap, no reversal pattern | no capture | `test_ALargeHonestSwapPaysBaseline`, `test_frontRunLegAloneIsNotSurcharged` | | Classic single-wallet sandwich | exit leg charged | `test_sandwichBackRunIsSurcharged` | | Cross-wallet sandwich (A buys, B victim, C sells) | exit leg charged | `test_splittingLegsAcrossAccountsDoesNotEvadeTheTax` | | JIT: add → swap → remove within windows | removal charged | `test_jitLiquidityForfeitsMostOfItsFees` | | LP rebalance across nearby blocks | no capture | `test_ARebalanceAcrossBlocksIsNotJit` | | Multiple independent LPs, same block | no capture | `test_ManyLpsInOneBlockAreIndependent` | | Near-miss / ambiguous pattern | no capture | `test_ASmallIntraBlockRoundTripIsNotCharged`, `test_smallRoundTripBelowThresholdIsNotSurcharged` |

Two further rows the suite covers that the matrix does not name: the sandwiched trade itself is never charged (`test_SandwichVictimPaysBaseline`), and an opposite-direction swap in a *later* block is never charged (`test_AnOppositeSwapInALaterBlockIsNotCharged`).

5. The Drawbridge: Dynamic Fees

Robin pools use v4 dynamic fees driven by the same state the classifier maintains, no second heuristic exists.

  • Base fee: **3,000 hundredths of a bip (0.30%)** (`MEVProtection.DRAWBRIDGE_BASE_FEE`).
  • When window state indicates attack conditions (displacement plus reversal structure forming), the fee escalates along a defined curve, **100 per tick of travel beyond the threshold** (`DRAWBRIDGE_FEE_PER_TICK`), to at most **30,000 hundredths of a bip (3.00%)** (`DRAWBRIDGE_MAX_FEE`), a hard cap reached at 330 ticks of intra-block travel.
  • The escalation decays back to base within **10 blocks** (`DRAWBRIDGE_DECAY_BLOCKS`) of calm state.

The escalated portion collected during attack conditions, the surcharge over base fee, is swapped to ROBIN and burned. Honest traders in calm markets pay base fee; a regression test asserts that a large non-attacking trader pays base fee even at high volume.

6. Token Economics

Supply

  • Total supply: **10,000 ROBIN**, fixed at genesis. No mint function exists.
  • Genesis: 100% of supply is deposited into the ETH/ROBIN v4 pool as a protocol-owned position placed **entirely above the initial price**, a one-sided range requiring only ROBIN at genesis, the standard concentrated-liquidity bootstrap. As buyers move price upward through the range, the position converts progressively into ETH, which remains inside the protocol-owned position. No team allocation, no presale, no airdrop. The deployer's balance after genesis is zero, verifiable on-chain.
  • Swap fees on the genesis position accrue to the treasury permanently. The position itself cannot be withdrawn by any EOA.

Two properties of the genesis range are consequences worth stating rather than discovering:

  • **The position spans the entire usable tick range, so price opens at the bottom of it.** It is not a bounded bootstrap range. The first buyer therefore takes a very large fraction of supply for very little, and the opening price is close to zero. Choosing the genesis tick is a decision, not a default.
  • **The rounding remainder is burned, not kept.** Liquidity is an integer, and a full-range position holds so few liquidity units that a single unit is worth a meaningful amount of ROBIN. Whatever the chosen liquidity cannot place is destroyed, on the order of a tenth of a percent of supply, measured by `test_TheCostOfTheGenesisRangeIsBounded`, which fails outright above one percent.

The locked-supply loop

Because every Robin locks 1.0 ROBIN, supply cycles through four states:

liquid ROBIN ──mint──► locked in NFTs ──trade──► (still locked)
     ▲                                              │
     └────────────── redemption (burn NFT) ◄────────┘

Maximum simultaneous Robins: 10,000. As the lock ratio rises, liquid float falls. Illustrative lock states (not projections):

| Robins existing | ROBIN locked | Liquid float | |---|---|---| | 1,000 | 1,000 | 9,000 | | 5,000 | 5,000 | 5,000 | | 9,000 | 9,000 | 1,000 | | 9,900 | 9,900 | 100 |

At high lock ratios, the marginal cost of minting rises with pool depth against a shrinking float, and redemption becomes the release valve: any Robin can be burned at any time to return 1.0 ROBIN to circulation plus its accumulated ETH. The system is reflexive by construction: mint demand tightens float, redemption loosens it, and the redemption path is what keeps the loop two-directional. The protocol makes no claim about where this equilibrates; it documents the mechanism.

Burn paths

Supply decreases through three paths, all funded by protocol activity: drawbridge surcharges (Section 5), Sherwood Market fees paid in ROBIN (Section 8), and 50% of Ballad auction proceeds (Section 9.4). Burns are permanent and on-chain.

7. Reward Economics

The capture vault

Captured MEV streams into an ERC-4626 vault. Reward weight is implemented as **share quantity**, not side-accounting: at mint, an object's token-bound account receives shares in proportion to its type, a Robin's account holds 1 unit of shares, a Trophy's 2, a Merry Man's 5.

NFT ──owns──► ERC-6551 account ──holds──► vault shares (= weight)
                                               │
                          capture deposits ETH into vault
                                               │
              object's claim = its shares / total shares outstanding

**Active reward weight** `W_active` is therefore simply the vault's total shares outstanding. Redeeming or forging an object burns its shares, removing it from the denominator automatically, no separate registry exists to drift out of sync. Rewards accrue from mint forward; nothing accrues retroactively.

| Object | Shares held | |---|---| | Robin | 1 unit | | Intercept Trophy | 2 units | | Merry Man | 5 units |

Per-object accrual for a capture allocating `E` ETH to NFTs:

object_reward = (object_weight / W_active) × E

The vault uses virtual-share offsets to eliminate first-depositor/donation attacks; share math is fuzz-tested to the wei across interleaved mint/capture/redeem sequences.

The split

Every capture is allocated:

| Destination | Share | |---|---| | Liquidity providers of the attacked pool | 50% | | Object vault (by active weight) | 20% | | Protocol-owned liquidity | 20% | | Treasury (multisig, Section 11) | 10% |

LP shares use a pull-based O(1) share-per-liquidity ledger; nothing is pushed automatically. LPs may claim, or compound claimed ETH into their position in one transaction.

Worked example (illustrative, not a projection)

Suppose cumulative captures of 100 ETH with 2,000 active objects: 1,900 Robins (1x), 90 Trophies (2x), 10 Merry Men (5x). Then `W_active` = 1,900 + 180 + 50 = 2,130.

| Destination | ETH | |---|---| | LPs | 50 | | Object vault | 20 | | POL | 20 | | Treasury | 10 |

Per-object from the 20 ETH vault allocation: a Robin accrues 20 × (1/2,130) ≈ **0.0094 ETH**, a Trophy ≈ **0.0188 ETH**, a Merry Man ≈ **0.0469 ETH**.

Sensitivity to capture volume (same population, per-Robin accrual):

| Captures/day (avg 0.05 ETH) | Daily vault flow | Per-Robin per day | |---|---|---| | 20 | 0.2 ETH | ≈ 0.000094 ETH | | 100 | 1.0 ETH | ≈ 0.00047 ETH | | 1,000 | 10 ETH | ≈ 0.0047 ETH |

These tables illustrate the arithmetic only. Actual capture volume depends entirely on trading activity and attack frequency on Robin pools, neither of which the protocol controls or predicts.

8. Sherwood Market

A first-party on-chain marketplace: fixed-price ETH listings, on-chain escrow, buy/cancel, pull-based proceeds, reentrancy-guarded throughout.

  • Protocol fee: **2%** (`SherwoodMarket.FEE_BIPS`, ceiling **10%** via `MAX_FEE_BIPS`). Fees paid in ROBIN receive a **25%** discount (`ROBIN_FEE_DISCOUNT_BIPS`) and are burned; ETH fees go to treasury.
  • Every listing displays the object's deterministic redemption value beside its price. The market can price objects wherever it likes; the redemption value is simply visible, on-chain, next to the ask.
  • Objects are standard NFTs; third-party marketplaces that index Robinhood Chain can list them without permission.

9. The War Layer

The collectible layer is downstream of protocol activity: every rare object is a record of something that actually happened.

Intercept Trophies

When a capture occurs, the trader who was attacked receives a Trophy: forced blood-sky palette, gilded arrowhead, 2x weight, and the captured amount stored permanently in its record. The Trophy is minted inside the attacker's transaction, the attacker pays the mint gas, and their address is in the token's provenance forever. A fallback path lets the victim mint the Trophy afterwards if the in-transaction mint cannot complete; the capture itself can never be blocked by the trophy path.

The Sheriff

The address with the highest cumulative captured-from total across Robin pools holds an on-chain title: the Sheriff of Nottingham. The title is a protocol-tracked statistic with no detection role (Section 4.3). When cumulative captures from the sitting Sheriff cross defined thresholds, **0.1 ETH** (`Sheriff.DEFEAT_THRESHOLD`, mirrored as `MEVProtection.LEGEND_DEFEAT_WEI`), a defeat is recorded. Defeats gate the top rarity tier, together with **10 intercepts** (`MEVProtection.LEGEND_INTERCEPTS`). An attacker can rotate wallets to shed the title; doing so merely crowns the next-largest extractor, which is the point.

Merry Men

Burning a set of **4** Robins (`MerryMenForge.INPUTS_PER_LEGEND`) forges one named legend (Little John, Friar Tuck, Will Scarlet, Marian), each with a fixed maximum count (**12 / 24 / 36 / 8**, `MerryMenForge.maxCountOf`) and **5x** weight (`MEVProtection.RARITY_LEGEND_WEIGHT`). The inputs' locked ROBIN and accumulated ETH roll into the forged legend's account; forging destroys objects but conserves value to the wei.

Ballads

At cumulative capture milestones (**1, 10, 100, 1,000 ETH**, `Ballads.MILESTONE_0..MILESTONE_3`), the protocol auto-mints a one-of-one 48×48 scene and opens an on-chain English auction (**3 days**, `AUCTION_DURATION`; minimum increment **5%**, `MIN_INCREMENT_BIPS`; reserve **0.01 ETH**, `RESERVE`; pull refunds). Proceeds split **50% swap-to-ROBIN-and-burn / 50% protocol-owned liquidity** (`BURN_BIPS`). No wallet receives any portion. The rarest objects in the collection cannot exist unless the protocol functions.

10. Third-Party Pools: Protection as Infrastructure

Any token on Robinhood Chain can create a pool with the Robin hook through the factory:

  • The registering project posts a refundable ROBIN bond of **50 ROBIN** (`RobinFactory.COLLECTION_STAKE`). Protection is inactive while under-bonded; the bond returns on deregistration. Holders never stake anything.
  • The project receives its own themed object collection rendered by the Robin renderer with its registered palette.
  • **Host share:** the project designates a treasury, and **10%** (`MEVProtection.HOST_SHARE_BIPS`) of every capture on their pool routes to it off the top. The remaining 90% follows the standard split proportionally. The effective allocation on a third-party pool:

| Destination | Share of capture | |---|---| | Host project treasury | 10% | | Pool's liquidity providers | 45% | | Object vault | 18% | | Protocol-owned liquidity | 18% | | Robin treasury | 9% |

The host share is the **only** cut a third-party pool pays. An earlier implementation also took a flat 15% protocol cut off the top; it has been removed, because charging a project 15% for protecting their users and then asking them to integrate is not an offer anyone accepts.

The value proposition is symmetrical: the integrating token gets MEV protection for its traders and LPs, a collection minted by its own trading activity, and revenue from the attacks made against it. The protocol gets volume, captures, and bond demand. Each integration extends the flywheel: more pools → more captures → more flow to every layer above.

11. Governance and Security

Immutable vs. governable

| Immutable (no path to change) | Governable (multisig, documented) | |---|---| | Token supply and absence of mint function | Capture split percentages | | 1.0 ROBIN backing per object | Drawbridge fee curve constants | | Redemption mechanism and payout math | Detection thresholds within bounded ranges | | Genesis liquidity position (non-withdrawable) | Treasury recipients, on a 2-day timelock | | ERC-6551 account implementation (pinned) | Registration bond, within compile-time bounds | | Renderer grid and trait derivation | |

Governance

Core contracts are permissionless and non-custodial. Governance is a multisig restricted to the explicitly documented parameters above, on a published path to a community multisig as the protocol matures. Its address, signer count, and threshold are published at deploy. Ownership transfers use two-step acceptance.

Governance **cannot**: mint ROBIN, seize or transfer any NFT, withdraw genesis liquidity, alter the 1.0 ROBIN backing or redemption math, rewrite object ownership or provenance, or modify historical captures. No function for any of these exists in the contracts.

Governance **can**: adjust capture split percentages, drawbridge fee-curve constants, detection thresholds within hard-coded bounded ranges, the registration bond size, and Hoard tier thresholds.

On-chain security gate

Treasury deployment into deep protocol-owned liquidity is protected by an on-chain security gate built into the treasury's own deployment path. This is enforced in code, not stated as policy: large-scale POL deployment can only proceed once the gate's on-chain security attestation has been published.

Implemented in `RobinTreasury.deployToPOL`, which enforces the gate at the contract level. The attestation is settable exactly once, records the report URI and the timestamp on-chain, and there is no function that can clear it. `AuditGate.t.sol` holds all of that, including the absence of a closing path.

Testing posture

The full suite, detection scenarios (Section 4.6), vault fuzzing, market interleavings, conservation invariants, router-agnosticism (the hook never conditions behavior on sender or router), runs against a fork of Robinhood Chain mainnet using the canonical PoolManager, not a local simulation. Byte-equality tests pin the renderer to the canonical art grid.

12. Contracts and Verification

Published at deployment: token, object, hook, vault, factory, market, treasury addresses; verified source on the chain explorer; deployment transaction hashes; the multisig's composition; and the art verification script that recomputes any object's SVG from its on-chain swap parameters.

Until those addresses are live, nothing that claims to be ROBIN is ROBIN.

*ROBIN is themed on the public-domain Robin Hood folk legend. It is not affiliated with Robinhood Markets or any exchange. Nothing in this document is financial advice; reward arithmetic describes mechanism behavior, not expected returns.*