Prediction markets are more than Yes/No. Alongside binary markets there are categorical multi-outcome markets (who wins) and scalar markets (what the number is). Each has different pricing constraints, market-making costs, settlement rules, and manipulation risks. This article explains the three forms, the sum-of-prices-equals-one arbitrage correction, complete sets, scalar linear payoffs, liquidity dilution, oracle edge cases, and the share-ledger and batch-settlement engineering.

1. Three Market Forms: Binary, Categorical, and Scalar

A binary market has two mutually exclusive outcomes (Yes/No), paying 1 to the winner and 0 to the loser at settlement. A categorical market has N mutually exclusive outcomes (e.g. candidates) with exactly one winner. A scalar market settles on a continuous value (CPI, year-end BTC price) with linear payoffs. Binary is simplest and most liquid; categorical carries more information but splits liquidity N ways; scalar expresses magnitude expectations but is most sensitive to oracle precision and bounds.

2. Pricing Constraints and Arbitrage Correction in Multi-Outcome Markets

For mutually exclusive outcomes priced in one quote currency, the sum of prices must equal 1—buying all outcomes should cost exactly the 1 paid out at maturity. If the sum deviates, arbitrageurs buy the underpriced complete set or sell the overpriced combination, pulling prices back. AMMs can enforce this in the formula (e.g. LMSR); order books rely on arbitrageurs, so UIs should show the sum deviation and offer one-click complete-set buy/sell.

3. Minting, Splitting, and Merging Complete Share Sets

A complete set is one share of every outcome, always redeemable for 1 unit. Users mint a set for 1 unit or merge one of each to redeem 1. This creates a hard arbitrage anchor. Engineering must make mint/merge atomic and forbid minting after settlement, which would otherwise create shares from nothing.

4. Can a Multi-Outcome Market Be Decomposed into Binary Markets

A categorical market is mathematically equivalent to a set of "candidate X: Yes" binaries, but with differences: decomposition fragments liquidity further and requires a counterparty for each binary; a single N-outcome market shares liquidity under unified LMSR pricing and is more capital-efficient. Decomposed binaries are easier to understand and reuse across platforms. In practice both coexist; the platform should let users trade in one interface with unified ledger accounting.

5. Scalar Market Implementation: Bucketing and Linear Payoffs

Two approaches: bucket the continuous range (e.g. 90k–95k, 95k–100k) into categorical outcomes—simple but resolution-limited; or Long/Short linear payoff (LS-LMSR) with lower bound L and upper bound U, where at result x short pays (U−x)/(U−L) and long pays (x−L)/(U−L), summing to 1. Linear payoff offers infinite resolution but demands more from the oracle and bound setting.

6. Handling Out-of-Bounds Extremes and Precision Issues

Define behavior when results fall outside [L,U]: commonly clamp below L to L and above U to U, keeping payoffs non-negative and summing to 1. Bounds must be wide enough to cover plausible extremes but not so wide that prices lose discrimination. Standardize numeric precision (fixed decimals), specify the snapshot time, and avoid source-specific rounding disputes.

7. The Liquidity Dilution Problem in Multi-Outcome Markets

Capital that provides one depth unit in a binary market is spread across 10 outcomes in a 10-way categorical market, widening spreads and easing price moves. Liquidity efficiency falls with N. Mitigations: cap outcomes per market (typically ≤12–16), attract market makers, quote adjacent outcomes jointly, and aggregate displayed liquidity. Fewer outcomes mean better UX and manipulation resistance.

8. Market Maker Inventory Risk and LMSR Parameter Setting

LMSR parameter b controls liquidity: larger b flattens price response and lowers slippage but costs more to subsidize; smaller b makes prices sensitive and easier to manipulate. For N outcomes, size b by outcome count and target max slippage rather than copying binary settings. Market makers must manage inventory—hedge or re-quote when one outcome is over-weighted to avoid large losses at resolution.

9. Settlement Rules and Oracle Design

Specify before listing: how the winner is determined (source, rule, snapshot time), how ties are handled (categorical ties can split payout proportionally), and what happens on no-result or cancellation (refund at entry or void). Prefer multiple independent sources with median/TWAP and a 24–72 hour dispute window. High-value markets should add human review or UMA-style optimistic oracle dispute, with all evidence retained.

