Tokenomics

Quorum has two classes of tokens: the protocol token QRM and per-idea tokens deployed by IdeaFactory via Clanker v4.

Protocol token — QRM

Per design decision #001:

• Ticker: QRM
• Launcher: Clanker v4 (same factory used for per-idea tokens, per design decision #002)
• LP: locked in ClankerLpLocker until year 2100
• Chain: Base mainnet

QRM is not required to use the protocol. Bonding, voting, and bounty payment all use the idea token of the chamber’s specific idea. QRM exists to:

1. Capture protocol fees (the 15% protocol BPS in each idea’s FeeRouter flows to the protocolTreasury which is QRM-controlled).
2. Govern parameter changes (initially through a Safe multisig; eventually through on-chain QRM voting + timelock).
3. Coordinate around protocol-wide upgrades and audits.

Per-idea tokens

Every chamber-graduated idea deploys its own Clanker v4 ERC-20. Standard Clanker v4 mechanics apply:

• Total supply: 100B tokens, fixed at deploy (configurable in TokenConfig but Quorum uses the standard).
• LP: locked in ClankerLpLocker until 2100. No rug.
• Fees: Uniswap V4 pool fees flow to Clanker → FeeRouter → 6-way split.
• MEV: ClankerMevBlockDelay hook enforces 1-block MEV delay.

Fee waterfall — the 6-way split

Clanker takes a fixed 20% protocol fee off the top of every trading-fee event. The remaining 80% flows into Quorum’s FeeRouter and is split per the immutable BPS config snapped at IdeaFactory.deployIdea.

Default split (sums to 10000 = 100% of Clanker’s 80% share):

A worked example. Suppose an idea’s V4 pool generates 1 ETH of trading fees over a week:

1.000 ETH total fees
├─ 0.200 ETH → Clanker protocol (20% off top)
└─ 0.800 ETH → FeeRouter
   ├─ 0.120 ETH (12%) → protocol treasury
   ├─ 0.120 ETH (12%) → idea creator
   ├─ 0.080 ETH (8%)  → chamber allocators
   ├─ 0.200 ETH (20%) → FOR-bonder pool
   ├─ 0.080 ETH (8%)  → AGAINST-bonder pool
   └─ 0.200 ETH (20%) → executor pool

Why these BPS

Per design decision #005:

• Heavy on FOR-bonders (25% × 80% = 20%): They take the most concentrated risk (their stake is slashed if the PR is rejected). Without a fat reward they don’t bond.
• Heavy on executor (25% × 80% = 20%): The PR merger is the bottleneck. Heavy incentive → more shipped code.
• Light on AGAINST-bonders (10% × 80% = 8%): They get paid TWICE on rejection — fees + the slashed FOR pool. Adding more fee weight would over-pay them and reduce reviewer adversariality (you want reviewers who reject because the work is bad, not because rejection pays best).
• Equal protocol + creator (15% × 80% = 12% each): Symmetry. The protocol bears infra cost; the creator bears the idea-origination risk.

QRM allocation — TBD

Final QRM allocation is gated on the external audit and the mainnet timeline. The current design intent:

Locked numbers will replace this table before the mainnet deploy. The protocol token will follow Clanker v4’s standard mechanics — no special token logic in Quorum’s contracts.

Slash math

Beyond trading fees, the protocol captures a slash on every bounty settlement:

• protocolSlashBps on BondingEscrow = 1000 bps (10%) default, max 3000 (30%).
• Applied to the loser pool only (the pool of bonders whose side lost).
• Flushed to protocolTreasury on flushProtocolCut(bountyId).

ForumExecutor separately takes protocolFeeBps = 500 bps (5%) of the bounty amount on approval or rejection.

Combined, the protocol takes:

• ~5% of every bounty payout (or refund on rejection).
• ~10% of the loser pool on every settlement.

Both rates are owner-tunable within bounded ranges. See Treasury.