Verex in one page

Every market on Verex resolves to exactly one outcome. Each outcome is a token that pays $1 if it happens and $0 if it does not. That single rule is what makes the price meaningful: if a token trades at $0.63, the market is collectively saying the event is 63% likely.

Because the outcomes of one question are mutually exclusive and exhaustive, their prices must sum to $1. A multi-outcome market — “who wins the election?” with five candidates — is five such tokens whose prices are held to a total of 100%. Verex enforces this by renormalising sibling outcomes whenever one of them trades.

Every prediction market, however it is built, has to answer three separate questions. Confusing them is the most common source of muddled design:

They are genuinely independent. You can change the pricing engine without touching settlement, and swap the oracle without touching either — with one important exception noted below.

1. Create. The question, its outcomes and a resolution time are registered. On-chain, prepareCondition creates the condition; the operator splits collateral into a full set of outcome tokens to have inventory to sell.
2. Quote. The operator posts a ladder of buy and sell orders around its current probability estimate, so the book is never empty on day one.
3. Trade. Orders match in the book by price-time priority. Each match is settled on-chain as a pair of signed orders through the CTF exchange.
4. Close. At the resolution time the market stops accepting orders.
5. Resolve. The winning outcome is reported on-chain via reportPayouts. This is irreversible.
6. Redeem. Holders burn winning tokens through redeemPositions and collect $1 each. Losing tokens are worth nothing.

Settlement and truth are not fully independent, and it is worth knowing why. A condition's on-chain identity is derived by hashing the oracle's address into it:

conditionId = keccak256(abi.encodePacked(oracle, questionId, outcomeSlotCount))

The oracle address is part of the market's identity. Pointing an existing market at a different oracle does not reconfigure it — it computes a different conditionId, which is a different market holding none of the original tokens. Migrating a live market between oracles is therefore not a matter of changing a setting; it is arithmetically impossible.