Wager Predict Whitepaper.

Wager Predict is a decentralised, non-custodial prediction-market protocol deployed on BNB Smart Chain. Users trade outcome shares that redeem for 1 USD each if the corresponding outcome occurs and zero otherwise. Liquidity is automated via a Logarithmic Market Scoring Rule (LMSR) market maker parameterised by a liquidity parameter, b, and funded by a creator-paid seed of b · ln(2) USD per binary market, which bounds the market maker's worst-case loss regardless of trader behaviour.

This document specifies the full protocol: the mathematical basis for the market maker, the on-chain state machine, the fee and subsidy economics, the resolution and dispute mechanism, the off-chain indexing layer, and the governance and token model. It is intended to be readable by auditors, builders, and sophisticated users, and to serve as a reference for every deployed parameter.

The central contribution is not a new market-making algorithm (LMSR is thirty years old), but a deployable instantiation that closes several well-known footguns: creator-impermanent-loss drain, unbounded protocol liability, sell-side slippage asymmetry, and ambiguity around voided markets. Each design choice is justified in the sections below against a named attack.

Throughout this paper:

• n denotes the number of outcomes in a market. This document focuses on the binary case, n = 2, unless stated.
• q_i (or q_A, q_B) denotes the outstanding share reserve on outcome i: the sum of all shares ever bought on that side minus all shares ever sold back.
• b denotes the LMSR liquidity parameter. Units: 18-decimal fixed-point, USD-denominated.
• p_i denotes the implied probability of outcome i under the current reserves.
• C(q) denotes the LMSR cost function; ΔC denotes the USD moved by a trade.
• USD amounts are in 6 decimals on-chain; share amounts are in 18 decimals. Conversions happen explicitly in the contract and are highlighted where relevant.
• A market is a single binary question with an expiry, a creator, a resolution source, and two outcome tokens (A and B, rendered as YES and NO).
• A position is a wallet's outstanding (sharesA, sharesB) tuple on a given market.

The canonical implementation uses @prb/math's SD59x18 fixed-point type for all LMSR computations. All inequalities and bounds below refer to the integer post-rounding output of those operations.

Decentralised prediction markets have been attempted continuously since 2015 and have converged on three dominant market-making architectures:

Order-book designs dominate in liquid markets but fail in the long tail where the majority of prediction-market questions live (single market, low dollar volume, episodic activity). CPMM designs solve the long-tail case but force the liquidity provider (typically the market creator) to absorb unbounded impermanent loss as public sentiment converges on the correct outcome.

LMSR is the original answer to exactly this problem: a scoring rule invented by Robin Hanson in 2003 that subsidises a market with a fixed, bounded loss and provides quoted prices at every depth. Its adoption has been constrained on EVMs by gas cost of the log / exp operations, which has now been brought within budget by @prb/math's SD59x18 arithmetic.

Wager Predict's contribution is a complete LMSR deployment: a creator-paid seed with a known, bounded maximum loss, symmetric buy/sell fees, bounded protocol liability, and a resolution stack with economic finality.

Goals, in decreasing priority:

1. Non-custodial. No operator can move user funds. Every trade, payout, and refund routes through an audited immutable contract.
2. Liquidity without creators underwriting IL. A creator of a market should not be exposed to open-ended impermanent loss when the crowd's belief moves. The creator's seed is the most it can lose.
3. Bounded protocol liability. The protocol's worst-case loss per market is a known, fixed constant chosen at market creation.
4. Symmetric buy / sell. Sell-side trades should experience the same fee and slippage behaviour as buys. Users should never feel trapped.
5. Economic finality. Market resolution is not trust-based; incorrect resolutions cost the resolver capital.
6. Public indexability. All market state is reconstructible from on-chain events alone; the indexer is a cache, not an oracle.

Non-goals:

• Multi-outcome markets in the current version. The LMSR derivation generalises to n outcomes, but the contract implements n = 2 only.
• Cross-chain state. The protocol is deployed on a single chain; bridging is out of scope until token launch.
• Privacy. All trades and balances are public.
• Fiat on-ramps. Collateral is USDW (0xe5eBE2AE0a036C955bfF58291826C50F7d670D43, 6 decimals); users wrap USDC into USDW before trading.

The Logarithmic Market Scoring Rule defines a cost function over the outstanding share reserves q = (q_1, …, q_n):

C(q) = b · ln( Σᵢ exp(qᵢ / b) )

