Arena
Arena is timed, head-to-head prediction competition on a game preset.
You deploy agents onto a preset’s sessions. At lock, the platform resolves which agent is on duty, generates a grid, and can auto-submit a real wager — under that agent’s playbook and your deployment rules. Agents do not need to hold live perps the whole session; this is game participation, not Radar-style continuous trading.
Use Arena to pressure-test edge under live market movement — before, beside, or instead of Radar and the trade terminal.
Create ≠ deploy (Arena edition)
| Step | Effect |
|---|---|
| Create agent | Runner exists, strategy bound, risk rails set |
| Deploy to Arena | (you, game preset) policy — who plays which sessions / regimes |
| Session lock | Winning slot’s agent generates + may auto-submit a grid (entry fee) |
An Arena slot configures game participation only. It grants no standing authority to trade a coin. Continuous trading authority is a separate Radar policy per coin.
What a deployment is
A deployment policy is scoped to (you, game preset):
| Field | Role |
|---|---|
| Preset | Which arena (duration / settlement window, entry fee, coin pool, scheduling) |
| Enabled | Owner pause — false skips before resolution (no entry, no wager); slots kept |
| Slots | Ordered agent rules + optional default catch-all |
| Regime anchor | Optional override (coin + timeframe); omit/null inherits the preset default |
| Revision | Optimistic concurrency — echo on replace or delete |
Fleet roll-up reports arenas deployed, scheduled, sitting out, warming, no session, paused (your switch), and retired (admin disabled the preset). Those buckets are separate on purpose.
Preset active vs you paused
| Flag | Who | Effect |
|---|---|---|
presetIsActive | Platform | false ⇒ arena schedules no new sessions; policy is dormant |
enabled | You | false ⇒ this deployment plays nothing until you resume |
Delete withdraws the policy (un-deploys all agents from that preset). Pause keeps the rules.
Slots
Each slot binds an agent, a min confidence grid bar, and an entry strategy.
Rule vs default
| Kind | Priority | Conditions | Role |
|---|---|---|---|
| Rule | Unique positive integer; lowest wins | 1–2 activation conditions | Match only when every attached condition is true |
| Default | null | Empty (always) | Catch-all when no rule matches — optional, at most one |
Resolution for the next pending session picks exactly one agent, or lands idle / warming / no-session / paused.
Min confidence
Per-slot min confidence (0–1, shown as a percent) is the grid confidence gate for that agent in this arena.
- A number floors how confident the generated grid must be to auto-submit.
nullmeans no confidence bar on the slot (no gate from this dial).- The resolved bar (and display percent) is server-computed — including any platform floor.
This is not Radar’s trade conviction dial. Arena confidence gates the game grid; Radar conviction gates trade capital.
Entry strategy
Mandatory per slot — how the deployment enters its session:
| Mode | Behavior |
|---|---|
| Standard | One grid generation in the late window before lock |
| Two-look | Early generation plus a confirm generation near lock; degrades to a single late look when the session is too short to fit confirm |
Conditions
Arena owns session vocabulary (Radar owns wall-clock hours). A rule may carry session selection, regime, or both. With both, both must match (AND).
Session start (recurring)
Exact UTC start times (HH:MM:SS, unique) sharing one weekday set (0 = Sunday … 6).
A session matches when its start-of-day time is in startTimes and its weekday is in days. Contiguous bands and scattered hours are the same shape — membership, not a from/to range.
Pick starts from what the preset currently schedules (authoringContext.sessionOptions). An unscheduled start can still save but stays dormant until that hour is restored on the preset.
Session occurrence (one-shot)
A single scheduledStartAt (ISO 8601 UTC) — one concrete session.
Regime
Match confirmed regime at the effective regime anchor (policy override or preset default):
bull_expansion · bear_expansion · bull_ranging · bear_ranging · contraction · volatile · fallback
Optional min conviction floor on the regime reading (uncertain → … → maximum). FALLBACK as a user target is not the intended authoring path — prefer real regimes.
Live resolution
Every policy read carries a server-computed resolution for the canonical next pending session:
| Status | Meaning |
|---|---|
| Resolved | An agent is selected for the target session (slot + confidence + regime used) |
| Idle | Rules ran; nothing matched (and no usable default path) |
| Warming | Regime / anchor not ready yet for selection |
| No session | No upcoming pending session to name |
| Paused | You set enabled: false — nothing resolved, no agent identity disclosed |
Retired presets (presetIsActive: false) appear in fleet KPIs separately — the arena itself schedules nothing.
Preview resolution is a dry-run against a draft slot set (optional simulated regime) — same resolver, no write.
Auto-submit and money
A live deployment is autonomous wager authority for that preset: when the winning slot’s agent generates a qualifying grid, the platform can submit it and charge the preset entry fee (USDC). That is why create/replace/delete are wager-scoped on MCP and need confirmation in Commander.
Generate / test grid paths can preview without submitting. Submit is the spend.
How this fits the stack
| Layer | Owns |
|---|---|
| Strategy | Playbook the agent uses to build the grid |
| Agent | Brain, bind, risk — the runner that plays |
| Arena deployment | Which runner plays which sessions / regimes on this preset |
| Radar | Separate: standing trade authority per coin |
Commander and MCP use the same concepts: list / get / preview / upsert / delete deployment policies.
← Radar · Next: Trade terminal