Mutual-claim result flow

Why both participants must file a claim, and how the platform reconciles them.

MusterBox does not trust a single browser to decide a match. This guide walks the two-participant claim protocol end to end.

The protocol

Participant A                        Participant B
     │                                    │
     │ openSession({matchId})             │ openSession({matchId})
     │  → session A (single-use)          │  → session B (single-use)
     │                                    │
     │ submitResult(claim, session A)     │ submitResult(claim, session B)
     │  → decision: pending               │  → decision: game_advance
     │       (awaiting opponent)          │       (claims agree)

The platform records a claim only when its session token validates to a real, unconsumed, non-expired match session bound to that user and match. Both participants must claim the same outcome for the match to finalize.

Reading the decision

Decision	Meaning
pending	Awaiting the opponent’s claim
replay	Both agree on DRAW, but draw is disabled for this single-elimination match — replay in place, match stays running
game_advance	Claims agree; match finalized and bracket advanced
game_advance_pending_finalization	Claims agree; bracket finalization was deferred (transient backend state)
dispute	Claims conflict (or a consistent winner could not be mapped to a slot) — awaiting server adjudication

Practical rules

• A one-time session token is a session secret — keep it out of bundles, logs, and network dumps.
• Resolve ambiguous or late positions (replay, tie-break) inside your game before submitting a conclusive claim.

When to surface what

• After your own claim: show “awaiting opponent” when decision == pending.
• When the opponent claims agree: proceed on game_advance.
• On dispute: hold UI, do not finalize locally, and surface the dispute state to the player (server adjudication decides).

Next: Monitoring a player session.