How to Design an AMM for Binary Outcome Markets

A Binary Outcome Automated Market Maker (BO-AMM) is a specialized liquidity pool for prediction markets where an event has only two possible outcomes, like "Yes" or "No". Unlike a constant product AMM (e.g., Uniswap V2) designed for fungible token swaps, a BO-AMM must manage two assets representing the conditional claims on a single event. The core design challenge is to create a bonding curve that accurately prices these conditional tokens based on the market's implied probability, manages liquidity provider risk, and facilitates a trustless settlement when the event resolves.

The most common pricing model is derived from the logarithmic market scoring rule (LMSR), popularized by platforms like Gnosis (now Omen) and Polymarket. This model uses a cost function, C(q_yes, q_no), where q_yes and q_no are the quantities of Yes and No shares in the liquidity pool. The instantaneous price for a Yes share is the partial derivative p_yes = ∂C/∂q_yes. A typical cost function is C = b * log(exp(q_yes/b) + exp(q_no/b)), where b is a liquidity parameter controlling the spread. When a trader buys Yes shares, q_yes increases, raising p_yes according to the curve, simulating a market moving towards a "Yes" outcome.

Smart contract implementation requires managing two ERC-20 tokens for the outcomes and a settlement mechanism. The core functions are addLiquidity(), buy(), sell(), and resolve(). For addLiquidity, a provider deposits collateral (e.g., USDC) and receives a balanced amount of both Yes and No shares, minting them from the contract. A trader calling buy() specifies an outcome and amount, pays the calculated cost in collateral, and receives the minted outcome shares. The resolve() function is called by an oracle (like Chainlink or a decentralized reality.eth-style oracle) after the event, which redeems all shares of the winning outcome for 1 unit of collateral each and burns the losing shares.

Key design considerations include liquidity provider (LP) risk and oracle security. LPs are exposed to the market's prediction; if they provide liquidity at 50/50 odds and the market moves to 90% Yes, they hold mostly devalued No shares. Impermanent loss is inherent and maximal. Therefore, the b parameter must be set carefully—a higher b means lower slippage but greater LP risk. Oracle security is critical; a malicious resolution steals all pooled collateral. Using a decentralized, time-delayed oracle or a dispute resolution system like UMA's Optimistic Oracle is essential for production systems.

To build a basic BO-AMM, start with a factory contract that deploys individual market pools. Each pool's initialization should set the event description, resolution time, oracle address, and liquidity parameter b. The bonding curve logic can be implemented in a library for gas efficiency. For frontends, you'll need to calculate and display the implied probability (p_yes * 100%), available liquidity, and historical trades. Reference implementations can be found in the Gnosis Conditional Tokens framework and Polymarket's open-source components.

The first prerequisite is selecting a pricing function that maps the probability of an outcome to the price of its token. The most common model for binary markets is the logarithmic market scoring rule (LMSR), popularized by platforms like Augur and Polymarket. The LMSR price for a 'Yes' outcome token is calculated as P_yes = e^(q_yes) / (e^(q_yes) + e^(q_no)), where q_yes and q_no represent the quantity of tokens in each pool. This function ensures liquidity is always available and prices move predictably with trades, but requires careful management of a liquidity parameter b that controls the market's depth and sensitivity.

You must also define the settlement mechanism and oracle integration. A binary market resolves to one of two states: 'Yes' or 'No'. Your smart contract needs a trusted, decentralized oracle (like Chainlink, UMA, or a custom DAO) to report the final outcome. The contract logic must handle the resolution by allowing holders of the winning outcome token to redeem each token for 1 unit of collateral (e.g., 1 USDC), while the losing token becomes worthless. Consider finality delays and dispute resolution processes to prevent oracle manipulation.

Next, architect the core data structures for your smart contract. You will need to manage at least two liquidity pools, one for each outcome. A typical Solidity struct for a market might include: uint256 liquidityParameterB, uint256 poolYes, uint256 poolNo, address collateralToken, and enum MarketState { Open, Closed, Resolved }. The contract must also track user shares in the liquidity pools separately from outcome tokens to accurately distribute fees and losses upon resolution.

