How OddMaki Works

Live on Base mainnet · May 2026 · try the demo on Base Sepolia →

---

TL;DR

• What it is. A permissionless protocol on Base where anyone can launch a prediction market platform. The protocol runs the orderbook, settlement, and resolution; operators run the venues.
• What's onchain. Everything. Order book, matching engine, settlement, resolution. No off-chain matcher, no centralized sequencer, no privileged resolver.
• Three market types. Binary, multi-outcome groups (up to 50, NegRisk-style cascade), and Pyth-resolved price markets.
• What ships today. Protocol live on Base mainnet; venue starter (Next.js 15), TypeScript SDK, and subgraph all public. Try the Sepolia demo.
• What's not in it. No token, no protocol-curated markets, nothing off-chain that touches user funds, no fees to launch a venue.

---

OddMaki is permissionless infrastructure for launching prediction market platforms — fully onchain, on Base. The protocol runs the orderbook, settlement, and resolution. Venue operators run the businesses.

What that means in practice: anyone can deploy their own prediction market platform — what we call a venue — using OddMaki as the underlying infrastructure. Think of it as Shopify for prediction markets. The protocol provides the trading engine, order matching, and settlement. Operators bring the audience, the markets, the brand, the front-end.

Polymarket and Kalshi are each one venue. OddMaki is the protocol that lets anyone deploy more.

A venue can be open and public. It can be gated to a community holding a specific NFT. It can be a private institutional book where the operator curates every market by hand. The protocol doesn't care which — it provides the same onchain trading rails to all of them, neutrally, and the operator picks the shape.

You can already try it. The venue starter is running live on Base Sepolia at base-sepolia.demo.oddmaki.com — connect a wallet, grab some testnet USDC, and trade real markets that resolve through real oracles. Same code operators will fork and deploy to mainnet.

The rest of this post is the long-form walkthrough: what's actually onchain, how trades match, how outcomes resolve, what running a venue looks like, and what we deliberately left out.

Why now

Two years ago, prediction markets were a curiosity. Today they're a category.

Polymarket's growth turned election forecasting into a real-time consumer product, with billions in trading volume and a public profile that put prediction markets into mainstream news cycles. Kalshi's CFTC outcome — the federal court ruling that contracts on event outcomes are legitimate financial instruments — gave the category a regulatory foothold in the United States that nothing else in this space has.

What both made clear: there is real demand for trading on what happens, and the demand isn't bounded by what one operator chooses to list.

At the same time, the underlying infrastructure has caught up. Base — Coinbase's L2 — has brought transaction costs to the point where a fully onchain order book and matching engine is practical at consumer scale. A few years ago this would have been theoretical, gas-prohibited, or limited to a handful of bluechip markets at any one time. It isn't anymore.

And there's a third user class arriving: autonomous agents. Trading agents that read onchain state, form views, and place orders without a human in the loop are becoming real, not hypothetical. They want infrastructure they can integrate with directly — open contracts, standard tool-use interfaces — not centralized operators that gatekeep API access.

Put together: a legitimized category, the technical means to run it actually onchain, and a new user class that demands open infrastructure. The piece that was missing was something that lets anyone launch a venue and lets all of those venues trade against the same shared, onchain liquidity rails.

That's OddMaki.

Actually onchain

This is worth being precise about, because the language gets sloppy.

When someone says a prediction market is "onchain," they usually mean some piece of it touches the chain — typically settlement. Outcome tokens get minted onchain, payouts happen onchain, custody is non-custodial. That's good and worth doing. But in most cases, the order book and the matching engine still live on a centralized server. Orders are submitted to that server, the server matches them, and only the final settled trades land on the chain. The operator can pause, censor, reorder, or front-run any of it.

OddMaki doesn't work that way. The order book itself lives onchain. Every limit order is a transaction. Every match is a transaction. There is no off-chain matching server. There is no centralized sequencer that orders trades before they hit the chain. There are no admin functions that can resolve a market outcome unilaterally.

Concretely:

• Orders live onchain. When you place an order, it gets stored in the contract. Other traders can see it. The matching engine — also onchain — fills it according to deterministic, public rules.
• Settlement is onchain. Outcome tokens are ERC-1155 via Gnosis CTF, the same standard Polymarket uses. Collateral is held by the protocol contract, not by an operator's wallet.
• Resolution is onchain. Outcomes resolve through onchain oracles, with no team or operator intervention required to settle. Anyone can trigger resolution. There is no privileged resolver.
• The contracts are public. Every line of source is published and verified on Basescan. The protocol Diamond on Base mainnet is 0x025d086a62d93e24f3cb3f161612ca8e9530127d.

