Capital-efficient multi-outcome

The capital problem

Multi-outcome events are mutually exclusive — exactly one outcome resolves Yes. That means a No share on any one outcome is economically equivalent to a Yes share on every other outcome combined. Conventional design ignores this relationship: traders must post fresh collateral to express the same view a different way, and a fully-hedged position still locks capital across every outcome. On a four-outcome market today, buying 100 shares of each at 0.25 USDC costs 100 USDC total — but the position is guaranteed to pay exactly 100 USDC at resolution. The design still requires all 100 USDC of collateral to be locked.

How the capital-efficient variant works

The mechanism centers on a single conversion operation. Inside a flagged multi-outcome event, holding one No share on an outcome can be atomically exchanged for one Yes share on every other outcome in the event. Worked example with three outcomes A, B, C: a trader holding 1 share of No-on-C can convert that single position into 1 share of Yes-on-A plus 1 share of Yes-on-B. The original No share is consumed; the resulting Yes shares are tradeable like any other outcome token. Capital that previously expressed 'C will not win' now expresses 'A or B will win' — without selling and rebuying.

• Conversion is atomic: 1 No on outcome X ↔ 1 Yes on each of the remaining N−1 outcomes.
• Collateral required for a hedged position equals the maximum possible loss, not the sum of every leg.
• Settlement still pays exactly one outcome at resolution — only the path to building a position changes.
• Single-outcome trades on flagged events still work normally; conversion is opt-in per trade.

Tradeoffs and augmented variants

The conversion mechanism is most useful when every outcome of an event is named and immutable at market launch. Some real-world events have emerging outcomes — a candidate enters the race late, a team qualifies for a bracket after market open. An 'augmented' variant supports these events by reserving placeholder slots that get named later, with an explicit 'Other' bucket as the resolution catch-all. This introduces specific risks traders need to understand.

• Trade only on named outcomes. A placeholder slot has no defined meaning until it is clarified, and resolution to a still-unnamed slot routes to the 'Other' bucket.
• The economic meaning of 'Other' shifts as placeholders are named. A position that was 'bet on Other' early in a market's life may be 'bet on a much narrower Other' by resolution.
• Two API-level flags are planned to identify these markets: a base flag for standard capital-efficient events, plus an additional flag for the augmented variant. Integrators should check both before routing orders.