A critical design decision is the fee structure. Most AMMs charge a small percentage fee (e.g., 1-2%) on every trade, which is distributed to liquidity providers as compensation for the risk of impermanent loss. In binary markets, this 'loss' manifests if liquidity providers hold pool shares when the market resolves; they lose the collateral backing the losing outcome tokens. Your fee logic must calculate and accrue these fees correctly, often by minting new pool share tokens to represent the accumulated fee revenue.

Finally, ensure you have a plan for initial liquidity provisioning and bonding curves. To bootstrap a market, initial liquidity providers deposit an equal value of collateral into both outcome pools, receiving liquidity provider (LP) tokens in return. The initial deposit determines the starting price (usually 0.5 for each outcome) and the market's depth. The bonding curve, defined by your pricing function, dictates how expensive it becomes to move the price as liquidity is added or removed. Testing this curve extensively is essential to prevent exploits and ensure a smooth trading experience.

A binary outcome market, like a prediction market for an election, has only two possible results: YES (event occurs) or NO (event does not occur). Designing an AMM for this requires a bonding curve—a mathematical formula that defines the relationship between the pool's token reserves and the price of an outcome token. Unlike a constant product AMM (like Uniswap V2), which uses x * y = k, a binary AMM must ensure the prices of the YES and NO tokens sum to 1 (or 100%), representing the certainty that one outcome will happen. The bonding curve enforces this invariant automatically as users trade.

The most common design uses a liquidity pool that holds two assets: collateral (like USDC) and the outcome tokens. When a user adds liquidity, they deposit collateral and mint both YES and NO tokens in a 1:1 ratio, which they can then sell independently. The pricing function, often a logarithmic market scoring rule (LMSR) or a polynomial curve, calculates the price of a YES token based on the current supply in the pool. For example, a simple linear bonding curve could be Price_YES = Supply_YES / (Supply_YES + Supply_NO). As more YES tokens are bought, their price increases non-linearly, reflecting higher perceived probability.

Implementing this requires a smart contract that manages two key functions: buy() and sell(). The buy() function accepts collateral, calculates the price via the bonding curve, mints new outcome tokens for the buyer, and updates the pool reserves. The sell() function does the reverse, burning tokens and returning collateral. Critical considerations include slippage control (large orders drastically move the price in a thin market) and ensuring the contract is fully collateralized so users can always redeem winning tokens for 1 unit of collateral after the event resolves.

Real-world protocols like Polymarket and Augur use variations of this design. Their AMMs often incorporate an additional fee (e.g., 2%) on trades to reward liquidity providers. When the market resolves—say, to YES—all YES tokens become redeemable for 1 unit of collateral each, while NO tokens become worthless. This mechanism creates a powerful, decentralized tool for price discovery and hedging, without needing order books or centralized market makers.

The Logarithmic Market Scoring Rule (LMSR) is an automated market maker (AMM) mechanism designed specifically for prediction markets with discrete outcomes, such as "Yes/No" questions. Unlike constant product AMMs used in DeFi (e.g., Uniswap V2), the LMSR does not hold liquidity in token pairs. Instead, it maintains a liquidity pool funded by a market maker and uses a mathematical scoring rule to price shares representing each possible outcome. Its key innovation is providing bounded loss for the liquidity provider, making it the standard for platforms like Augur and Polymarket.

The core of the LMSR is its cost function, C(q) = b * log( exp(q₁/b) + exp(q₂/b) + ... + exp(qₙ/b) ), where b is the liquidity parameter and qᵢ is the quantity of shares outstanding for outcome i. For a binary market (e.g., "Will ETH be above $4000 on Jan 1?"), this simplifies to C(q_yes, q_no) = b * log( exp(q_yes/b) + exp(q_no/b) ). The price for buying an infinitesimal share of outcome i is the partial derivative of the cost function with respect to qᵢ. This yields a price formula: p_i = exp(q_i / b) / Σ exp(q_j / b).

Implementing the LMSR in a smart contract involves tracking the outstanding share quantities (q_yes, q_no) and the liquidity parameter b. When a user buys Δq shares of "Yes," the contract calculates the cost as cost = C(q_yes + Δq, q_no) - C(q_yes, q_no). The user pays this cost, and the q_yes balance is incremented. The price per share changes smoothly with each purchase, ensuring instant liquidity. The parameter b determines the market's depth; a higher b means lower slippage but exposes the liquidity provider to greater potential (though bounded) loss.

