HOW IT WORKS

How ThousandMarkets Works From Market Creation to Fee Collection — in Plain English

The prediction market stack that takes teams 6-12 months to build, explained step by step. Click any technical detail to go deeper. Or just scroll — the plain-English version tells you everything you need to know.

THE SHORT VERSION

Three Steps. That's All You Need to Know.

If you never read another section on this page, these three steps tell you how ThousandMarkets works.

01 You Create a Market

Log into your admin dashboard. Click "Create Market." Write a question: "Will ETH hit $5,000 by December 31, 2025?" Set the outcomes (Yes / No), the end date, and the resolution criteria.

Click "Create." Done.

Behind the scenes, ThousandMarkets handles all the blockchain interactions — generating token IDs, deploying conditions on-chain, initializing the oracle. You don't see any of that. You see a form. You fill it in. Your market is live.

02 Your Users Trade

Your audience visits your branded portal (yourname.thousandmarkets.fun). They connect their wallet. They browse your markets. They buy "Yes" or "No" tokens with USDC on Base.

Orders are matched automatically through the trading engine. Trades settle on-chain. Prices update in real time. Your users see a clean, fast trading experience.

03 You Earn Fees. The Market Resolves.

Every trade on your market generates a taker fee that flows to your ProtocolVault — a smart contract on Base mainnet that holds YOUR revenue. You see your balance in your admin dashboard. On-chain. Verifiable. Yours.

When the market's end date arrives, the UMA Oracle determines the outcome. Winning tokens become redeemable for USDC. Losers expire worthless. The market is settled. You keep the fees. Your users keep their winnings.

That's it. Create → Trade → Earn.

Everything below explains HOW each step works under the hood. You don't need to read it to use ThousandMarkets. But if you're the kind of person who wants to know what's behind the curtain — keep scrolling.

Ready to launch? Skip the deep dive →
STAGE 1

How Markets Get Created

What happens when you click "Create Market" in your admin dashboard — from form to live, tradeable market.

1

You Fill In the Form

In your admin dashboard, you enter: the question, outcomes (Yes/No), resolution criteria, close date, resolution window, and proposer reward (USDC incentive for the resolution proposer).

2

The System Generates Unique IDs

Every market needs unique blockchain identifiers. The system automatically generates a questionId and a conditionId — how the blockchain tracks your market across every contract interaction.

3

The Condition Is Registered On-Chain

The system calls the ConditionalTokens contract to register your market on Base mainnet. This creates the on-chain "slot" for your prediction. Now "Yes" and "No" tokens exist. They can be traded.

4

The Oracle Is Initialized

The system initializes your market on the UMA Oracle Adapter — telling the oracle what question is being asked, the resolution criteria, when the market closes, and when proposals can begin.

5

(Optional) Initial Liquidity

Seed your market with initial liquidity by splitting USDC into outcome tokens. Depositing $1,000 creates $1,000 of "Yes" AND $1,000 of "No" tokens (they always sum to $1). Or opt into shared liquidity and let the network provide it.

The Market Goes Live 🟢

The market appears on your portal. Users can see the question, current prices, and the trading interface. They connect their wallet and start trading. From form to live market: typically under 10 minutes.

CREATION FLOW
Admin Dashboard Form: Question, Outcomes, Timing Generate IDs questionId · conditionId On-Chain: CTF_CORE prepareCondition() On-Chain: Oracle Adapter initializeMarket() (Optional) Split initial liquidity MARKET LIVE < 10 minutes
Question ID Generation
questionId = keccak256( abi.encode(title, creatorAddress, blockTimestamp) )

Deterministic hash ensures uniqueness and independent verification.

Condition ID Computation
conditionId = keccak256( solidityPacked( oracleAdapterAddress, questionId, outcomeSlotCount ) )

Triple-binding prevents ID collisions: oracle + question + outcome count.

