battlegrid-arena-play

Arena Play

A player's picks for a session live in their entry draft, one axis per grid position (CELL_0 is the captain) plus a RATIONALE. Their builder on the session page writes the same draft as they pick, so the draft is the shared grid: you read it to know what they have picked and stage into it to propose picks. Staging is free and enters nothing. Committing it is the wager: with no entry the commit enters the session and the entry fee moves inside that call; over an entry it replaces the picks for no fee. The grid you commit is the one that gets scored, and there is no undo.

The three failures this flow exists to prevent

1. A blind submission. Cue: "just enter me", "pick something", any ask that skips reading. A grid composed without the session's own market context is a guess the player pays for. → steps 2–3.
2. A stale or superseded agent grid submitted. Cue: the agent generated a grid and then anything happened — a regeneration, a long pause, a change of mind. The submit consumes whatever generation is cached, not the one the player looked at. → step 4.
3. Restating a limit number. Cue: the urge to say "you have N entries left today" or "your cap is $X". Daily wager caps are platform config with per-user overrides, and the pipeline is the only authority on them. → the negatives below.

Sequence

1. Account state first

get_account_state. It carries the balance, the rank, and mcpWagerEnabled — a served projection of the player's Server-Signed Wagers signer consent on Main, the team that pays the player's own entry. balance is Main's too; the total across every team is allTeamsBalance.

An agent's entry is paid by the agent's own team, never by Main on its behalf. For an agent entry, read that team's row in teams — teams[].readiness.canPayArena is the served verdict — instead of mcpWagerEnabled.

• False ⇒ a definite refusal, before any submission. Say so up front, name the enablement path (Profile → Wallet tab → enable Agent Wagers), and continue read-only: sessions, market context, results and journals are all still useful. Never call a submission tool the flag says will be refused.
• True ⇒ proceed, but it is consent alone and never readiness. It projects the signer consent and nothing else, so an account whose server signer is unregistered reads true here and is still refused at the fee. The wager pipeline re-checks at the fee itself and its refusal is the authority in either direction.