10. Edge Cases: Other Buckets, Candidate Withdrawal, and Event Postponement

Categorical markets often need an "Other" bucket so outcomes are exhaustive. Candidate withdrawal, event postponement, and ambiguous definitions are frequent edge cases: withdrawal can redistribute shares proportionally or refund by rule; postponement needs a maximum wait before voiding; ambiguous definitions must be fixed at creation, not interpreted at settlement. These rules belong in market parameters enforced by contract.

11. User Experience and Implied Distribution Visualization

Multi-outcome markets work best with probability bars or implied-distribution charts: categorical shows per-outcome bars; scalar shows a distribution curve or range. Users should see who the market thinks will win and where a number will land, plus the price sum (highlighting arbitrage when it deviates), max loss, and maturity payout. Explain complex payoffs (Long/Short) graphically so probability shares are not mistaken for spot.

12. Manipulation Risk in Low-Liquidity Outcome Buckets

Thin outcome buckets are easy to manipulate—small capital can move a candidate from 1% to 20%, shaping narrative or arbitraging other platforms. Monitor short-window price moves and position concentration, cap per-account positions per outcome, strengthen monitoring around the settlement window, and delay settlement into dispute when needed. Settle on post-dispute TWAP, not a single-block spot price.

13. Engineering Implementation: Share Ledger and Portfolio Risk

The ledger records per-market, per-outcome balances rather than issuing independent tokens (though ERC-1155 works). Mint/merge, trade, and settlement all use this ledger. Portfolio risk uses worst-case payout: the maximum payable across a user's shares caps their position. Batch settlement uses Merkle trees or off-chain computation with on-chain claims to avoid gas-heavy per-user transfers.

14. SoonTech Multi-Outcome Market Implementation

SoonTech delivers a complete multi-outcome and scalar engine: binary, categorical, and LS-LMSR scalar forms; built-in sum-to-one enforcement and complete-set mint/merge; multi-source oracle with dispute workflow; per-outcome position caps and settlement-window monitoring; share ledger with portfolio risk; batch settlement/gas optimization; and probability-bar/distribution UI components. Deployed across Southeast Asian projects, with compliance and oracle support for fast launch.

15. Enterprise Implementation Recommendations

Start with binary markets (simplest liquidity and compliance), validate oracle and settlement, then add categorical, then scalar. Every market needs exhaustive outcome definitions, clear edge-case rules, and dispute mechanisms; prefer fewer outcomes; settle on dispute-window TWAP. The complexity of multi-outcome markets lies in settlement and manipulation protection, which must be fixed at design time.

FAQ

Q1: How should I choose between multi-outcome, binary, and scalar markets?

A: Use binary for yes/no questions (best liquidity), categorical for choosing among mutually exclusive options, scalar for magnitude. Complexity and manipulation risk rise in that order.

Q2: Can complete-set minting/redemption be abused?

A: It is instead the price anchor—mint/merge enables risk-free arbitrage when the sum deviates. Forbid minting after settlement and keep operations atomic.

Q3: How should scalar bounds be set?

A: Wide enough to cover plausible extremes (so clamping is meaningful) but not so wide that prices lose discrimination; use historical volatility and expert judgment, and specify clamp-at-bound behavior.

Q4: How to address liquidity dilution in multi-outcome markets?

A: Cap outcomes (typically ≤12–16), share liquidity under LMSR, attract market makers, quote adjacent outcomes jointly, and aggregate displayed depth.

Q5: How is responsibility assigned for scalar extremes?

A: The contract fixes clamp rules, data source, precision, and snapshot time at creation; out-of-bounds settles at the bound, unavailable data triggers dispute or void refund—no after-the-fact discretion.

Q6: What is the most gas-efficient payout after settlement?

A: Off-chain payout computation plus Merkle claims, or batch transfers, with only a root stored on chain and users claiming with proofs.

Conclusion

Multi-outcome and scalar markets let prediction markets express "who wins" and "by how much," but their complexity lives in settlement rules, liquidity allocation, and manipulation protection—not the trading interface. Solid price constraints, complete sets, edge-case rules, and dispute mechanisms are what let a platform safely host richer event types.

🌐 Build secure and scalable Web3 platforms with SoonTech.

Explore our solutions for White Label Crypto Exchanges, Prediction Markets, MPC Wallets, Matching Engines, Liquidity Integration, and Compliance.