On-Chain Condition Preparation
CTF_CORE.prepareCondition( conditionId, oracleAdapterAddress, outcomeSlotCount, parentCollectionId )
Contract: ConditionalTokensPlus 0x7De5A1F23B7ce0456Ed530b19e601324141ad9e0 View on Basescan ↗
Oracle Initialization
adapter.initializeMarket( questionId, conditionId, questionText, description, resolutionData, // human-readable criteria reward, // USDC for proposer proposalBond, closeTimestamp, proposalAllowedAfter )
Contract: CTFUpdatedAdapter 0x3c8d2e8E791b12F86AC9a07709887e6fD2aAF64a View on Basescan ↗
Initial Liquidity (Optional)
USDC.approve(CTF_CORE, amount) CTF_CORE.splitPosition( USDC_ADDRESS, // collateral parentCollectionId, // bytes32(0) for root conditionId, partition, // [0b01, 0b10] for Yes/No amount ) // Splitting $1,000 USDC creates: // → 1,000 YES tokens (indexSet 0b01) // → 1,000 NO tokens (indexSet 0b10)
Market Status After Creation
draft pending_approval live

Tenant admins can configure approval workflows or set markets to auto-approve.

STAGE 2

How Trading Works

What happens when a user places an order on your portal — from wallet signature to on-chain settlement.

1

User Connects Wallet

A trader visits your portal. They click "Connect Wallet" — MetaMask, Coinbase Wallet, Rainbow, or any WalletConnect-compatible wallet. Connected to Base mainnet.

2

User Places an Order

They decide to buy YES at $0.65 for $100. Their wallet asks them to sign a message — not send a transaction. This is an EIP-712 typed data signature. It costs nothing (no gas). It's a cryptographic proof that this order was authorized.

3

Order Goes to the Book

The signed order is stored in the orderbook, waiting for someone to take the other side. Your admin dashboard shows it as an open order. The probability shifts.

4

A Matching Order Arrives

Another trader — maybe on YOUR portal, maybe on another tenant's portal via shared liquidity — places a matching sell order. The prices align.

5

The Relayer Matches Orders

ThousandMarkets' relayer continuously scans for compatible buy/sell pairs and calls the exchange smart contract to execute on-chain. THIS is where gas is paid — for trade execution, not order placement.

6

Trade Settles On-Chain

The contract verifies both signatures, transfers outcome tokens, and collects your taker fee. Permanent, transparent, verifiable on Base mainnet. Your ProtocolVault receives the fee.

The Cycle Continues

Prices update. The orderbook refreshes. Other traders place orders. Every trade cycles through steps 2-6. More trades → more fees → more liquid markets.

TRADING LIFECYCLE
Trader A Trader B Sign (free) Sign (free) ORDERBOOK Orders stored & sorted RELAYER Matches compatible orders EXCHANGE CONTRACT matchOne() · On-chain YES tokens USDC YOUR VAULT 💰 Taker fee collected
How Prediction Market Prices Work

Prices represent probabilities. If YES trades at $0.64, the market thinks there's roughly a 64% chance the event happens.

YES price + NO price always equals $1.00 (the spread is the market maker's edge).

If you're RIGHT

Buy YES at $0.64 → worth $1.00

Profit: $0.36/token

If you're WRONG

Buy YES at $0.64 → worth $0.00

Loss: $0.64/token

This is how prediction markets turn collective opinion into a real-time probability estimate.

EIP-712 Order Signing
// Domain (must match frontend & backend EXACTLY) { name: "[contract name]", version: "[version]", chainId: 8453, verifyingContract: "0xd0494D68D5Cc9eAcB1..." } // CRITICAL: Domain and types MUST be identical on // frontend (ethers v6) and backend (ethers v5.7.0). // A single type mismatch causes ALL orders to fail. // This is the #1 integration bug in DIY builds.
Relayer Matching Process
// Service: 1000relayer (continuous loop) 1. Query open orders for each active market 2. Sort buy orders descending by price 3. Sort sell orders ascending by price 4. Check if best buy >= best sell (matchable) 5. Verify both orders: signatures, expiry, balance 6. Call CTFExchange.matchOne(buyOrder, sellOrder) 7. On-chain: verify sigs → transfer tokens → collect fee 8. Record trade, update prices & positions
Contract: MultiTenantCTFExchange 0xd0494D68D5Cc9eAcB1cdc32F5c71E9635c0B9801 View on Basescan ↗
Shared Liquidity Matching

When enabled, the relayer scans orders across ALL opted-in tenants for the same market (same conditionId). Tenant A's buy order can match Tenant C's sell order. Each tenant's FeeModule collects their own fee. Users never see the other tenant's brand.

STAGE 3

How Markets Resolve

What happens when a market's end date arrives — from proposal to final settlement. Trustless, transparent, dispute-ready.

1

Market Closes

When the close timestamp arrives, trading stops. No new orders. Existing open orders are cancelled. Status: live → resolving

2

Someone Proposes the Outcome

Anyone can propose a resolution: "I propose: the answer is YES. ETH did hit $5,000." They post a bond in USDC. If they're wrong, they lose it.

3

The Dispute Window Opens

A liveness period begins (typically 2-4 hours). During this window, anyone can dispute the proposal by also posting a bond.

4A: No Dispute → Accepted ✅

If nobody disputes, the resolution is accepted. The oracle adapter calls reportPayouts() setting the payout vector. Proposer gets bond back + reward. Status: settled

4B: Disputed → UMA DVM ⚖️

If disputed, resolution goes to UMA's decentralized voting (DVM). UMA token holders vote on the correct outcome. Not ThousandMarkets, not the tenant admin — community consensus. Loser forfeits bond.

5

Users Redeem Winnings

After settlement, winning token holders click "Redeem" → each token = $1 USDC. The CTF contract burns tokens and transfers USDC. Losing tokens are worthless.

RESOLUTION FLOW
MARKET CLOSES Proposal Submitted + bond posted No Dispute Accepted ✅ Disputed UMA DVM ⚖️ reportPayouts() Payout vector set MARKET SETTLED Users redeem USDC 💰
Emergency Resolution

Sometimes markets need immediate resolution: ambiguous questions, external events, oracle delays, or regulatory concerns. Your EmergencyGuard contract enables fast resolution bypassing the normal oracle process.

Important: Emergency resolution is always recorded on-chain — transparent and auditable. Use sparingly. It's a safety valve, not a shortcut.

UMA Optimistic Oracle Flow
1. Market close: closeTimestamp passes → Market status: live → resolving 2. Proposal: proposalAllowedAfter passes → adapter.proposePrice() → Proposer posts bond, liveness period begins 3. Liveness period: → No dispute: resolution accepted → adapter calls CTF_CORE.reportPayouts( conditionId, payoutNumerators // e.g. [1, 0] ) 4. If disputed: → Goes to UMA DVM (decentralized voting) → UMA token holders vote → Correct party gets bond back
Redemption Flow
CTF_CORE.redeemPositions( collateralToken, // USDC address parentCollectionId, // bytes32(0) for root conditionId, indexSets // which positions to redeem ) // Binary market payout: // Winning: 1000 tokens * 1/1 = 1000 USDC // Losing: 1000 tokens * 0/1 = 0 USDC
Market Status Transitions
draft pending live resolving settled
STAGE 4

How You Earn Revenue

How trading fees flow from every transaction to your wallet — automatically, on-chain, verifiable.

1

You Set Your Fee Rate

In your admin dashboard, configure your taker fee in basis points. Default: 30 bps (0.30%). For every $1,000 in volume, you earn $3 in fees. Pro tier adds maker fees and referral module.

2

A Trade Executes

When the relayer matches orders and settles on-chain, the FeeModule automatically calculates and collects your fee. The fee routes to your ProtocolVault — not to ThousandMarkets.

3

Your Vault Accumulates

Every fee from every trade accumulates in your ProtocolVault — a smart contract on Base deployed for your tenant. Verify it on Basescan anytime.

4

You Track Everything

Your dashboard shows total fees (all-time, 30d, 7d, 24h), fees per market, top markets by revenue, trend over time, and referral-driven fees.

The Fee Math (at 0.30% taker fee)
$10,000 volume $30
$100,000 volume $300
$1,000,000 volume $3,000
$10,000,000 volume $30,000

ThousandMarkets' cut of your fees: $0. Always.

FEE FLOW
Trade Executes $1,000 volume Exchange Contract Calculates: $3.00 fee Your FeeModule Routes fee → your vault Your ProtocolVault 💰 On-chain. Yours. Verifiable. 📊 Admin Dashboard analytics
Referral Module (Pro & Enterprise)

Turn your most active traders into your distribution channel. Generate unique referral links. Track referred trades. Configure referral rewards. Your traders bring new traders → volume → fees → more rewards. A built-in growth flywheel.

Fee Calculation
takerFee = (tradeAmount * takerFeeBPS) / 10000 // Example: // tradeAmount = 1000 * 1e6 (1000 USDC, 6 decimals) // takerFeeBPS = 30 (0.30%) // takerFee = (1000000000 * 30) / 10000 = 3000000 (3 USDC) // Fee BPS stored as uint16 in FeeModule contract // Amounts as 1e6 strings (USDC decimals)
Revenue Share with ThousandMarkets
// Revenue share: None. Zero. 0%. // // FeeModule routes 100% of configured fees // to the tenant's ProtocolVault. // // No platform fee. No revenue extraction. // Your fees are your fees. Entirely. // // ThousandMarkets monetizes through tier // payments (1 ETH, 5 ETH, custom).
CROSS-TENANT MATCHING

How Shared Liquidity Works (Step by Step)

The process that makes every ThousandMarkets tenant's market more liquid than it could be alone.

TENANT A
"CryptoAlpha"
A KOL's branded portal
TENANT B
"PredictPro"
A startup's prediction platform

Both create: "Will ETH hit $5,000 by Dec 31, 2025?" · Both opt into shared liquidity.

STEP 1

Alice (Tenant A) Places a Buy Order

Alice visits cryptoalpha.thousandmarkets.fun, wants to buy YES at $0.65. Signs an EIP-712 order. Goes to the shared orderbook tagged with Tenant: CryptoAlpha.

STEP 2

Bob (Tenant B) Places a Sell Order

Bob visits predictpro.thousandmarkets.fun, wants to sell YES at $0.65. Signs an EIP-712 order. Same conditionId as Alice's. Goes to the shared orderbook tagged with Tenant: PredictPro.

STEP 3

Relayer Matches Across Tenants

The relayer sees: Alice (Tenant A) wants to BUY YES at $0.65. Bob (Tenant B) wants to SELL YES at $0.65. Same conditionId. Compatible prices. Match! Calls matchOne() on the exchange contract.

STEP 4

Trade Executes On-Chain

The exchange contract: verifies Alice's signature ✅, verifies Bob's signature ✅, transfers YES tokens (Bob → Alice), transfers USDC (Alice → Bob), collects Tenant A's taker fee → CryptoAlpha's Vault, collects Tenant B's taker fee → PredictPro's Vault.

STEP 5

Both Sides Win 🤝

Alice

Got her YES tokens at the price she wanted. Sees the trade on CryptoAlpha's portal. Doesn't know Bob or PredictPro exist.

Bob

Sold his YES tokens at the price he wanted. Sees the trade on PredictPro's portal. Doesn't know Alice or CryptoAlpha exist.

CryptoAlpha

Earned a taker fee from Alice's trade.

PredictPro

Earned a taker fee from Bob's trade.

CryptoAlpha Alice buys YES $0.65 · $100 PredictPro Bob sells YES $0.65 · $100 SHARED ORDERBOOK 🤝 MATCH! Exchange Contract On-chain settlement Alice gets YES tokens Bob gets USDC Fee → CryptoAlpha Vault 💰 Fee → PredictPro Vault 💰

Neither Alice nor Bob knew the other existed. Neither CryptoAlpha nor PredictPro had to bootstrap liquidity alone. This is shared liquidity. This is the structural advantage of a multi-tenant platform.

Full shared liquidity architecture →
THE COMPLETE PICTURE

The Prediction Market Lifecycle — All Four Stages

Everything on this page, in one diagram.

1
STAGE 1: CREATE
Admin Dashboard Generate IDs prepareCondition() initializeMarket() (Optional: split liquidity) Market LIVE 🟢
2
STAGE 2: TRADE
Users connect wallet Sign EIP-712 orders Orders in book Relayer matches matchOne() Tokens transfer Fees collected ↻ Loop
3
STAGE 3: RESOLVE
Market closes Proposal + bond Dispute window No dispute: Accepted / Dispute: UMA DVM reportPayouts() SETTLED ✅
⚡ Emergency: EmergencyGuard → immediate settlement
4
STAGE 4: EARN
Winners redeem tokens for USDC · Fee revenue in ProtocolVault · Admin dashboard analytics · 💰 Revenue

This Is Why You Don't Build It Yourself.

You just read through (or scrolled past) the complete prediction market lifecycle:

Conditional token framework
EIP-712 signed orderbooks
UMA Oracle integration
Per-tenant fee routing
Cross-tenant shared liquidity
Market lifecycle management
Emergency resolution
Real-time analytics & caching

Each of these is a multi-week engineering project on its own. Together, they're 6-12 months of full-time development for a team of experienced smart contract engineers.

Or: 1 ETH and under an hour

on ThousandMarkets.

We built the complexity so you don't have to touch it. You get the outcome. We handle the engineering.

Smart contracts deployed. Trading engine running. Oracle ready.

You've Seen How It Works.
Now See It Work for You.

The smart contracts are deployed. The trading engine is running. The oracle is ready. The shared liquidity network is waiting.

Launch your prediction market. Create your first market. Watch your community trade on it.

Launch Your Market →
Copied to clipboard!