Resolution & Disputes

Resolution is the step that turns outcome tokens into money. It is a multi-stage, bonded process rather than a single authority call.

The path to final

  Open ──▶ Closed ──▶ PendingResolution ──┬──▶ Resolved ──▶ redeem
                            │             │
                       (dispute)          └── (no dispute, window elapses)
                            ▼
                        Disputed ──▶ Resolved  or  Cancelled ──▶ refund

Instruction	Who	Effect
`close_market`	Operator	Stops trading at `end_time`
`resolve_market`	Resolution authority	Proposes an outcome; starts the dispute window
`dispute_resolution`	Anyone	Posts a bond into the vault, contesting the proposal
`finalize_resolution`	Anyone	After the window elapses, makes the outcome final
`cancel_market`	Config resolver	Voids the market; collateral is refundable

The dispute parameters — bond size and window length — live in the program’s Config PDA.

Why a window exists

resolve_market does not pay anyone. It proposes. The gap between proposal and finalization is the only opportunity to catch a wrong resolution, and the bond is what makes disputing costly enough to be meaningful. Nothing redeems until finalize_resolution lands.

Redeeming

Once Resolved:

markets::redeem    winning outcome tokens → USDC, 1:1 from the market vault

The losing side is worthless. Redemption is a transaction you send — it isn’t automatic, and the program sets no deadline. withdraw_residual lets an admin sweep a market only after it is fully settled.

Cancellation

A cancelled market never had a winner. markets::refund returns collateral against either token type, because both are claims on the same undivided pot.

Cancellation has a second life in parlays: a leg whose market cancels doesn’t kill the slip. It goes Voided and is divided out of the multiplier, shrinking the payout to what the remaining legs justify. → Settlement & Claiming

Trading around resolution

Market status	New orders	Settlement of existing matches
`Open`	yes	yes
`Closed`	no	yes, if before `end_time`
`PendingResolution`	no	no
`Disputed`	no	no
`Resolved`	no	no
`Cancelled`	no	no

execute_trade requires the market to be Open or Closed and before end_time. The Closed allowance exists so a match made moments before close can still land; it is not a window for new trading.

Reading resolution state

# Dispute info for a market
curl -s https://prod-api.gomarket.io/api/markets/{market_id}/dispute/

# A user's open disputes
curl -s https://prod-api.gomarket.io/api/markets/user/disputes/ \
  -H "Authorization: Bearer $JWT"

# What's redeemable
curl -s https://prod-api.gomarket.io/api/markets/user/claimable/ \
  -H "Authorization: Bearer $JWT"

Effect on parlay legs

A parlay leg settles once its underlying market is terminal, via the permissionless settle_leg:

Market state	Leg becomes
`Resolved`, your side won	Won
`Resolved`, your side lost	Lost — the whole slip dies immediately
`Cancelled`	Voided — divided out of the multiplier
Anything else	Transaction reverts (`MarketNotResolved`, 6013)

Because a parlay reads the market’s resolved outcome rather than a price, the dispute window protects parlays exactly as it protects redemptions: a leg cannot settle against a proposal, only against a finalized result.