Parlays are capital-intensive in fully collateralized prediction markets because each ticket is often collateralized in isolation. This post shows how market makers can reduce required collateral by computing worst-case portfolio exposure with integer linear programming.
This collateral engine does not price parlays or estimate correlations. Pricing decides whether a market maker should quote a trade. The collateral engine decides how much collateral must be reserved after the trade exists.
Why Parlays Lock So Much Market-Maker Capital#
Combo bets are one of the most natural products in prediction markets: small stakes, expressive views, and huge upside. I have argued separately that they are the most important missing derivative for markets that are not sports-related. The enhanced user experience is obvious. The market structure behind it is not.
In a fully collateralized prediction market, every dollar a user can win needs to be backed by someone else's dollar. If a user bets $100 on a long-shot parlay with a 1% chance of hitting, they can win roughly $10,000. In a fully collateralized system, the market maker on the other side needs to have that $10,000 available to pay them.
Traditional sportsbooks can live with latent risk across millions of wagers. They do not fully cash-collateralize every single parlay ticket in an escrow account. They manage a book, throttle exposure, price in margin, and rely on the empirical reality that not every long-shot combination hits at once.
Prediction market exchanges and their market makers do not get that same luxury. Bernard Marantelli of White Swan put the scale of it plainly in a July 2026 interview: when a 10 million-to-1 parlay transacts, a market maker has to supply $10 million of capital, because these are exchange contracts and they need to be fully collateralised. If every combo bet is collateralized in isolation, the market maker has to post the worst-case payout for every ticket, even when many of those tickets cannot all win in the same world. That is what isolated margin means in practice: the risk on each trade is ring-fenced to that position only.
A Two-Position Example#
A market maker holds two positions.
Position 1. User wins if BTC closes above $100k AND ETH closes above $5k. Market maker exposure: $100.
Position 2. User wins if BTC closes below $100k AND ETH closes above $5k. Market maker exposure: $80.
Collateralized in isolation, the market maker posts $100 + $80 = $180. But it is impossible for the market maker to lose both. BTC cannot close both above $100k and below $100k.