A critical property is the liquidity provider's maximum loss, which is bounded by b * log(N), where N is the number of outcomes. For a binary market, the max loss is b * log(2) ≈ 0.693 * b. If b is set to 1000 DAI, the market maker can lose at most ~693 DAI, regardless of trading volume or outcome. This bounded risk is what makes the LMSR commercially viable. The liquidity parameter b is typically set by the market creator based on desired market depth and their risk tolerance.

Here is a simplified Solidity code snippet for the core cost and price calculations of a binary LMSR:

solidityCopy
// Liquidity parameter
uint256 public b;
// Outstanding shares for YES and NO
int256 public qYes;
int256 public qNo;

function cost(int256 newQYes, int256 newQNo) public view returns (int256) {
    return wmul(b, ln(wadd(wdiv(exp(wdiv(newQYes, b)), expScale), wdiv(exp(wdiv(newQNo, b)), expScale))));
}

function calcCost(int256 deltaQYes) public returns (uint256 payment) {
    int256 oldCost = cost(qYes, qNo);
    int256 newCost = cost(qYes + deltaQYes, qNo);
    payment = uint256(newCost - oldCost);
    qYes += deltaQYes;
}

Note: This uses fixed-point math libraries (wmul, wdiv, ln, exp) for precision.

In practice, building a full prediction market requires additional components: a resolution oracle to report the real-world outcome, a mechanism for users to redeem winning shares for 1 unit of collateral each, and fees to compensate the liquidity provider. The LMSR's elegance lies in its simplicity and robust economic guarantees. For further reading, refer to Robin Hanson's original paper and implementations in the Augur v1 contracts.

Binary outcome markets, where an event resolves to one of two possible states (e.g., "YES" or "NO"), require specialized AMM designs. Unlike traditional constant product AMMs like Uniswap v2, which manage continuous price ranges, a binary AMM must handle a probability space that converges to 0 or 1. The core mechanism often uses a bonding curve, where the price of a "YES" token is defined as a function of its current supply relative to the total liquidity pool. A common model is P_yes = (Y_yes)^k / ((Y_yes)^k + (Y_no)^k), where Y is the token supply and k is a curvature parameter controlling liquidity sensitivity.

Designing the fee structure is critical for sustainability and liquidity provider (LP) incentives. A primary fee is a swap fee (e.g., 1-3%) charged on each trade, distributed proportionally to LPs. This compensates LPs for the risk of impermanent loss, which is magnified in binary markets as resolution nears. Additionally, a protocol fee can be levied (e.g., 10% of the swap fee) to fund development. Fees should be calibrated to balance trader cost against the necessary incentive for LPs to deposit capital, especially in the early, illiquid phase of a market.

Incentive mechanisms must address the unique challenge of liquidity migration at resolution. As the market outcome becomes certain, liquidity in the losing outcome becomes worthless. To encourage continuous liquidity, protocols like Polymarket use a multi-phase model. Before resolution, standard swap fees apply. Upon resolution, the AMM can automatically settle, converting all liquidity into the winning outcome token for redemption. Some designs also implement liquidity mining rewards, distributing a governance token to LPs based on their share of fees generated or time-weighted liquidity, aligning long-term participation with protocol growth.

Smart contract implementation requires careful handling of resolution. A typical Solidity structure involves a BinaryMarket contract that mints conditional tokens (YES/NO) upon liquidity deposit. The swap function uses the bonding curve formula to calculate prices and fees. An oracle (e.g., Chainlink or a decentralized arbitrator) calls a resolve function, which halts trading, sets the winning outcome, and allows users to redeem each YES/NO token for a proportional share of the collateral pool. Code must include access control for resolution and robust event emission for off-chain indexing.

Key design trade-offs involve the curvature parameter k and fee levels. A higher k creates a steeper curve, providing more liquidity near 50% probability but greater slippage near extremes—this suits volatile, uncertain events. A lower k creates a flatter curve, offering stable prices but requiring more capital to depth. The chosen parameters directly impact capital efficiency and trader experience. Successful implementations, such as Gnosis Conditional Tokens (which uses a fixed product market maker model), demonstrate that clear documentation, transparent resolution, and aligned LP incentives are foundational for user trust and market viability.