This isn't a slogan. The whole protocol is one Diamond proxy contract on Base, and you can read it. We can't censor individual orders, we can't front-run, we can't push a market to resolve a particular way. The infrastructure does what it says it does, in the open.

That's what we mean by fully onchain.

The trading engine

The engine that matches trades is a tick-based central limit order book — the same shape used in traditional finance. Traders place limit orders at specific prices ("buy YES at 62¢, size 100"). Orders rest in the book at their price. When a new order crosses an existing one, they match. First-in-first-out within each price level — the order that's been sitting longest gets filled first.

There's no AMM curve here, no constant-function market maker, no pool. The price you see is what real participants are willing to pay or accept right now, denominated in USDC. Same primitive as a stock exchange, implemented in a smart contract.

The interesting part is what happens when you can't find a direct counterparty. In a binary YES/NO market, there are three ways trades can happen, and the matching engine uses all three:

A direct match. A YES buyer meets a YES seller. Standard exchange. The seller delivers the token, the buyer pays the price.

A mint. Two buyers on opposite sides of the same question — one buying YES, one buying NO — whose prices together add up to at least one dollar, fund the creation of new outcome tokens together. The protocol takes their combined collateral, splits it into a fresh YES/NO pair, and delivers each side what they bought. No prior holder needed. The market made itself.

A merge. The reverse: two sellers on opposite sides — one selling YES, one selling NO — whose combined ask is at most one dollar, redeem their tokens together back to collateral. The protocol burns the matched pair, returns the dollar to the two sellers proportionally to what they were asking, and the position closes out.

The reason all three matter: they keep liquidity workable when natural counterparties don't exist. In a thin market, a YES buyer might not find a YES seller — but might find a NO buyer at a complementary price, and they can both get filled out of fresh collateral. In a deep market with lots of resting positions, sellers on both sides can exit by reclaiming collateral instead of waiting for new buyers. The market keeps moving.

All three paths execute in the same matching call, onchain, deterministically. The matcher tries them in priority order, fills whatever it can up to a gas limit, and stops cleanly. Anyone can call the matcher — there's no privileged operator role for matching, and whoever submits the match collects a 10 bps fee from the takers in the same transaction. The matcher is an open keeper market.

Three market types. A venue can offer three kinds of market, picked per-market at creation, all sharing the same orderbook, outcome tokens, and fee stack:

• Binary markets. Standalone YES / NO questions, resolved by UMA. The default shape for discretionary questions.
• Market groups. Up to 50 mutually exclusive binary markets bundled into one group — "who will win the election," "which team takes the championship." Each candidate is its own YES/NO market, traded independently, but they're linked at resolution: when one resolves YES, the rest cascade to NO atomically in a single transaction. Holders of NO across the group can also collapse their positions early into the surviving YES side, recovering capital before resolution. The mechanic is what makes capital-efficient multi-outcome trading workable onchain. (Sometimes called NegRisk-style in the broader space.)
• Price markets. YES / NO on a price-feed outcome — "ETH ≥ $4,000 on July 15" — resolved by Pyth from onchain price data. No human assertion needed. We'll come back to these in the resolution section.

Batch operations. Because every order is a transaction, batching matters. Traders can submit up to 20 orders, cancel up to 100, or atomically cancel-and-replace existing orders, all in a single call. The same primitive is what makes market-making bots and other onchain trading agents feasible at the protocol layer.

Resolution

Once a market closes, it needs an answer. OddMaki ships with two resolution paths, picked per-market at creation.

UMA V3 for human assertions. For markets whose outcomes need a human to state what happened — "did Candidate X win the runoff," "was the bill signed by year-end," "did the team win Sunday's game" — the protocol uses UMA's Optimistic Oracle V3. Anyone can assert an outcome by posting a bond. The assertion sits in a public liveness window. If no one disputes it, it settles as-asserted. If someone disputes it, the assertion goes to UMA's dispute resolution process — a decentralized voting mechanism backed by the UMA token — and the loser's bond is slashed. The verified result is reported back to the OddMaki protocol and the market resolves.

Liveness, bond size, and reward for the asserter are configured at the venue level, with a protocol-enforced minimum liveness floor so that even an operator who wants very fast resolution can't shorten the dispute window below a safe threshold. Operators can configure longer windows for higher-stakes questions.

Pyth Network for prices. Some markets don't need a human at all. "Will ETH close above $4,000 on July 15" is a question with a single, machine-verifiable answer — what was the price at that time, according to a trusted onchain feed. For these, OddMaki integrates with Pyth, the largest first-party oracle network on the chain.

