Predictifi Protocol Whitepaper

1. Problem and thesis

Markets are the most accurate forecasting mechanism humanity has built. When people stake real value on an outcome, the resulting price aggregates dispersed private information into a single, continuously-updating probability. Yet most people never get to participate in a serious forecasting market: traditional venues are gated by geography, custody, and opacity about how prices and payouts are actually computed.

Predictifi is an on-chain prediction market protocol built to remove that gap. Every market, trade, and resolution settles on Base Sepolia (testnet) through open-source smart contracts covered by an in-repo Foundry test suite (unit, fuzz and stateful-invariant). They have not been reviewed by an external security firm. Prices are produced by a published market-making rule — not a hidden order book — so anyone can verify exactly how a price moved and exactly what a winning position redeems for. Resolution, by contrast, is administrator-declared (see section 7).

This is a protocol for predictions and positions, denominated in USD-pegged USDC. It is not a casino: there is no house edge baked into outcome selection, and the protocol earns only a flat, disclosed fee on trading volume.

2. System overview

A Predictifi deployment is a set of cooperating contracts:

An off-chain indexer reads contract events for fast browsing, and a keeper executes triggered conditional orders. The keeper's resolution handler is an inert stub — resolution is administrator-declared, not keeper-driven.

Neither the indexer nor the keeper can move user funds, and all trading, payout, and solvency math is enforced entirely by the contracts. Economic authority is not fully decentralised, however: the resolver/maker owner holds unilateral authority to declare or void outcomes, pause markets, reject proposals, and slash proposal bonds. That owner is a single externally-owned account (EOA) — not a DAO or a multisig.

3. The LMSR automated market maker

Predictifi prices outcomes with a Logarithmic Market Scoring Rule (LMSR), the standard cost-function market maker for prediction markets. Each market tracks a vector of outcome quantities q = (q₀, q₁, …) and a liquidity parameter b.

The market's cost function is:

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

The price (implied probability) of outcome i is the softmax of the quantities:

price(i) = exp(qᵢ / b) / Σⱼ exp(qⱼ / b)

Buying Δ shares of an outcome costs C(q′) − C(q), where q′ is q with that outcome increased by Δ. Selling is the same difference in reverse. This gives three properties that matter for traders:

• Prices always sum toward 1.00. The softmax is a probability distribution, so outcome prices represent a coherent implied-probability split.
• Liquidity is continuous and bounded. There is always a quote, at any size, and the maximum subsidy the maker can ever pay out is bounded by b · ln(n) for n outcomes — the market can never be drained beyond its funded subsidy.
• b controls depth. A larger b means deeper liquidity (prices move less per trade); a smaller b means prices react more sharply. The market creator funds the subsidy that backs b.

All LMSR math is computed on-chain in 18-decimal fixed point. To stay inside the safe range of the exponential regardless of how lopsided a market gets, every exponent is offset by the maximum ratio max(qᵢ/b) before exponentiation — a standard numerically-stable softmax.

4. Trading and fees

To trade, a participant connects a self-custodied wallet, signs in once with Sign-In with Ethereum (SIWE), and approves USDC spending. Buying and selling both produce an instant LMSR quote in the interface, which is confirmed against the on-chain quote before submission.

Fee schedule

A single, flat fee applies to each trade — buy and sell alike — taken from the trade amount:

There are no deposit, withdrawal, subscription, or account fees. Participants pay network gas only when a transaction is not sponsored by a paymaster.

The split aligns incentives: market creators earn for sourcing good questions and seeding liquidity, while liquidity providers and the protocol recipient earn for backstopping the maker and operating the system.

5. Leverage

On eligible markets a participant can open a leveraged long by posting margin (the USDC they commit). The Leverage Vault lends the remainder, so the position controls more exposure than the margin alone.

Tiers (gated by traded volume)

Margin on any leveraged position is bounded to a fixed band of $50 to $2,000.

Position math

For a position whose pre-fee LMSR cost is cost, at leverage L:

margin = ceil(cost / L)        // trader posts at least their 1/L slice
borrow = cost − margin         // lent by the vault; margin + borrow == cost

The trader posts margin + fee; the vault lends borrow; together they fund the full position. Profit and loss scale with the price move times the leverage, versus an unleveraged position of equal margin.

Liquidation, TWAP, and the insurance reserve

If price falls to a position's liquidation threshold, the position can be closed by anyone (permissionless liquidation) and the margin is forfeited:

liquidationPrice = entryPrice · (L − 1) / L

At this price the long's loss equals the trader's margin (its 1/L slice of the cost). Two safeguards are designed to prevent unfair liquidations:

• Cooldown. A position cannot be liquidated until 1 hour after it opens.
• TWAP gate. The liquidation check reads a time-weighted average price over the position's lifetime, not the spot price, which is designed to prevent a single-block price spike from triggering a liquidation.

A liquidator earns a bonus of 5% of the position's margin, funded first from any seized surplus and then from the Insurance Reserve — a permissionlessly-funded USDC buffer designed to backstop the vault against liquidation bad debt. If a recovery comes in below the borrowed amount, the reserve makes the vault whole up to its balance; any shortfall beyond the reserve is socialized to vault LPs. The reserve uses tracked accounting (it cannot be over-drawn) and can only be paid out by the Leverage Manager.

