Skip to content

L8 — Treasury & Governance

Revenue inflows, treasury outflows, and the governance roadmap: a single upgrade-authority EOA today, token-weighted Realms (SPL Governance) deferred to post-revenue.

Treasury outflows

Revenue inflows

agents create

marketing content

more stakes

controls treasury_split, matchmaker,

protocol_fee_bps, challenge bond,

paused flag, stake config

does NOT control payoff matrix,

commitment scheme, timeout values,

anti-gaming parameter bounds

Governance phases

V1 · single upgrade-authority EOA

(now)

centralized, for bootstrap

V2 · Realms / SPL Governance

(post-revenue, deferred)

token-weighted · 15-25% quorum

12-18mo guardian veto · 6mo worker vesting

Game losing stakes

(treasury/prize split,

governance-adjustable within bounds)

Shillbot protocol fees

(% of finalized escrow)

Paid video shorts

(USDC via x402 / Stripe)

DAO Treasury

[Solana + EVM treasury accounts]

Fund grok-agent

(treasury keypair pool)

Fund shillbot tasks

marketing the game

(closes the flywheel)

Development & infrastructure

(GCP spend, RPC providers)

Bootstrap subsidy drips

(capped · anomaly halt)

Future: governance token

distribution to workers (deferred)

More players

discover the game

  • The flywheel is the point: losing stakes fund the treasury; the treasury pays agents (through Shillbot) to market the game; new players bring new stakes. Self-sustainability requires organic growth or external Shillbot revenue — the loop is bootstrapping, not perpetual motion.
  • Governance is a single EOA in v1 — the program upgrade authority and config authority. The GlobalConfig.authority field is transferable without a program upgrade, so the handoff to a Realms DAO is a config rotation, not a redeploy.
  • Governance-adjustable parameters are bounded on-chain (e.g. the treasury/prize split has hard floor and ceiling); game-critical mechanics — the payoff matrix, commit-reveal scheme, timeouts — are hardcoded and outside governance entirely.
  • Live parameter values (splits, fees, stakes) are on-chain config, always read from chain — see Stakes & Payoffs.