The SpotEngine holds a dedicated balance of C(q) USDW per market (in 18-decimal internal units) at all times. This is the market's solvent collateral. A trade that moves reserves from q to q' moves ΔC = C(q') − C(q) USD from trader to contract (on a buy) or contract to trader (on a sell).

For the binary case:

C(qA, qB) = b · ln( e^(qA/b) + e^(qB/b) )

At market creation, qA = qB = 0, giving:

C(0, 0) = b · ln(2)

This initial value is the seed: the USDW that the market creator deposits into the market at creation. It is the worst-case amount the protocol can lose; see Section 06.

Path independence. Because C depends only on the endpoint reserves, any sequence of trades that returns the reserves to their starting state returns the contract to its starting balance. Traders therefore cannot "pump" the market into a state where the contract owes more than C(q).

Convexity. C is convex in q, which means buying shares on any single side increases marginal cost strictly monotonically. This gives deterministic price impact and rules out arbitrage via trade splitting.

Claim. In an LMSR market with parameter b and n mutually exclusive outcomes, the market maker's worst-case loss is bounded by:

L_max = b · ln(n)

For the binary case: L_max = b · ln(2) ≈ 0.693 · b.

Proof sketch. At resolution, the winning outcome's shares redeem for 1 USD each and losing shares redeem for 0. The market maker's terminal balance is therefore:

payout(w) = q_w · 1 USD

where w is the winning outcome. The market maker's total intake over the life of the market is C(q) − C(0), where q is the reserve vector at resolution. Net maker PnL is:

PnL = C(q) − C(0) − q_w

Substituting the cost function and letting m = max_i q_i:

C(q) − C(0) = b · [ln(Σᵢ e^(qᵢ/b)) − ln(n)]
           ≥ b · [ln(e^(m/b)) − ln(n)]
           = m − b · ln(n)

Since q_w ≤ m, we have:

PnL ≥ m − b · ln(n) − q_w ≥ −b · ln(n)

Thus the maker's loss is bounded by b · ln(n), independent of trader behaviour and the realised outcome. ∎

Practical implication. At the minimum b = 500 USD, the maximum net loss of a binary market's seed is ~346.57 USD; at the self-serve default b = 866 it is about 600 USD. This holds regardless of any combination of buys, sells, outcome flips, or trade sizes. This is the single most important property of the chosen market maker.

The marginal price of outcome i (the price an infinitesimally-small buy would pay) is the partial derivative of the cost function:

p_i(q) = ∂C/∂q_i = exp(q_i / b) / Σⱼ exp(q_j / b)

This is the softmax function over scaled reserves. It has several properties worth stating explicitly:

• Prices are always strictly between 0 and 1, even when a side has zero shares.
• Prices sum to 1 exactly; no numerical drift is possible.
• Prices are invariant under adding a constant to all reserves (a hidden symmetry that the contract exploits to avoid overflow; see Section 19).
• The price curve is smooth; there are no cliffs at zero.

Why this matters. The naive ratio q_i / Σ q_j (used by parimutuel markets) collapses to 0 or 1 whenever a single side has zero shares. The indexer in a prior iteration of this protocol used the naive ratio for chart snapshots, which caused the market-detail chart to show 100/0 the instant anyone traded only one side. The LMSR price function fixes this at the source.

The three quantities that define a market-maker's microstructure are price impact, effective spread, and depth.

Price impact. A buy of size Δq on outcome i shifts the implied probability from p_i to:

p_i' = 1 / (1 + (1 − p_i) / p_i · exp(−Δq / b))

The larger b, the smaller the impact for a given USD size. b is literally a depth parameter.

Effective spread. The fee schedule (see Section 10) charges 2.0% per trade (1.0% platform + 0.1% creator + 0.8% depth + 0.1% LP). This fee widens the effective spread: a trader who buys then immediately sells recovers the midprice minus 2.0% minus any LMSR slippage incurred on both legs. Slippage on each leg depends on the market's depth (its liquidity parameter b): the deeper the market, the smaller the slippage for the same trade size.

Depth. The LMSR depth at a probability level p (the USD required to move the price by a given amount Δp) scales linearly with b:

USDC_to_shift ≈ b · ln(p' · (1 − p) / (p · (1 − p')))

This gives protocol operators a direct lever: doubling b doubles depth but also doubles the worst-case protocol subsidy loss. Section 13 discusses the calibration.

A market moves through a deterministic state machine held in MarketRegistry. A market is created self-serve with a seed and a validity bond, waits in review, and becomes tradeable once listed. Trading stays open until the end date. The market then moves to resolution: propose, dispute window, finalize.

The dispute window scales with money at stake: 12 hours on small markets, growing to 48 hours as stake rises. See Section 14 for parameter calibration.

Once Resolved, winning shares redeem 1 USDW each via claimWinnings. Once Void, each share redeems via claimWinnings at the market's price at the moment of void: YES at the YES price, NO at the NO price.

Every buy and sell pays a 2.0% fee, split four ways:

• 1.0% platform fee → the protocol treasury (the governance Safe). Planned after the $WP TGE (not live): 30% of this routes to a TWAP buyback (half burned, half to resolution-staking rewards). See Section 30.
• 0.1% creator fee → market creator's address
• 0.8% depth fee → stays in the market to deepen liquidity, funding per-market b growth from organic volume
• 0.1% LP fee → liquidity-provider yield

These are calculated on the gross USD moved, not the net. For a buy of x USD, the contract pulls x from the trader, routes 0.01·x to the treasury, 0.001·x to the creator, 0.008·x to the market's depth reserve and 0.001·x to the LP fee sink, then applies the remaining 0.98·x against the LMSR cost function to compute shares out.

Lifetime revenue, on-chain. Lifetime platform revenue is readable on-chain at any time from FeeRouter.totalPlatformFees() (FeeRouter 0x186DCA432CE9f9B5618fcBb7231a6bE3FcEAe454), which updates on every trade. Each increment also emits PlatformFeeBooked(amount, lifetime).

Comparison.

The lifetime creator fee rewards creators for every trade on their market, for as long as it trades. The scarce resource in prediction markets is not liquidity (LMSR provides it algorithmically) but well-specified, resolvable questions. Creators should have enough cashflow to treat market-making as a serious activity.

Both buyShares and sellShares charge the full 2% fee and both apply the LMSR cost function. This breaks a common failure mode where users feel "trapped" in a position because exiting is punitively expensive.