6. Conditional orders

Stop-loss and take-profit orders let a participant pre-commit an exit. The trader sets a trigger price and a slippage tolerance; the keeper monitors markets and executes a triggered order on-chain at the next valid opportunity. Placing an order escrows the covered shares in the orders contract until it executes or is cancelled, at which point they are returned.

7. Resolution

Resolution is bonded-proposal, administrator-declared. The resolver keeps the seam a production optimistic oracle would plug into, but it does not implement a dispute game:

1. Propose. Anyone may propose the winning outcome by posting a 100 USDC bond, which immediately freezes trading in that market. Markets created with restricted resolution (openResolution = false) accept a proposal only from the administrator. There is one proposal per market; the bond amount is owner-configurable and snapshotted per proposal.
2. Declare. A protocol administrator then declares the final outcome, rejects the proposal, or voids the market. A correct proposer is refunded the bond and paid the market's accrued resolver reward; a wrong proposer forfeits it. A rejection reopens trading and slashes the bond.
3. No dispute window, no automatic finalization. There is no challenge period, no matching counter-bond, and nothing finalizes on a timer.
4. Stale escape. If no administrator acts within 30 days of a proposal, anyone may call voidStale to void the market; holders then claim a refund, paid in the order claims arrive.

Three consequences follow directly from this design and are worth stating plainly. Because a proposal freezes trading, posting a bond is a market-halting action, not a costless assertion. Because only the administrator can declare, resolution depends on that key remaining available and honest — the 30-day voidStale escape is the only permissionless backstop. And because voidStale requires an existing proposal, a restricted-resolution market whose administrator never proposes has no escape path at all: its funds stay locked for as long as the administrator stays silent.

State is always updated before any external maker/token call (checks-effects-interactions), and bond transfers are reentrancy-guarded.

Voids and refunds

A market that cannot be resolved unambiguously is voided. A void refunds your net amount spent out of that market's remaining collateral, with no fee deducted. Refunds are paid in the order they are claimed and each one draws that collateral down, so a market that cannot cover every holder pays the earliest claims and leaves the last ones short — a late claim can recover less than you spent, or nothing. Claim promptly once a market is voided.

The deployed claimVoidRefund pays min(netSpent, collateral) and decrements collateral on each claim; it does not divide the pot pro-rata. A market only becomes unable to cover every holder after its creator reclaims the market subsidy, which reserves totalNetSpent while the claims outstanding total the sum of every holder's netSpent.

8. Risk disclosures

• Smart-contract risk. Predictifi runs on open-source contracts covered by an in-repo Foundry test suite (unit, fuzz and stateful-invariant). They have not been reviewed by an external security firm. On-chain transparency means state is verifiable, not that bugs are impossible.
• Market risk. Prices can move sharply. A losing position can lose its full stake; a liquidated leveraged position forfeits its full margin.
• Resolution risk. Resolution is administrator-declared: there is no dispute window and no automatic finalization, so a market resolves only when the administrator acts. If nobody acts within 30 days of a proposal, anyone may void the market via voidStale, and a void refunds in claim order out of the market's remaining collateral — possibly below 100%, and possibly nothing for the last claimant — while cancelling the forecast.
• Admin-key risk. The resolver/maker owner is a single EOA with unilateral authority to declare or void outcomes, pause markets, and slash bonds. If that key is unavailable, affected markets cannot be resolved by any other means.
• Leverage backstop risk. The Insurance Reserve is currently unfunded, so liquidation bad debt is socialized to Leverage Vault LPs in full.
• Liquidity risk. A small b makes prices move sharply on size. Always check the quote before confirming.
• Not investment advice. Predictifi is a tool for expressing views on real-world outcomes. Nothing here is financial advice, and predictions are not guaranteed to be profitable.

9. Roadmap

• Now (Base Sepolia testnet, test USDC with no monetary value). LMSR markets, spot trading, volume-gated leverage, conditional orders, bonded-proposal / administrator-declared resolution, liquidation with an insurance reserve that is currently unfunded, the indexer, the keeper, and the full web app.
• Next. An external security review; a production optimistic oracle (e.g. UMA) wired in via the existing resolver seam so resolution stops depending on an admin key; funding the Insurance Reserve; mainnet deployment behind a staged rollout; deeper liquidity provisioning tools for creators.
• Later. A rewards layer (points, seasons, achievements — already computed and displayed today) with a token-ready settlement seam, and richer market types.

10. Token — Deferred

Predictifi has no token at launch. There is no token sale, no airdrop, no on-chain rewards distribution, and no token-denominated balance anywhere in the product. The rewards surface computes and displays points, seasons, and achievements purely from indexer data — it never mints or promises a token.

The architecture keeps a deliberate token-ready seam: points are computed on read from verifiable on-chain activity, so if a token is introduced in the future a claim mechanism can attach to the same computation without rewriting it. Until then, this section makes no token promises and quotes no token numbers.