That is the core problem: long-tail combo bets are attractive to users, but expensive for counterparties. The more expressive the product becomes, the worse the collateral problem gets. A few long-shot parlays are manageable. Thousands or millions of them can trap enormous amounts of market-maker capital, especially when the system blindly adds up every standalone worst-case payout.
A simple solution is to aggregate all of a market maker's open trades and calculate the worst-case loss across the entire portfolio. For the example above, that is max($100, $80) = $100.
Why Enumerating Every Outcome Does Not Scale#
So how do we calculate the market maker's worst-case loss across all markets they are exposed to?
The naive way is to enumerate every possible outcome. Prediction markets resolve to binary outcomes, so each market has two possible states: YES or NO. With active positions across n markets there are 2n possible outcome states. For each state we could calculate which combo bets pay out, sum the losses, and take the maximum.
This is infeasible. At 30 markets there are more than a billion states to check, and independent market makers can have positions across hundreds or thousands of markets.
Formulating Worst-Case Exposure as an Integer Linear Program#
Instead of checking every possible world one by one, we can formulate the problem as an integer linear program, or ILP.
An ILP is an optimization problem with three parts. Variables are the decisions the solver is allowed to make. The objective is the value it tries to maximize or minimize. Constraints are the rules that define which solutions are valid.
Here the variables represent market outcomes and whether each position loses. The objective is to maximize the market maker's total loss. The constraints encode the logic of each combo bet: a position only pays out if every leg resolves in the user's favor. The output is the market outcome that creates the largest valid loss, and that loss is the minimum required collateral.
Define a binary variable for each market m:
xm ∈ {0, 1}
1 means the market resolves YES, 0 means it resolves NO.
And one for each parlay position p:
yp ∈ {0, 1}
1 means the market maker loses position p, 0 means it does not.
With ep the amount the market maker loses if position p pays out, the objective is:
maximize ∑p ep · yp
Choose the market outcomes that maximize the total amount the market maker loses.
The Constraints That Encode a Parlay#
Each parlay position is made up of legs, and a position only pays out if every leg resolves in the user's favor. So every leg adds one constraint.
If position p requires YES on market m, the market maker can only lose it when that market resolves YES:
yp − xm ≤ 0
The position cannot be marked lost unless that market resolves YES.
If position p requires NO on market m, the market maker can only lose it when that market resolves NO:
yp + xm ≤ 1
The position cannot be marked lost unless that market resolves NO.
Those two inequalities are the whole encoding. Every leg of every position becomes one row, and the solver is left to find the world that hurts most.
The Example as an ILP#
Written out, the two positions above become:
xBTC, xETH ∈ {0, 1} y1, y2 ∈ {0, 1}
maximize 100y1 + 80y2
y1 − xBTC ≤ 0
y1 − xETH ≤ 0
y2 + xBTC ≤ 1
y2 − xETH ≤ 0
The first two rows are position 1's YES legs; the third is position 2's NO leg on BTC, the fourth its YES leg on ETH.
The third row is what does the work. Setting y2 to 1 forces xBTC to 0, while the first row needs it at 1 for y1. The solver cannot take both, so the objective tops out at 100, exactly the figure the outcome table gives.
Solving It#
Once the portfolio is an ILP, mature solvers take over. They use LP relaxation to solve a continuous version of the problem and establish a bound, branch and bound to explore the remaining integer possibilities while pruning regions that cannot improve the answer, and cutting planes to remove fractional solutions without excluding any valid integer one.
The details of those techniques are well studied and out of scope here. The important point is that we never enumerate the worlds ourselves. Once the portfolio is expressed as variables, constraints and an objective, the solver searches for the worst case directly.
Our collateral engine solves the ILP with HiGHS through scipy.optimize.milp, which wraps that solver and is deterministic. On realistic market-maker portfolios it recalculates the worst-case loss after any position change in milliseconds.
What the Reduction Looks Like in Practice#
How much collateral this frees depends heavily on the portfolio. From backtests against our own markets:
- 20 to 40% for market makers quoting only category-specific parlays, such as a single major sports league.
- 10 to 30% for generalist market makers with exposure across hundreds or thousands of markets.
- Upwards of 70% for market makers quoting heavy long-tail parlays of four or more legs.
The pattern is intuitive. The more mutually exclusive worlds a book contains, the more of its naive collateral is reserved against outcomes that cannot co-occur, and the more an exact worst-case calculation gives back.
For market makers, this means less idle capital locked against impossible outcomes. For users, it means tighter quotes, deeper liquidity, and more expressive combo bets. For prediction markets as a whole, it lets parlays trade closer to sportsbook capital efficiency without giving up the fully collateralized guarantees that peer-to-peer settlement requires. At Totalis those guarantees are what the Solana vaults enforce, and the quotes market makers stream into each request are priced against capital this engine has already freed. Build a parlay →
FAQ#
What is the difference between pricing a parlay and collateralizing one?#
Pricing decides whether a market maker should quote a trade at all, and at what payout. Collateral decides how much capital must sit idle once the trade exists. The engine described here does only the second job. It takes positions as given and computes what must be reserved against them.
Why does collateralizing each position separately overstate the risk?#
Because it sums worst cases that cannot happen in the same world. Two positions that need opposite resolutions of the same market can never both lose, but a per-position calculation reserves for both anyway. Summing worst cases is only correct when every position can lose simultaneously.
Why not just enumerate every outcome?#
The state space doubles with each market. Thirty markets is already over a billion combinations, and a working book can touch hundreds or thousands. An ILP solver reaches the same answer without visiting the worlds that cannot possibly be the worst.
Does this reduce the guarantees behind a position?#
No. The requirement is still the exact worst-case loss across the portfolio, computed rather than estimated. Nothing is netted on a probabilistic basis and no correlation is assumed. What goes away is collateral held against combinations that are logically impossible.
How much capital does this actually free?#
Between 10% and 70% in our backtests, depending on the book. Concentrated category books and long-tail multi-leg books benefit most, because they contain the most mutually exclusive outcomes. Generalist books benefit least.
Does Totalis solve this for its market makers?#
Yes. This is the collateral engine behind Totalis parlays, not a proposal. Every time a maker's book changes, worst-case portfolio exposure is recomputed as an ILP, so the maker reserves against the worst world that can actually occur rather than the sum of worlds that cannot. Makers quoting on Totalis therefore hold less idle capital against the same book, and that shows up for users as tighter payout multiples and the ability to get long-tail combinations quoted at all.
Does this apply to combos as well as parlays?#
Yes. The encoding cares only that a position pays when a specific set of binary markets resolves a specific way, which is true whatever the venue calls the product. The naming difference between combos and parlays does not change the mathematics.