The flow is direct: a price market is created with a strike price and a resolution time. When the close arrives, anyone can submit a signed Pyth price update from that moment. The protocol verifies the signature onchain, checks the timestamp falls in the resolution window, compares the price to the strike, and resolves. No human assertion, no liveness wait, no dispute possible. Resolution can happen seconds after the close — or hours later if no one bothers. The result is the same.

If a price market never gets resolved through Pyth for some reason, it falls back to the standard UMA flow. There's always a path to resolution.

The structural point. Both oracles are permissionless. Anyone can submit the assertion. Anyone can submit the price update. There is no "OddMaki resolves the market" — the protocol team isn't a resolver, and we couldn't be even if we wanted to. This is the cleanest contrast with prediction market designs where outcomes flow through an operator-controlled oracle or admin function. Here, resolution is a public good with a public interface, and the rules are deterministic.

The venue model

This is the part operators care about most.

A venue is your prediction market platform. You configure it once — an onchain registration, gas only — and then it lives on the protocol. Two things are configurable, both enforced by the contract, and they're configured independently:

Who can create markets. This is the curation axis. Options:

• Open — anyone can create markets. The most permissionless setting; users are the listing committee.
• Whitelist — only addresses on a list you maintain can create. Useful for editorial venues where you want curators, not random submissions. Functions as KYC-style access without the intermediary.
• NFT-gated — only holders of a specific NFT collection can create. Useful for community-owned venues where the right to list is part of membership.
• Token-gated — only addresses holding at least N of a specific ERC-20 can create. Useful for token-based community access.
• Custom — any access logic the venue implements as a custom smart contract. The escape hatch for anything the four built-in modes don't cover.

Who can trade. This is the audience axis. The same five shapes — open, whitelist, NFT-gated, token-gated, custom — are available independently for trading.

The two axes combine. A venue can be public on creation and private on trading (anyone can list a market, only members can trade), or the inverse, or fully open, or fully gated, or anything in between. Three example shapes:

• An open public venue. Open creation, open trading. The Polymarket-style consumer product. Anyone in the world can list a market or place an order. The operator sets fees, owns the front-end, runs the brand.
• A community venue. NFT-gated on both axes, or NFT-gated on creation and open on trading. The right to list (or trade) is tied to community membership. Useful for sports leagues, fandoms, DAOs, professional groups — anywhere the audience is already organized around a token.
• A private institutional venue. Whitelisted on both axes. The operator and their counterparties create markets and trade among themselves, using the protocol for clearing and settlement but with no public exposure. Useful for corporate hedging, private prediction markets inside a firm, or institutional-only books.

The same protocol serves all three. There's no separate code path, no separate contract, no separate deployment — just different access modules wired into the same venue registration.

Verticals are not a parameter. A single venue can host crypto price markets, weather markets, governance markets, sports markets, and news markets simultaneously. Or it can specialize tightly to one. The protocol doesn't enforce a category. Operators choose what to list (or what their users are allowed to list), and the same trading engine handles all of it.

Fees. Every trade pays a fee stack, taker-only — makers pay nothing. Four layers:

• Venue fee. 1–200 bps, set by the operator. This is the operator's share, the main revenue line of running a venue.
• Creator fee. A configurable slice of the venue fee, carved out at creation, paid to whoever listed the market. Optional. Useful as an incentive for listers when the venue allows public market creation.
• Protocol fee. 0–200 bps, set by the protocol — currently 50 bps. Funds protocol infrastructure and development.
• Match operator fee. 10 bps fixed, paid to whoever submits the matching transaction. This is what turns matching into an open keeper market: any address can run a matcher, and gets paid for it.

The operator sets the venue fee and creator share at launch and can update them anytime. Venue revenue goes directly to a venue-controlled address. We don't take a cut beyond the protocol fee, and there's no revenue share above that line.

The operator owns the front-end. Branding, UX, market discovery, social features, leaderboards — all of that is the venue's product, not the protocol's. The protocol provides the rails. The venue provides the experience.

What ships at launch

The protocol is live on Base mainnet. Contracts are deployed, verified on Basescan, and the source is public — open to read, audit, and learn from. The same protocol is also deployed on Base Sepolia for testing — every operator action, every market type, every resolution path works end-to-end on testnet, so you can rehearse a full launch before going to production.