A binary outcome market involves two assets representing opposite outcomes of a future event, such as YES and NO tokens for a political election. At settlement, one token is worth $1 and the other $0. A standard constant product AMM like x * y = k is unsuitable here, as the pool's value would collapse to zero the moment one token's price deviates from 0.5. Instead, the design must ensure the pool's total value remains stable and converges correctly at resolution.

The core mechanism uses a liquidity invariant that factors in the probability p of an outcome. A common model is the log market scoring rule (LMSR) adapted for constant function market makers. One implementation uses the invariant k = (y + p * L) * (n + (1-p) * L), where y and n are the reserves of YES and NO tokens, L is a liquidity parameter, and p is the implied probability from 0 to 1. The price of a YES token is derived as P_yes = p * L / (n + (1-p) * L).

Impermanent Loss (IL) manifests uniquely. Liquidity providers deposit an equal value of both tokens. If the market probability shifts, the pool rebalances, creating a divergence loss compared to simply holding the tokens. The loss is temporary ('impermanent') until the event resolves. At resolution, IL becomes permanent: LPs win if they backed the correct outcome but receive less profit than a direct holder; they lose less if they backed the wrong outcome. The AMM's fee structure is critical to compensate for this risk.

A practical implementation involves a smart contract that updates the implied probability p based on trades, moving it toward 0 or 1. The contract must also handle the settlement process atomically: locking the pool, redeeming winning tokens for the collateral (e.g., USDC), and distributing proceeds to LPs. Formulas must be optimized for gas efficiency, often using fixed-point math libraries like ABDKMath64x64.

Key design considerations include: - Choosing the liquidity depth L to minimize slippage. - Setting trading fees (e.g., 0.5-2%) to reward LPs. - Implementing emergency settlement oracles. Projects like Polymarket and Augur v2 have pioneered these designs, demonstrating their viability for real-world event prediction.

You now have a functional blueprint for a binary outcome AMM. The core model uses a constant product invariant x * y = k to manage liquidity between YES and NO shares, with a liquidity fee (e.g., 1-3%) to reward LPs. The pricing function price_yes = y / (x + y) ensures the market price reflects the pool's composition. To proceed, you must implement key smart contract functions: addLiquidity(), removeLiquidity(), buyShares(), and sellShares(). Use a library like Solidity's ABDKMath64x64 for precise fixed-point arithmetic to avoid rounding errors in calculations.

For a production deployment, several critical enhancements are necessary. First, implement a dispute resolution mechanism, such as integrating with a decentralized oracle like Chainlink or a custom optimistic challenge period, to finalize the market outcome and enable redemption. Second, introduce dynamic fees that adjust based on trading volume or volatility to better compensate LPs for risk. Third, design a gradual weight update system to slowly shift the pool's k invariant after resolution, preventing instantaneous arbitrage and smoothing the liquidity migration process for LPs exiting a resolved market.

To test your implementation, write comprehensive unit and fork tests using Foundry or Hardhat. Simulate key scenarios: extreme price swings, liquidity provider entry/exit during active trading, and the final resolution payout process. You should also analyze impermanent loss profiles for LPs under different outcome probabilities and monitor the pool's depth to ensure it can handle expected trade sizes. Security audits are non-negotiable before mainnet launch; consider engaging specialized firms like Trail of Bits or OpenZeppelin to review the contract's economic logic and code.

The next evolution of your AMM could explore advanced designs. Research liquidity mining incentives to bootstrap initial pools. Consider proactive market making (PMM) models that use external price feeds to concentrate liquidity around the predicted probability, improving capital efficiency. Alternatively, look into dynamic curve AMMs where the invariant k or fee structure changes based on time to expiration or trading activity, as seen in protocols like Gnosis Conditional Tokens. Each design choice involves trade-offs between capital efficiency, LP risk, and trader slippage.

To continue your learning, explore the codebases of live prediction market platforms. Study Polymarket's use of Conditional Tokens (CTFs) on Polygon, Augur v2's reporting system on Ethereum, and PlotX's non-custodial prediction markets. The UMA Protocol documentation offers deep insights into designing priceless financial contracts and dispute resolution. For community discussion and collaboration, engage with developer forums on the Polymarket Discord, Augur's community Discord, and Ethereum Research forums where novel AMM designs are frequently proposed and debated.