Sell accounting. A sell of Δq shares on outcome i pays the trader C(q) − C(q') USD less 2% in fees, where q' has q_i − Δq on outcome i. Shares are burned from the trader's position and q_i decrements on-chain.

Trading window. Buys and sells stay open until the market's end date. After that, the market moves to resolution and trading stops. See Section 15.

Each market's seed, C(0) = b · ln(2) USDW, is paid by its creator at creation through createMarketSelfServe, together with a refundable validity bond. This seeds the LMSR cost function with the bounded-loss guarantee from Section 06.

Solvency. The market's collateral covers the LMSR cost C(q) at every state, plus the depth fee retained from trading. Solvency is checked by invariant tests in the protocol test suite.

Settlement. On resolution, each winning share redeems for 1 USDW. On void, each share redeems at the market's price at the moment of void (YES at the YES price, NO at the NO price). The validity bond is returned to the creator once the market resolves.

The choice of b is the single most important parameter in LMSR. It trades off three things:

• Protocol subsidy cost: linear in b. Double b, double the worst-case loss per market.
• Depth: linear in b. Double b, the USD required to shift the price by a fixed amount doubles.
• Price sensitivity: the smaller b, the more responsive the market is to new information.

Bounds. b is bounded between 500 and 100,000. Self-serve markets default to b = 866 (about $600 of seed). Featured markets are seeded higher. Price impact per trade depends on the market's depth, set by b: the deeper the market, the less a trade of the same size moves the price.

Choosing b. Smaller b suits markets where creators expect low volume and want tighter price discovery; larger b suits anticipated-high-volume markets where smooth price action matters.

Why a range, not a free float. Below the floor a market is effectively illiquid and a single small bet moves the price sharply. Very large b means a seed that exceeds the expected fee revenue of the market. The trade-off can be expressed as the break-even volume under a 2% fee:

break_even_volume = b · ln(2) / 0.02 ≈ 34.65 · b

so a creator choosing b = 10,000 must generate ≥ ~346,500 USD in lifetime volume for the protocol to be neutral on that market.

The resolver proposes an outcome and posts a proposer bond of at least $20, scaling at 0.05% of money at stake. Anyone can dispute by posting 50x that bond. Disputes are settled by the resolver role.

The dispute window is 12 hours on small markets, growing to 48 hours as money at stake rises. A proposal that survives the window finalises.

Calibration target: the bond must exceed the maximum expected profit an adversary could earn by pushing a false outcome through. That profit is bounded by the outstanding shares on the market's actual losing side, so the bond scales with money at stake rather than staying flat.

Dispute window length. Scaling the window balances user experience (fast payouts on small markets) against the time a disputer needs to notice a false proposal, locate source material, and post the bond on markets where more is at stake.

Trading stays open until the market's end date. Once the end date passes, buyShares and sellShares revert and the market can be moved to Resolving, permissionlessly.

Creators should set the end date at or before the moment the outcome becomes knowable, so the market stops trading before the result is public. Buys and sells close together, so a holder cannot dump shares against the pool after the outcome is known.

We enumerate the actors and their capabilities. Each attack in the next section is evaluated against this model.

• Rational trader. Profit-maximising. Has arbitrary USD. Can submit arbitrary transactions but cannot forge signatures, reorder blocks beyond short-term MEV, or alter oracle state.
• Market creator. Rational trader who also selects b, the market text, a market template and a resolution source, and pays the seed and validity bond.
• Resolver. The address holding the resolver role, which is the governance Safe during the beta. It proposes outcomes and arbitrates disputes.
• Disputer. Any wallet willing to post a dispute bond (50x the proposer bond). Can escalate a resolver proposal.
• MEV searcher. Rational trader who additionally controls transaction ordering within a block (via private relayers or validator collusion).
• Sybil cluster. A single economic actor operating arbitrarily many wallets.
• External oracle adversary. An actor who can manipulate the real-world event being predicted, or the sources that resolvers use.

We do NOT trust: trader rationality, creator honesty, or resolver honesty in isolation. Every economic guarantee must survive one of those breaking.

Creator IL drain (closed). In CPMM-style markets, the creator's liquidity is the losing side's payout. A creator who funds a $1,000 AMM can be drained as sentiment converges. LMSR's bounded loss closes this: the creator's seed of b · ln(2) is the most it can lose, regardless of how sentiment moves.

Wash trading. Round-trip trades on a single market generate no PnL for the wash trader (2% fee round-trip) and no impact on implied probabilities beyond noise. Wash-based volume-pumping for leaderboard inflation is dissuaded by the explicit fee cost; the frontend also flags wallets exceeding 50 bets / 24h or <10s inter-trade intervals via wallet_activity.

Sybil for subsidy extraction. An attacker opens many markets to farm subsidies. Mitigated by: (a) each creator pays the market's seed plus a validity bond at creation; (b) markets are only tradeable after review and listing by the governance Safe.

Oracle manipulation. A resolver proposes a false outcome. Mitigated by the 12h to 48h dispute window and bond slashing. Residual risk: the permissioned resolver set colludes on a market below the dispute threshold, addressed by resolver rotation and limited parameter scope (Section 25).

Liquidity sniping. A trader sees a new market, buys on one side immediately, then exits as the crowd corrects. This is the intended behaviour of an AMM: providing this arbitrage is how LMSR achieves price discovery. The protocol captures 2% of every leg, so this is a revenue mechanism, not a vulnerability.

MEV / front-running. A searcher observes an incoming trade in mempool and front-runs. LMSR's convexity bounds the impact: the victim pays the marginal price after the front-runner, but the front-runner's exit costs them the other direction. Net effect at small sizes is a few basis points of extra slippage.

Griefing via mass-void. An adversary tries to force a market void to recover stake on a losing bet. Requires corrupting the resolver set AND surviving dispute; not economic.

Expiry-timestamp manipulation. Validators can skew block.timestamp by ~±15s. This is immaterial against an end date set ahead of the outcome and a 12 to 48 hour dispute window.

The mitigations for each attack above are structural: they arise from protocol mechanics (bounded loss, bond forfeiture, trading closing at the end date, symmetric fees) rather than from detection or reactive measures. This is deliberate. Detection-based systems produce false negatives at the worst possible time.

Residual risks.

• Resolver collusion on undisputed markets. If no disputer acts within the dispute window, a false proposal finalises. Mitigated by community bounty for discovering false proposals; no structural fix.
• Real-world event manipulation. The protocol cannot distinguish "Team A won the game" from "Team A bribed the ref". Out of scope.
• Upstream RPC censorship. A single RPC provider could reject transactions. Mitigated by frontend-side fallback RPC list; full fix requires user-operated RPC.
• Known-unknowns. The dispute-bond calibration for very large b has not been empirically tested. Bond economics are governance parameters and will be revisited as volume grows.

The protocol runs as a set of single-purpose immutable contracts:

• MarketRegistry: creates and lists markets, and holds each market's lifecycle state.
• SpotEngine: runs the LMSR curve (buy, sell, claim).
• FeeRouter: splits trade fees and records lifetime platform revenue in totalPlatformFees.
• ResolutionModule: handles propose, dispute and finalize.
• ProtocolConfig: holds every tunable parameter (fees, bonds, b bounds, windows).
• AccessController: manages roles.
• PredictTimelock: delays governance changes (3-hour minimum).
• Supporting contracts: MarketTemplates, OutcomeToken, InsuranceFund, Vault (LP deposits), ExchangeSettlement and LmsrAsMaker (order-book tier, not live), MMRegistry, NoLeverage (leverage disabled) and MigrationDisabledGate (migration to the order book blocked).

Collateral is USDW (0xe5eBE2AE0a036C955bfF58291826C50F7d670D43, 6 decimals), the ecosystem's USDC wrapper pegged 1:1 to USDC; see Section 20. Addresses for every contract are listed in Appendix B.

Storage layout. Every market lives in a Market struct keyed by uint256 marketId in MarketRegistry; curve reserves and per-user shares live in SpotEngine.

LMSR arithmetic. Computed with @prb/math's SD59x18 signed 59.18 fixed-point type. To prevent overflow when q_i / b is large, the contract subtracts max(q_A, q_B) from both arguments before exponentiating. This is the invariance property from Section 07. The worst-case input to exp is therefore 0, and the worst-case output is 1.

Upgrade posture. The contracts are not upgradeable. There is no proxy, no admin upgrade function. Changes to contract logic ship as a new deployment, as with the 5 October 2026 redeploy that added the on-chain revenue counter. New market types (multi-outcome, scalar, conditional) will be deployed as separate contracts.

Pausing. SpotEngine exposes pause() to the pause guardian (the governance Safe) for emergency stop. buyShares and sellShares are pausable; claimWinnings always executes.

Every market on Predict is denominated in USDW. USDW is the ecosystem's wrapper around USDC: a 6-decimal token on BNB Smart Chain (0xe5eBE2AE0a036C955bfF58291826C50F7d670D43) pegged 1:1 to USDC. Each USDW is minted against one USDC deposited into the wrapper, and each USDW is redeemed for one USDC on withdrawal.

Why a wrapper. USDW gives the ecosystem one dollar unit of its own instead of tying every contract directly to an external stablecoin. Products built on Predict share that unit, so the same USDW balance can move between them as new products and features launch, without a separate deposit for each. It is the base layer for building the wider ecosystem, starting with the prediction market.

The peg. 1 USDW = 1 USDC. Depositing 100 USDC mints 100 USDW; withdrawing 100 USDW returns 100 USDC. The protocol prices, settles and pays out in USDW, so a dollar in a market is a dollar of USDC.

Depositing. The app's Deposit action converts USDC in your wallet into USDW at 1:1 in a single transaction, after a one-time USDC approval. The accepted deposit asset on BNB Smart Chain is USDC (Binance-Peg USDC, 0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d). Balances in the app are shown in dollars.

Withdrawing. You can withdraw USDW back to USDC from the app at 1:1.

Precision. USDW tracks balances to six decimal places, one millionth of a dollar. USDC on BNB Smart Chain uses 18 decimals; the wrapper converts between the two on deposit and withdrawal, so the protocol's contracts only ever handle 6-decimal USDW. Each contract checks this at deployment and rejects any collateral token that is not 6 decimals.

Inside the protocol. Market seeds, validity bonds, trades, fees and payouts are all in USDW. A winning share redeems for 1 USDW, and lifetime platform revenue (FeeRouter.totalPlatformFees) is counted in USDW.

The indexer is a read-only view layer; it provides no privileged data and can be rebuilt from on-chain events alone. Its sole job is to make queries like "all bets by wallet X" or "odds history for market 42" fast for the frontend.

Pipeline.

1. A self-hosted log poller reads events from the protocol contracts, 15 blocks behind the chain head for finality.
2. The backend (Express / TypeScript) keeps only events from the protocol contracts and their known event signatures, and writes them to Supabase (Postgres).
3. The Next.js frontend reads from Supabase via a REST API layer that mirrors the event model.

Reorg handling. The poller only processes blocks at least 15 blocks below the chain head, and re-scans a small margin below its cursor on every pass. This is deeper than typical BSC reorg depth and sufficient for the protocol's use case.

Cold start / backfill. A standalone backfill script reads events from a specified BACKFILL_FROM_BLOCK through getLogs, replays them deterministically into the Supabase tables, and is idempotent via unique transaction_hash constraints. This is run on deploy and on any indexer outage.

Failure posture. If the indexer goes down, the frontend's on-chain paths continue to work: useMarkets, useUserShares, getOdds all read directly from the contract. The degraded UX is that "X minutes ago" timestamps and leaderboard lose freshness; the trading and payout paths are unaffected.

The frontend is a Next.js 14 App Router application written in TypeScript, using wagmi + viem for chain interaction and RainbowKit for wallet connection. It is hosted on Netlify; all chain writes are signed in the user's wallet.

RPC fallback. The frontend configures a fallback-ordered list of BSC RPCs. The first alive one wins; failures cascade.

Read batching. Dashboards fetch per-market shares / odds / netSpent / claimed via wagmi.useReadContracts, which wraps them in a single multicall3 RPC round-trip. A portfolio view with 50 positions makes 1 RPC call instead of 200.

Refresh semantics. The frontend polls the on-chain event feed every 8s and the indexer every 15s. Both refresh immediately on a successful trade so new trades appear in the feed and chart without a page reload. See the useBetEvents + RecentBets merge logic for the race-condition handling.

Animation + perf. Market grids virtualise above a 50-item threshold; portfolio reads are batched; chart redraws skip when the tab is hidden; DPR is clamped at 2 for canvas charts.

A clear boundary between on-chain and off-chain data:

Every off-chain primary view is reconstructible from the event log. The indexer is a cache, not a trust root. If every off-chain provider vanished tomorrow, a new operator could replay events from genesis and rebuild every view in hours.

Resolution is a propose → dispute → finalize flow:

1. Propose. After the end date, the resolver calls propose on ResolutionModule and posts a bond of at least $20, scaling at 0.05% of money at stake.
2. Dispute window. For 12 hours on small markets, growing to 48 hours as money at stake rises, anyone can call dispute by posting 50x the proposer bond.
3. Finalize. If the window elapses with no dispute, anyone can call finalize. The proposal becomes the resolved outcome and the proposer recovers their bond.
4. Arbitrate. A disputed proposal is settled by the resolver role. The winning side takes the bonds.

Why this works. An honest proposer forfeits nothing. An adversarial proposer of a false outcome loses their bond to any single honest disputer. The only way an adversary wins is if nobody disputes within the window, a scenario bounded by community incentive, not structural guarantee.

Resolver set. During the mainnet beta the resolver role is held by the 2-of-3 governance Safe; permissionless resolution is off. Post-TGE, the resolver set may rotate via $WP governance (Section 25).

Voiding. If a question cannot be resolved (e.g. the resolution source no longer exists), the market is voided and each share redeems via claimWinnings at the market's price at the moment of void (YES at the YES price, NO at the NO price).

The protocol is operated by the team, through the 2-of-3 governance Safe, during the mainnet beta. Governance transfers to a $WP-staked DAO at TGE + 3 months.

Scope. Governance can set the following, within limits enforced on-chain by ProtocolConfig. Every change goes through the 3-hour timelock:

• Which addresses hold the resolver role (granted through AccessController)
• The b range for creator-selectable liquidity
• The dispute window (bounded: up to 30 days)
• The resolution bond floor (bounded: up to $1M) and the validity bond (bounded: up to $100k)
• The fee schedule (bounded: total trade fee at most 5%, split freely between the four slices)
• Treasury spending from the governance Safe
• New market-type deployments (multi-outcome, scalar)

DAO cannot:

• Upgrade the core contract. (It's immutable.)
• Confiscate user positions or funds.
• Change the resolved outcome of a finalised market.
• Modify user share balances.

Timelock. Parameter changes go through PredictTimelock (0x8f1B33cfDdF0A2Da5a4dDa1E6250c02915ad8CE2) with a 3-hour minimum delay, proposed and executed by the 2-of-3 governance Safe (0xF39342C6758156df432fc47cDfF0cDd593E6CcC0). The Safe can pause trading immediately in an emergency.

Because the core contracts are immutable, "upgrades" mean new deployments, as with the 5 October 2026 mainnet redeploy. A contract with multi-outcome support would be a new address with the same governance Safe and treasury.

The app points at one deployment at a time. Markets on retired contracts settle there and are not shown in the app.

This approach accepts that some operational complexity (a new deployment and a cutover of the app and indexer for each upgrade) is the cost of avoiding upgradeability's two failure modes: admin keys that can change contract behaviour, and proxy storage collisions that cause silent data corruption.

$WP is a BEP-20 token on BNB Chain with a fixed supply of 30,000,000,000. It serves five purposes:

• Market resolution staking. Stake $WP to participate in dispute resolution. Honest resolvers earn a share of protocol fees; addresses that propose or affirm a losing outcome have their stake slashed and distributed to the winning side.
• Fee discounts. Tiered platform-fee reductions for $WP holders and stakers, scaling with stake size.
• Governance. Token-weighted voting on fee rates, supported markets, treasury deployment, and oracle integrations (Section 25).
• Liquidity mining. Market makers and active traders earn $WP for providing depth and non-wash volume. Wash activity is filtered using the same heuristics described in Section 17.
• Market creation. Today, creating a market requires a USDW seed plus a refundable USDW validity bond; no $WP is involved. Planned after the $WP TGE: a small $WP bond, returned on clean resolution, as a spam filter.

Value accrual. Today the 1.0% platform fee goes to the governance Safe. Planned after the $WP TGE: 30% of every protocol fee routes into a buyback program executed via TWAP on the canonical USD/$WP pool. 50% of the bought-back tokens are burned permanently; the remaining 50% recirculates to the resolution-staking reward pool. This couples token value to protocol throughput without relying on emissions.

Fixed supply of 30,000,000,000 $WP (BEP-20, BNB Chain), no inflation. Allocation:

Vesting envelope. Insider allocations (Team & Advisors, Pre-Seed, Seed, Strategic, KOL) each sit behind a cliff and a linear vest from TGE; the longest tail is Ecosystem and Treasury, which release linearly through month 48. The entire 30B supply is fully unlocked by month 48. See Section 29 for the circulating-supply curve.

Circulating supply against the 30,000,000,000 total, measured from TGE:

The TGE float is dominated by the Liquidity, Airdrop, Public Sale and Treasury tranches; insider buckets stay locked behind their cliffs and unlock linearly thereafter. From month 48 the supply is fully vested and fixed, and the only protocol-level change to circulating $WP is the buyback-and-burn flow described in Section 30.

Planned after the $WP TGE (not live today; the platform fee currently goes to the governance Safe): 30% of every protocol fee (platform fee on trades, plus the DAO's configurable cut of leverage-vault fees) will be routed into a buyback contract that executes on the canonical USD/$WP pool via TWAP, smoothing out price impact and frontrunning.

The buyback contract splits the acquired tokens:

• 50% burned permanently, sent to 0x0. This is monotonic deflation: once vesting completes at month 48 the supply only ever decreases.
• 50% recirculated to the market-resolution staking reward pool, paying honest resolvers (Section 27) in $WP rather than USD. This concentrates token demand at the same place token holders are doing protocol-essential work.

The remaining 70% of protocol fees stays liquid: a configurable split between the DAO treasury (operations, audits, grants) and the LP-vault fee distribution (Section 41). The buyback fraction is DAO-adjustable within bounds [10%, 50%] through the normal timelocked governance path.

Worked example. At a hypothetical $500M annual trading volume under a 1.0% platform fee (5.0M USD gross), 30% (1.5M USD) routes through the buyback. At a $0.005 average buyback price that's 300M $WP acquired per year, 1.0% of total supply, of which 150M is burned and 150M flows to resolvers.

Funding is structured as a staged raise rather than a single public event. The five priced rounds together sold 5,700,000,000 $WP (19% of supply) and raised $10,900,000 at a $120M TGE FDV ($0.0040/token):

• Pre-Seed (3%, 900M $WP): $30M FDV, $0.0010/token. Closed strategic round to a small set of long-horizon backers. 5% at TGE, 9-month cliff, 24-month linear vest.
• Seed (5%, 1.5B $WP): $50M FDV. Priced at a premium to pre-seed; closes pre-mainnet. 8% at TGE, 6-month cliff, 18-month vest.
• Strategic (4%, 1.2B $WP): $60M FDV. 10% at TGE, 5-month cliff, 15-month vest.
• KOL Round (2%, 600M $WP): $80M FDV. Key opinion leaders and ecosystem partners. 15% at TGE, 3-month cliff, 9-month vest.
• Public Sale (5%, 1.5B $WP): $70M FDV. Open, no allowlist. Held immediately before TGE on a BNB-Chain-native venue. 25% at TGE, 6-month vest.
• Liquidity (8%, 2.4B $WP). Seeds the canonical USD/$WP pool plus market-maker inventory at TGE, fully unlocked. The DEX-pool portion is locked.

Pre-seed-to-TGE ratio targets 4.0× ($30M → $120M FDV), modest by sector standards, deliberately so. The team's view is that an aggressive opening multiple is the single biggest predictor of post-launch token failure; modest first-day pricing buys the runway for buybacks (Section 30) to actually do work.

The mainnet deployment is gated on a third-party audit by one of: Trail of Bits, OpenZeppelin, Spearbit, or ChainSecurity. The scope includes:

• SpotEngine, MarketRegistry, FeeRouter and ResolutionModule in their entirety
• ProtocolConfig and AccessController (parameter bounds and role wiring)
• Integration with @prb/math's SD59x18 usage (specifically the overflow pre-conditioning)
• Timelock + multisig configuration

Audit acceptance criteria:

• Zero critical or high findings at final re-audit
• Medium findings either resolved or documented with risk acceptance
• Public audit report published under the protocol's domain

Parallel to the audit, the test suite currently stands at 83 passing tests covering the full lifecycle: creation, buy/sell under all pricing regimes, fee accounting, resolution, dispute, void, refund, claim, and reentrancy. A property-based fuzzing pass via Foundry is planned for mainnet prep.

Post-audit, the contract enters an Immunefi bug bounty with the following tiers:

The frontend and indexer also have a bounty scope, with caps one order of magnitude lower. They are not funds-bearing, but phishing / XSS vectors can still damage users.

The 2-of-3 governance Safe holds the pause guardian role and can pause trading immediately, without the timelock delay. It acts in this scenario:

• Code vulnerability disclosure. An exploit is reported or observed in mempool. Pause immediately, patch (via new deployment), unpause.

Pause blocks buyShares and sellShares. It does NOT block claimWinnings, which is user-protective and must always execute.

Unpausing is done by the pause guardian or by governance through the timelock.

Each market's seed is paid by its creator at creation, together with a refundable validity bond, so the treasury does not fund market subsidies. The treasury is the 2-of-3 governance Safe (0xF39342C6758156df432fc47cDfF0cDd593E6CcC0), which receives the 1.0% platform fee on every trade.

Public revenue metric. Lifetime platform revenue is FeeRouter.totalPlatformFees() (0x186DCA432CE9f9B5618fcBb7231a6bE3FcEAe454): one on-chain read, updated on every trade, with no reliance on an indexer.

Monitoring. The team tracks:

• Treasury USDW balance
• Lifetime platform revenue (totalPlatformFees)
• Any undelivered treasury fees held in FeeRouter.platformAccrued() (non-zero only if a treasury transfer ever fails)
• Rate of market creation per day

The protocol is non-custodial in the strict sense: no operator, administrator, or governance action can move user funds. A user's outstanding shares, their claimable payout on a resolved market, and their refundable balance on a voided market are all computable from on-chain state alone, without any off-chain cooperation.

This is load-bearing for both the security model (Section 17) and the regulatory posture (Section 37). It also constrains the product: features that would require custodial intermediation (e.g. fiat on-ramps, off-chain matching, instant withdrawals beyond block finality) are explicitly out of scope.

The protocol is designed and documented as a peer-to-peer information service. Specifically, it does not:

• Hold customer funds
• Operate an order book or central matching engine
• Take the other side of trades (the LMSR is algorithmic; the protocol does not profit from trader losses as a counterparty would)
• Provide investment advice or recommend specific market outcomes
• Target residents of jurisdictions where prediction markets are classified as regulated instruments

We believe this structure is most closely analogous to a software publisher distributing a non-custodial tool, not to a regulated derivatives venue. This is, however, not legal advice: each user is responsible for determining the regulatory status of their own use in their own jurisdiction.

The team has engaged outside counsel to review the product's classification in the key jurisdictions. Findings will be published in a companion memo.

A non-exhaustive list, ordered by severity.

• Total loss. Losing-side shares pay zero. A user can lose 100% of their stake on a single market.
• Smart-contract bug. Undiscovered bugs could permanently lock or drain funds. The multisig pause can mitigate some classes but not all.
• Oracle error. A resolver can propose a wrong outcome that survives the dispute window if no disputer posts a bond.
• Network censorship. BSC validators could (collectively) censor the user's transactions. Extremely unlikely in practice but possible in theory.
• RPC failure. The frontend's ability to read contract state depends on third-party RPCs. A coordinated outage would render the UI unusable, though users retain direct contract access via any node.
• Regulatory risk. A user's jurisdiction may, at any time, criminalise the activity. The protocol itself is neutral, but users bear the legal consequences.
• MEV / sandwich. A large trade announced in the mempool may be front-run, increasing the slippage relative to the quoted price at transaction-submission time.
• Frontend-specific risk. The wagerpredict.com frontend could be compromised (DNS, hosting, phishing). Experienced users are encouraged to verify contract addresses against the published list and use their own frontend if paranoid.

Leverage is not live. The design below is planned and disabled on mainnet (the NoLeverage gate is wired in place of a leverage engine).

Leveraged trading sits on top of the unchanged LMSR. Rather than fork the AMM, the protocol lets a user collateralise a position with a fraction of its notional and borrow the rest from the LP vault. The LMSR sees a normal-sized trade; the leveraged trader sees an amplified payoff.

Three contracts cooperate.

• LeverageVault.sol: owns the position registry, the TWAP buffer, and the insurance reserve. All user-facing entry points (openPosition, liquidate, closeEarly, closePosition) live here.
• LPVault.sol: pooled USD. Exposes lendToLeverage + repayLoan + writeOffLoan + notifyFee, the four hooks that the leverage layer uses to move money across the trust boundary. See Section 41 for the LP-side mechanics.
• BetProxy.sol: a fresh contract deployed per openPosition call. Each proxy is the on-chain owner of the LMSR shares for exactly one leveraged position; this keeps user shares and leveraged shares strictly separated on the curve.

Open flow.

1. User picks a side, tier, and collateral amount. The contract pulls collateral × leverage USD: the collateral from the user, the rest from LPVault.lendToLeverage.
2. A BetProxy is deployed; the full collateral + borrowed is sent to it.
3. The proxy approves PM and calls buyShares on the user's chosen side. The shares now sit in the proxy.
4. A LeveragedPosition struct is stored on the vault with side, leverage, collateral, borrowed, opening odds, and liquidation threshold.

Tiers and liquidation thresholds.

Liquidation is permissionless and pays the caller a 5% bonus on the position's collateral, drawn from the insurance reserve. The position's owner cannot self-liquidate; a 1-hour cooldown from open also prevents instant-liquidation griefing if a market jumps inside the opening block.

TWAP, not spot. Liquidation reads a 30-minute time-weighted YES-odds value rather than spot. A trader can momentarily push odds across a tier's threshold without triggering a liquidation; the TWAP must cross. This trades a small amount of capital-efficiency loss for resistance to flash-price manipulation. The contract maintains a rolling buffer of odds snapshots (kept for 1 hour) and recomputes the TWAP on every liquidation check.

Caps and gates.

• Per-position: collateral between $50 and MAX_POSITION/leverage; total bet ≤ $2,000.
• Per wallet: ≤ 5 active positions; combined open exposure ≤ $5,000.
• Per vault: total open borrowed ≤ 20% of LP TVL; total outstanding loans ≤ 50% of LP TVL (defense-in-depth for the window between liquidation and close).
• Per day: combined realized losses (from writeOffLoan) ≤ 10% of LP TVL. Crossing this triggers a permissionless emergencyPause path.
• Opening cutoff: 2 hours before market expiry. The TWAP window can't stabilize closer than that.
• Open odds must sit inside [20%, 80%] for the TWAP at open time. Leverage on lopsided markets is too cheap to game.

Close paths.

• closePosition(positionId) (owner only, post-resolution): proxy claims the winning payout from PM, the LP loan is repaid first, the remainder goes to the user. If the side lost, both collateral and the loan are written off: writeOffLoan books the LP-side loss and bumps the day's loss counter.
• closeEarly(positionId, minUsdcOut) (owner only, pre-resolution): proxy sells all of its shares back into the LMSR at the current cost-function price. Proceeds repay the loan; surplus goes to the user. If proceeds < loan, the shortfall writes off against LP TVL and the user forfeits all collateral. Slippage floor is enforced inside PM's sellShares.
• liquidate(positionId) (permissionless, TWAP-triggered): position is flagged liquidated; the bonus is paid; the actual unwind happens later when anyone calls closePosition on the liquidated row. Liquidated positions are fully assigned to the LP. Any post-liquidation payout flows to the vault as a fee, never to the user.

Insurance reserve. Seeded from creator-side fees + a fixed share of leverage-trade fees. Pays liquidator bonuses. Decoupled from LP TVL so a depleted reserve doesn't pause the vault; instead, the bonus is silently clamped to whatever's left.

The LP vault is a yield source. Deposits earn a share of the 0.1% LP slice of every trade fee, routed by FeeRouter and weighted by lock tier. There are no points and no token emissions. Leverage income (borrow interest, liquidation surplus) would also flow to LPs once leverage is enabled; leverage is not live.

Tiers.

Two rules are worth calling out:

• No decay. A position keeps its tier multiplier for as long as it stays deposited, including after its lock ends.
• Cooldown is uniform. A 1-day cooldown applies between requestWithdraw and the actual withdraw call, including for Flex. This defeats flash-deposit fee-grab attacks (deposit just before a large fee distribution, claim it, withdraw the next block).

Fee distribution. FeeRouter pushes the 0.1% LP slice of every trade into the vault through notifyFee. Each call increases accFeesPerShare by the amount divided by total fee-weighted shares, and every position has a feeDebt snapshot, the standard MasterChef-style accumulator pattern. Pending fees are claimable at any time via claimFees.

Loss absorption. LP principal can only take a loss through writeOffLoan, which only the leverage engine can call. With leverage off, LP principal is not exposed to trading losses. Once leverage is enabled, a write-off is covered by the InsuranceFund first, and any remainder is shared across LP principal.

Deposit constraints. Minimum deposit $10. There is no cap on the number of positions per wallet. Each position is independent: you can hold a 365-day deposit and a Flex deposit simultaneously, and each has its own multiplier.

The main events, by contract. Full ABIs are available from the verified sources on BscScan (addresses in Appendix B).

// MarketRegistry
event MarketSubmitted(
    uint256 indexed id, address indexed creator, uint256 templateId, uint256 resolutionSourceId,
    bytes32 questionHash, uint64 endDate, uint256 b, uint256 seed, uint256 validityBond
);
event MarketListed(uint256 indexed id, bool featured);
event MarketRejected(uint256 indexed id, bool malicious, uint256 bondSlashed);
event Graduated(uint256 indexed id, uint256 distinctTraders, uint256 rollingVolume, uint256 ts);
event MarketResolving(uint256 indexed id, uint256 ts);
event MarketResolved(uint256 indexed id, uint256 bondReturned);
event MarketVoid(uint256 indexed id, uint256 bondReturned);
event MarketClosed(uint256 indexed id);

// SpotEngine
event MarketInitialized(uint256 indexed id, uint256 b, uint256 seed, uint64 endDate);
event SharesBought(uint256 indexed id, address indexed buyer, Side side, uint256 usdcIn, uint256 shares, uint256 newPriceYes);
event SharesSold(uint256 indexed id, address indexed seller, Side side, uint256 sharesIn, uint256 netOut, uint256 newPriceYes);
event Claimed(uint256 indexed id, address indexed user, uint256 paid6);

// ResolutionModule
event Proposed(uint256 indexed marketId, address indexed proposer, Outcome outcome, uint256 bond, uint64 disputeDeadline);
event Disputed(uint256 indexed marketId, address indexed disputer, Outcome counter, uint256 bond);
event Finalized(uint256 indexed marketId, Outcome outcome, address indexed proposer, uint256 bondReturned);
event DisputeResolved(uint256 indexed marketId, Outcome outcome, address indexed winner, uint256 payout, uint256 toTreasury);

// FeeRouter
event FeesRouted(address indexed creator, uint256 platform, uint256 creator_, uint256 lp);
event PlatformFeeBooked(uint256 amount, uint256 lifetime);
event TreasuryPaymentAccrued(uint256 amount, uint256 totalAccrued);

BSC Mainnet (chainId 56), deployed 5 October 2026. All contracts are verified on BscScan.

Lifetime platform revenue: call totalPlatformFees() on FeeRouter.

Retired (BSC testnet, v1). The v1 testnet contracts (PredictMarketLMSR, FeeVault, LeverageVault, LPVault, MockUSDC, Faucet) are retired and no longer used by the app.

C.1. Path independence of LMSR.

For any sequence of trades that takes the reserves from q⁰ through q¹, q², …, qᵏ back to q⁰, the total USD moved is zero. Proof:

total = Σᵢ (C(qⁱ) − C(qⁱ⁻¹))
      = C(qᵏ) − C(q⁰)
      = C(q⁰) − C(q⁰)   [since qᵏ = q⁰]
      = 0

This is a direct consequence of C being a function of the endpoint only.

C.2. Convexity of LMSR cost.

The Hessian of C at any q is:

Hᵢⱼ = (1/b) · (pᵢ · (δᵢⱼ − pⱼ))

where δ is the Kronecker delta. This is the covariance matrix of the softmax distribution, which is positive semi-definite by construction. Therefore C is convex. Strict convexity holds whenever p is not degenerate.

C.3. Bounded loss for n outcomes.

Following Section 06 with n outcomes instead of 2:

C(q) − C(0) ≥ m − b · ln(n)
PnL       = C(q) − C(0) − q_w
          ≥ m − b · ln(n) − q_w
          ≥ −b · ln(n)          [since q_w ≤ m]

The generalisation preserves the bound; b · ln(n) grows sublinearly in n, making multi-outcome markets cheap to subsidise.

• AMM:Automated Market Maker. A contract that quotes prices algorithmically from its reserves.
• b:LMSR liquidity parameter. Units: USD. Depth and subsidy are both linear in b.
• Bonded proposer:A resolver who has locked capital as a commitment to the truthfulness of their proposed outcome.
• Cost function:A function C(q) whose difference across a trade gives the USD moved.
• CPMM:Constant-product market maker (x · y = k).
• Dispute window:The period (12 to 48 hours, scaling with money at stake) during which a proposed outcome can be challenged.
• FeeRouter:Splits each trade fee and records lifetime platform revenue in totalPlatformFees.
• LMSR:Logarithmic Market Scoring Rule. The market maker used by this protocol.
• Market creator:The wallet that calls createMarketSelfServe, pays the seed and validity bond, and receives the 0.1% creator fee.
• Position:A wallet's outstanding (sharesA, sharesB) on a given market.
• Resolver:The address holding the resolver role (the governance Safe during the beta), which proposes and arbitrates outcomes.
• Share:A claim that pays 1 USDW if its outcome wins, 0 otherwise.
• Seed:The C(0) = b · ln(2) USDW paid by the creator into a market at creation.
• USDW:The ecosystem's wrapper around USDC, pegged 1:1 to USDC (6 decimals). Every market trades and settles in it. See Section 20.
• Void:A terminal market state in which each share redeems at the market's price at the moment of void.

• Hanson, R. (2003). Combinatorial Information Market Design. Information Systems Frontiers, 5(1), 107-119.
• Hanson, R. (2007). Logarithmic Market Scoring Rules for Modular Combinatorial Information Aggregation. Journal of Prediction Markets, 1(1), 3-15.
• Pennock, D. M., Sami, R. (2007). Computational Aspects of Prediction Markets. In Algorithmic Game Theory, N. Nisan et al., Cambridge University Press.
• Othman, A., Pennock, D. M., Reeves, D. M., Sandholm, T. (2013). A Practical Liquidity-Sensitive Automated Market Maker. ACM Transactions on Economics and Computation.
• Augur Core Developers. Augur v2 Whitepaper. (2020).
• Polymarket Team. Polymarket CTF Specification. (2022).
• Gnosis Conditional Tokens Framework: https://docs.gnosis.io/conditionaltokens/.
• Aboutaleb, P. (@prb). prb-math: Solidity fixed-point math. https://github.com/PaulRBerg/prb-math