The venue starter is the headline operator artifact. It's a fully featured prediction market dApp — Next.js 15, modern stack, designed to be cloned, branded, and deployed. It reads directly from the chain and a public subgraph, so no backend is required out of the box. If you want to run a venue, you can: clone the repo, change the colors and the logo, deploy to Vercel or any other host, point the front-end at your venue's onchain registration. The whole path is documented at oddmaki.com/docs/quick-start and typically takes under thirty minutes. The vast majority of operators won't need to write a line of contract code or touch the SDK at launch.

You can play with the starter right now on Base Sepolia: base-sepolia.demo.oddmaki.com. Same code you'd fork, running against the testnet protocol.

@oddmaki-protocol/sdk is the TypeScript SDK that powers the venue starter and works standalone for any developer building something different — a custom front-end, a backend service, a market-making bot, an analytics dashboard, an agent integration. The SDK and the venue starter aren't in tension. The venue starter is the public dApp; the SDK is for everything else.

The subgraph indexes every protocol event — markets, orders, trades, fills, fees, portfolios, group statistics. It's the data backbone behind the venue starter and the standard query path for any application reading historical state. Hosted on The Graph.

Python and Rust SDKs are in progress and will follow.

What we don't do

What we deliberately left out is as much a part of the design as what we put in.

No fees to launch a venue. Deploying and running a venue costs only network gas. No setup fees, no subscriptions, no tiers. Nothing sits between you and the protocol.

No token. OddMaki is launching with no token, no airdrop, no points program. Protocol fees are the revenue model, and the fee data and regulatory landscape need time before a token decision can be made responsibly. We'd rather defer the question than ship a token we'll regret in eighteen months.

No protocol-curated markets. The OddMaki protocol team operates no markets, picks no questions, and runs no editorial calendar. Market creation happens at the venue level under whatever access policy each operator sets. We don't pick winners — operators do, or their users do, depending on how the venue is configured.

Nothing off-chain that touches user funds. No matching server. No operator hot wallet holding user funds. The protocol contract holds collateral and outcome tokens; nothing routes through a team-controlled custodian. We can't move user funds. We can't censor an individual order. We can't front-run. We can't push a market to resolve YES or NO.

The protocol is software. Venues are businesses. That distinction isn't rhetoric — it's how the contract is built, what the team does, and what the team doesn't do. We write and ship neutral infrastructure. The businesses that operate on top of that infrastructure are owned, branded, and run by independent third parties who chose to build on it. They're the ones with users, fees, and counterparties. We're the ones with the protocol contract.

A note on architecture

For the technically curious: the protocol is implemented as an EIP-2535 Diamond — a proxy pattern that splits functionality across modular facets, each handling a distinct domain (markets, orders, matching, resolution, venues, access control, fees, and more). Twenty-one facets in production today. This is the cleanest way we found to ship a protocol of this scope while keeping individual components upgradeable per-domain without disrupting the whole. Most readers don't need to think about it. Operators don't need to understand it. It's there because it was the right tool for the job.

What's next

Today's launch is the foundation. The protocol is live, the venue starter is available, the SDK and subgraph are published. From here, three lanes:

Distribution. Onboarding venue operators across verticals — creator economies, sports communities, institutional desks, agent-driven trading firms. Expanding the developer surface with Python and Rust SDKs. Deploying the protocol to additional chains, with Arbitrum next on the list.

Trading rails. Programmable trading primitives at the protocol layer — constraint vaults that let capital owners delegate trading to authorized agents (human or AI) under onchain rules they specify, without giving up custody. Reference implementations for market-making bots. An MCP server that exposes the protocol to AI agents through standard tool-use interfaces, so agent developers can build against OddMaki the way they'd build against any other tool.

Operator tooling. Continued investment in the venue starter — every feature added compounds across every operator running it. The starter is the highest-leverage surface in the stack.

The structural bet is that a permissionless protocol with a credible venue surface and real onchain rails will compound faster than vertically-integrated competitors. Operators choosing infrastructure will choose what they can verify, what they can build on, and what won't be pulled out from under them. We think that's OddMaki.

Closing

If you're an operator thinking about launching a prediction market platform: fork the venue starter, brand it, deploy it. The documentation walks through every step. The Sepolia demo lets you try the end product before you commit to anything. You don't need our permission. You don't need to talk to us. The protocol is open and the front-end is yours.

If you're a developer building infrastructure, bots, agents, or analytics: read the SDK, the subgraph schema, the contract source. All of it is public. We'd love to see what you build.

If you're a trader: head to the Sepolia demo for now — testnet USDC, real oracles, real resolution — and to the app to find venues live on mainnet as they come online.

Neutral by design. Yours to build on.

— The OddMaki team