Market Economics#

This model is for launch catalog sizing. It does not change the permissionless program: creators can still create markets within the on-chain bounds, but the first-party catalog should avoid cadences that lock rent and crank budget faster than organic volume can pay back.

Per-Market Cost Model#

Each market locks SOL and settlement-token working capital until settlement and close complete:

Current defaults reserve 5 × 200,000 = 1,000,000 lamports of closer budget per market lifecycle. That budget is separate from account rent and can be topped up permissionlessly with TopUpCloserRewards (0x35) when a market's remaining rent-safe reward pool is too low to attract keepers.

Cadence vs. Volume#

Rent float and crank cost scale with cadence:

live_markets_per_feed = ceil((duration_seconds + close_latency_seconds) / duration_seconds)
daily_market_count = feeds × durations_per_feed × (86_400 / duration_seconds)
daily_closer_budget = daily_market_count × closer_rewards_per_market × closer_reward_lamports
locked_rent_float = live_markets × (market_rent + orderbook_rent + trader_ledger_rent)

Fee revenue scales with traded notional:

fee_revenue_per_market = traded_notional × effective_taker_fee_bps / 10_000
protocol_revenue = fee_revenue_per_market × protocol_fee_share_bps / 10_000

The launch catalog should therefore treat short-duration markets as an operational cost multiplier, not just a product feature. A 15-minute cadence creates 96 markets per feed per day; a one-hour cadence creates 24; a one-day cadence creates 1. Unless observed volume supports the extra rent float, keeper load, API/indexer rows, and support load, prefer fewer feeds and fewer durations.

Launch Catalog Policy#

For broad beta, first-party market creation should start with a deliberately small catalog:

• supported high-liquidity feeds only;
• one short cadence for active traders, one hourly cadence, and one daily cadence at most;
• deep-book and trader-ledger tiers selected from measured demand, not maximum capacity by default;
• no new feed/duration pair until the previous pair shows enough volume to cover its rent float, closer budget, keeper cost, and support burden.

Review catalog expansion weekly using:

• traded notional and effective fee revenue per market;
• live rent float by feed/duration/capacity tier;
• close latency and unreclaimed-rent backlog;
• closer reward paid vs. withheld near rent floor;
• keeper transaction cost and failed-action rate;
• trader-ledger occupancy and eviction frequency.

Seat-tier expansion should follow the same review. Start experimental markets at Small, featured recurring markets at Standard, and reserve Large for flagship markets with staged liquidity or partner traffic. Do not use the 8,193 or 8,321 on-chain seat tiers in first-party launch catalogs until occupancy data shows Standard/Large are insufficient and the extra rent float is approved.

If a cadence is underused, stop first-party creation for that feed/duration, let existing markets settle and close, and keep the permissionless program unchanged.

Telemetry-Gated Keeper Reward Design#

Status: design only; inactive. The current single-rate reward remains the authoritative on-chain behavior. Crossing a monitoring threshold opens an owner review; it does not activate this design. Any activation requires a separate implementation plan, account-layout allocation, off-chain propagation review, and protocol tests.

Current contract#

• Market creation prepays account rent plus closer_reward_lamports × CLOSER_REWARDS_PER_MARKET (5) at program/src/processor/create_market.rs:503-509.
• SnapshotEnd, ResolveMarket, ExpireMarket, and ForceClose read the current config rate when they pay (program/src/processor/snapshot.rs:130-148,280-292, program/src/processor/resolve.rs:275-283, program/src/processor/expire_market.rs:250-260, and program/src/processor/force_close.rs:149-166,323-334). CloseMarket has no closer reward; the creator receives remaining account rent and unused reward budget.
• pay_closer_reward caps each payment at the lamports available above the market rent floor and logs partial or skipped payment (program/src/utils/account.rs:805-845). Thus a live config increase can consume an old market's prepaid budget faster, but cannot debit its rent floor.
• TopUpCloserRewards (0x35) validates the market/config settlement-mint binding, computes current_config_rate × 5, returns successfully when the rent-safe budget already meets that target, and otherwise transfers exactly the deficit from the signer (program/src/processor/top_up_closer_rewards.rs:23-56). This is sufficiency relative to the live config at the instant of the call, not a frozen promise: a later config change changes both pay-site behavior and the next top-up target.

The fifth prepaid reward slot is budget margin, not a CloseMarket bounty. Unused rent-safe lamports remain in the market until close and are then recovered by the creator.

Proposed reward classes#

The classes are accounting boundaries, not active configuration fields. In particular, the resolved design does not add a paid close-market class or change the existing order-reclaim bounty. The current reclaim bounty is documented at program/src/processor/reclaim_expired.rs:95-105; current market, orderbook, escrow, vault, and trader-ledger rent recovery to the creator is implemented at program/src/processor/close_market.rs:645-710.

Market snapshot and prepaid bound#

If monitoring justifies activation, creation records the applicable reward schedule in the 9-byte MarketAccount._reserved3 region. The implementation plan must choose between an 8-byte closer_reward_rate_snapshot and a compact 8-byte encoding of four u16 class multipliers over a base rate; this documentation does not make that owner/layout decision. Each lamport pay site reads the immutable market snapshot instead of live config. The creation-time prepay becomes sum(max_calls_per_class × snapshotted_class_rate) and retains the existing rent floor.

This removes retroactive repricing of already funded markets: a config update applies to newly created markets only. Existing markets drain on their captured schedule unless an explicitly designed opt-in migration is later approved.

Top-up sufficiency under a future snapshot design#

Activation must retarget TopUpCloserRewards from live config rate × 5 to the market's complete snapshotted obligation. A successful top-up must leave rent-safe lamports at least equal to sum(max_calls_per_class × snapshotted_class_rate), matching today's restore-to-full-target semantics; otherwise it rejects. A config increase alone must never raise an old market's target or its payouts.

If an opt-in reprice variant is proposed later, it must atomically prove and fund the complete new target before recording the new schedule. Partial funding cannot alter the market snapshot. The instruction shape, encoding, and whether such a variant should exist remain owner decisions for the activation plan.

The four evidence signals are budget exhaustion, missed deadlines, reward-cost ratio, and reclaim age. Budget exhaustion is an immediate review signal; missed deadlines, reward-cost ratio, and reclaim age use the documented 14-day windows. None is an automatic governance action.