[h] home [b] blog [n] notebook

why i'm building if.market

i have been thinking about conditional markets for almost five years. some of what i have written about them is on this site — futarchy for ai governance, the causal-correlational gap, perpetuals as continuous prediction markets, lmsr isn't enough. the through-line is that conditional markets are the mechanism-design primitive that lets you price counterfactuals — "what happens to x if we do y?" — and that almost every interesting governance, forecasting, and allocation problem reduces to one of these at some level.

the other through-line is that nobody has built the exchange for them. polymarket and kalshi are unconditional. augur is a decade of cautionary tales. metaculus has conditional forecasts but no money. the deep perp venues — hyperliquid, dydx, paradex — have solved the matching and settlement side of exchange design in ways prediction-market platforms have not caught up with. there is a space between "a binary options market with cumbersome resolution" and "a perp dex with no semantics about conditions" that is not filled by any product currently in the market. if.market is the attempt to fill it.

the technical frame is almost boring. if.market is an instrument-agnostic exchange engine — a central limit order book with price-time fifo matching, event-sourced through kafka, postgres for persistence, written in rust. none of that is innovation; it is table stakes. the point of getting the plumbing right is that once you have a fast, deterministic, symbol-agnostic matching engine, the "instrument" can be anything: a binary conditional ("if event x happens, pays $1"), a scalar conditional ("if event x happens, pays f(x)"), a continuous perp, a two-legged conditional basket. all of these are the same exchange engine with different resolution semantics attached at the edges.

the product frame is that the interesting questions in finance and governance over the next decade are conditionals. "what is the fair price of nvda if the fed cuts 50bps in march." "what is the probability of a recession if the new tariff package passes." "what is the expected eval score of a frontier model if it is trained on 5e26 flops." each of these is a primitive that every analyst already computes internally with bayesian reasoning and no counterparty. turning them into tradeable instruments is the cleanest way to aggregate the relevant private information and price the counterfactual.

i want to be explicit about what makes this project different from the dozen prediction-market projects that have failed. four things:

resolution is a product, not an afterthought. most prediction-market projects assume resolution will be solved by "an oracle" and then design the exchange around a hypothetical oracle that does not yet exist. this is the opposite of how mature markets work. futures contracts start with a resolution spec (the deliverable instrument, the venue, the settlement index) and the exchange is designed to serve that spec. if.market treats resolution as the primary design question and builds the matching engine around whatever resolution semantics make sense for the instrument. some markets will resolve against kalshi. some will resolve against on-chain events. some will resolve against a smoothed estimator of a public index. the exchange does not care.

matching is built for crypto-native scale and speed. a price-time fifo clob with a kafka event bus and per-symbol engine sharding will run at a latency profile comparable to a mid-tier perp dex. this matters because conditional markets on short-horizon events — "will the fed cut at the next meeting" — can only absorb liquidity if the book responds fast enough that a market-maker can post meaningful size without getting picked off. no existing prediction-market platform has this.

the instrument menu is designed to converge on perps. the platform supports binary yes/no conditionals at launch, scalar conditionals shortly after, and eventually conditional perps — perpetual contracts whose funding rate clears continuously and whose resolution is gated on a condition. this is the shape of the thing i think will eat prediction markets, for reasons i wrote about in perpetuals as continuous prediction markets. the exchange is built so that adding the conditional-perp primitive is a few hundred lines of engine code rather than a full rewrite.

liquidity is a portfolio problem, not a per-market one. as i wrote in lmsr isn't enough, the scaling story for prediction markets breaks if you subsidize every contract independently. if.market will ship with a portfolio-level liquidity backstop — a shared reserve of amm-quoted quotes that backstops thin markets, subsidized at the catalog level rather than per market, with batched auctions handling price discovery when native interest exists. this is the main piece of original mechanism design in the product.

there are things i am worried about. three, in order of how much i think about them.

one: the legal surface. prediction markets in the us are a regulatory minefield, and every legitimate attempt to build one — intrade, kalshi, early polymarket — has paid a tax to figure out which questions clear and which do not. i do not think the solve is to wave this off. i think it is to design the exchange so that the instrument type (binary vs. scalar vs. perp) and the resolution source (cftc-regulated vs. on-chain vs. third-party) determine the compliance envelope cleanly, and to keep the protocol open-source enough that the engine can serve both regulated and unregulated instances. the us version will be narrow. the offshore version will be broad. that is fine.

two: the selection problem i wrote about. conditional markets are not decision rules. they are information. the product has to expose this honestly. shipping the exchange while waving at the randomization question is how futarchy gets discredited for the second time this decade. i would rather educate users up front than have the first bad dao execution make the case for me.

three: liquidity bootstrap. the portfolio-level subsidy design is good on paper and untested in prod. there is a scenario where the amm backstop burns subsidy on markets that never achieve native liquidity, and the unit economics fail before the catalog has enough breadth to amortize. i have designs for how to cap this — subsidy per market is bounded, time-decaying, and revocable by governance — but nothing in prediction markets has gone from zero to working without eating at least one version of this failure. i expect to eat one.


the short reason i am building if.market is that i have been thinking about conditional markets for long enough to believe they are the right primitive, and i have been watching existing prediction-market platforms for long enough to believe nobody is going to build the right exchange unless someone decides to treat it as a serious infrastructure project rather than a side-quest on the way to a governance narrative. this is the infrastructure project. the governance use cases follow from there.