Protocol guide

STONK is a treasury-backed reserve protocol for Robinhood Chain. Bond markets exchange approved reserve assets for vested STONK, while conservative onchain backing limits new supply.

Tokens

STONK and stSTONK are the complete token system. There is no intermediate staking token, governance wrapper, index, or periodic supply update.

Staking vault

The vault holds STONK directly:

deposit STONK -> mint stSTONK
redeem stSTONK -> return pro-rata STONK

The first deposit starts near one share per STONK. Thereafter, ERC-4626 preview and conversion functions are authoritative. A direct STONK deposit that mints no shares, such as protocol revenue or a buyback, increases totalAssets() and therefore the STONK redeemable per share. It never creates votes or new STONK.

User transactions use overloads with explicit output limits:

• deposit(assets, receiver, minimumShares)
• mint(shares, receiver, maximumAssets)
• withdraw(assets, receiver, owner, maximumShares)
• redeem(shares, receiver, owner, minimumAssets)

Clients must call a preview immediately before submission and apply a user-visible limit. Standard ERC-4626 methods remain available to integrations.

Revenue and emissions

Launch emissions are zero because no emission contract exists. stSTONK value can grow only when existing STONK enters the vault without minting shares. A revenue controller or buyback executor may be introduced only through a separately audited governance proposal with a clearly identified revenue source.

No APY is promised. Frontends must show assets per share and historical realized change, not a fabricated forward yield.

Bonds

Governance creates markets with a quote token, capacity, maximum payout, price curve, vesting duration, and conclusion. A deposit:

1. validates market liveness, price, capacity, payout limit, recipient consent, and system state;
2. transfers the quote asset to the treasury;
3. mints only the bounded STONK payout into a vesting note; and
4. lets the recipient redeem vested STONK later.

The caller supplies both a maximum acceptable market price and a minimum payout. Market capacity bounds aggregate remaining issuance; maxPayout bounds one deposit.

Backing

Backing uses live treasury balances and validated prices:

risk-adjusted reserves = sum(balance x valid price x haircut)
backing per STONK = risk-adjusted reserves / total STONK supply

MINTR prevents bond issuance beyond the configured conservative backing rule. Backing is an accounting constraint, not a claim that holders can redeem STONK for a basket, a guaranteed floor, or a price peg.

Prices and external assets

PRICE reads Chainlink AggregatorV3 proxies. It rejects incomplete, future, stale, identity-mismatched, excessive-deviation, or over-cap results. Equity assets also fail closed when the Robinhood token exposes a paused oracle state. Token decimals are recorded and checked because decimal drift changes valuation.

USDG is capped at $1. Volatile assets receive configured haircuts and caps. External tokens can still freeze, blocklist, pause, upgrade, lose liquidity, or change behavior outside STONK governance.

The mainnet candidate currently uses an explicitly accepted unprotected sequencer mode because no canonical feed has been approved. See STK-001.

Governance

stSTONK is the voting token. A holder delegates to themselves or another address, then checkpointed voting power can propose and vote. Passing proposals queue in StonkTimelock and execute only after its delay.

STONK -> deposit -> stSTONK -> delegate -> Governor -> Timelock

Acquiring shares does not create active votes until delegation. Redeeming shares reduces delegated voting power. Vault revenue increases economic value per share but does not increase vote count.

Emergency behavior

The guardian can shut down MINTR and TRSRY and cancel queued Timelock operations. It cannot restart, create markets, change prices, withdraw assets, mint STONK, or execute governance. Only delayed governance restarts contained modules.

Vault deposit and redemption do not rely on a scheduler or operator key. Users retain their ERC-4626 exit subject to STONK token behavior and the vault's onchain balance.

User journeys

Bond and stake

1. Inspect the market, oracle state, capacity, price, minimum payout, and vesting.
2. Approve the quote token and deposit with explicit limits.
3. Redeem vested STONK.
4. Approve the vault and deposit STONK with a minimum-share limit.
5. Delegate stSTONK if participating in governance.

Exit staking

1. Preview the redemption.
2. Submit redeem with a minimum-asset limit.
3. Receive STONK directly; no wrapper approval or maintenance call is needed.

Integration rules

• Resolve addresses from the manifest for the active chain.
• Verify chain ID and deployed bytecode before enabling writes.
• Read token decimals onchain; STONK and stSTONK currently use 9.
• Use ERC-4626 previews and bounded overloads for transactions.
• Never display backing as redeemable NAV or guaranteed price.
• Treat invalid or stale prices, inactive modules, missing manifests, and chain mismatch as write-blocking states.
• Read Governor, Timelock, market, role, and vault state onchain rather than relying on documentation defaults.

Contract directory