What it actually takes to build a prediction market platform in 2026.
You want to build your own Polymarket.
Maybe you want a regional venue, since Polymarket isn't accessible in your country. Maybe you're serving a specific vertical: sports fans, a creator community, a DAO, an institutional desk. Maybe you've noticed Kalshi can't compete on the categories you care about. Maybe you just want to ship something different.
Whatever the motivation, the question is the same: where do you actually start?
This post walks through the decision space.
You can't actually "fork Polymarket"
Polymarket and Kalshi are platforms, not protocols. But the gap goes deeper than that.
Polymarket's stack has two parts. The onchain part — outcome tokens, collateral custody, settlement, UMA resolution — is public, audited, and forkable. The offchain part — the orderbook, the matching engine, the API, the indexer — is closed source. When you trade on Polymarket, your orders sit in their offchain orderbook. Their backend matches them, and the matched results get signed and sent onchain only at settlement.
So when someone says "fork Polymarket's contracts," they're forking the bottom half of the stack. The orderbook and matching engine — the parts users actually interact with — they have to rebuild from scratch. That's a backend infrastructure project on its own: API servers, signature schemes, indexers, monitoring, ops. Months of work before the first trade matches.
That's the engineering side. There's also the side every infrastructure choice leaves on your plate: the brand, the audience, the operations, the reason anyone uses your platform instead of someone else's. No fork, clone, or protocol choice gives you those. They're always your job.
So the real question isn't "how do I fork Polymarket." It's: which engineering work do you want to do yourself, and which do you want already done?
What "building from scratch" actually requires
If you sit down to build a prediction market platform from zero, here's what you're committing to.
Outcome tokens. Usually a fork of Gnosis CTF (ERC-1155 conditional tokens). This is the easy part — the standard exists, you wire it in.
Market listing. Where markets come from, who can create them, how they get configured, and how they get instantiated on the exchange. Polymarket does this off-chain — a curated team configures markets and pushes the data to the contracts. If you want listing onchain, you need to design who's allowed to call it and how. Either path is real work.
Exchange. Order representation, the matching engine, settlement against collateral. This is where most of the work actually lives, and it's where the architectural decisions matter most. If you do it offchain (Polymarket's approach), you need API servers, a signature scheme, batching logic, anti-front-running protections, monitoring, and the ops to keep all of it running 24/7. If you do it onchain, you need to design a matching engine that fits within gas constraints and handles direct fills plus the cases where two opposing buyers can mint new tokens from collateral and two opposing sellers can close back to collateral.
Resolution. Wire UMA's optimistic oracle for human-asserted markets — bond logic, dispute window, payout handling. Or wire Pyth or Chainlink for price-based markets. Either way, you also handle the disputes, the edge cases, and what happens if resolution never comes.
Access control and fees. Who can list markets, who can trade, what each side pays, how fees route to the protocol, the venue, the market creator. All enforced onchain, all configurable per venue if you want flexibility.
The frontend. Order entry, position viewing, market discovery, portfolio tracking, wallet flows, mobile responsiveness, fiat onramps if you want them. Nontrivial.
The data layer. You need an indexer, probably a subgraph. You need to track markets, orders, fills, positions, fees, and historical state. The frontend depends on this being fast.
Operational infrastructure. Hosting, monitoring, customer support flows, KYC if your jurisdiction requires it, compliance work, legal entity setup, banking relationships if you want fiat rails.
Distribution. None of the above gets you a single user. You need a brand, a content strategy, a community, and a reason for people to use your platform.
The honest estimate for the first eight items, assuming a competent team, is twelve to eighteen months of engineering work before the platform is ready to take a single trade. That's before the ninth item, distribution, which is what actually matters.
This is why most projects that announce "we're building a Polymarket competitor" disappear before launching. The work is real.
The other path: build on top of existing infrastructure
The alternative is: don't build the infrastructure yourself. Build on top of someone who did.
That option is new in 2026. OddMaki is permissionless onchain infrastructure for the Polymarket category. Live on Base.
It's an open protocol. No subscription, no listing fees, no charge to deploy. Anyone can create a venue and list markets paying only gas, which on Base is negligible. There's a fixed protocol fee on trades, paid by your users on the taker side.
Here's what you get without writing it, and what you still build.
What's already there
Outcome tokens. CTF-compatible ERC-1155 outcome tokens. Same standard Polymarket uses.
Market listing. Fully onchain. Anyone can create a market on OddMaki, bounded by your venue's access policy. No off-chain curation team, no API to push markets through. Whoever you've authorized lists markets directly via the contract.
Exchange. Order representation, fully onchain orderbook, matching engine with three paths: direct fill, mint-to-fill (two opposing buyers mint new tokens from collateral), merge-to-fill (two opposing sellers close back to collateral). USDC collateral. No backend to run. No API servers to operate. No signature schemes to design. Multi-outcome markets supported — up to 50 mutually exclusive binaries in a group with atomic resolution cascade.
Resolution. UMA V3 wired in for human-asserted markets (news, events, election outcomes) with a bond and dispute window. Pyth Network wired in for price-based markets (BTC at strike, ETH above threshold, FX, RWA milestones) with instant resolution and no liveness wait. Both permissionless — anyone can submit.
Access control and fees. Each venue independently configures who can list markets and who can trade — open, NFT-gated, token-gated, whitelist, or custom contract. Fee routing handles protocol, venue, and market-creator splits. The protocol enforces what you specify.
The data layer. A subgraph indexes every protocol event — markets, orders, fills, positions, fees, historical state. Public endpoint. Your frontend reads from it.
What you build
Your frontend. Order entry, position viewing, market discovery, portfolio tracking, wallet flows, brand. Wire it to your onchain venue and to the public subgraph. No backend needed — the frontend reads directly from the chain and the subgraph.
Your distribution. Brand, audience, content, the reason people use your platform. This part is always your job, regardless of which infrastructure choice you make.
That's it. Two items.
Or use the Venue Starter as your foundation
OddMaki ships a white-label frontend called the Venue Starter. A fully-functional Polymarket-style dApp built on Next.js 15. How much you do on top of it is up to you.
The minimum path: fork it, change the colors and the logo, point it at your venue's onchain registration, deploy to Vercel or any other host. You have a live prediction market platform in under an hour. Most launches won't need to touch the SDK or write a line of contract code.
The more common path: same starting point, but you customize the UX, add features that fit your venue, integrate with your community, and ship something that feels like your product instead of a fork. The Venue Starter handles trading, positions, market discovery, and portfolio out of the box, which means the work you do on top is the work that differentiates you, not the work to get to parity.
The advanced path: treat the Venue Starter as a reference implementation and build your own frontend against the SDK. This is for operators who need something the starter doesn't fit — a different UX paradigm, a backend service that does something custom, a market-making bot, an agent integration.
Whichever path you pick, you're starting on top of working infrastructure, not from zero.
What you actually need to decide
If you're trying to figure out which path to take, the questions worth answering first.
Are you a builder or a brand? If you have specialized engineering capability and a real reason to write your own contracts (a unique mechanism, a novel oracle design, a category that doesn't fit existing primitives), going from scratch might be the right call. If you're primarily bringing an audience, a vertical, or a brand to a market that already exists, building on a protocol is much faster.
What category do you care about? Different shapes of infrastructure are tuned for different shapes of markets. CLOB-based protocols with deterministic resolution work well for the Polymarket-shaped categories — crypto prices, news, events, RWA milestones, election outcomes, anything where the question has a clean answer. Pool-based protocols with off-chain odds providers work well for sportsbooks. If your category looks like Polymarket, OddMaki is shaped for it.
How much control do you need? If you want to set unique access rules, fee schedules, market creation policies, and branding without asking permission, the protocol-on-top approach gives you that without forcing you to maintain the underlying infrastructure. With OddMaki, each venue independently configures its own access policies (open, NFT-gated, token-gated, whitelist, or custom), and the protocol enforces what you specify.
What's your distribution thesis? Whatever you build, the hard part is getting users. If you have a real distribution edge (a community, an audience, a vertical, a geography), the protocol path lets you focus on that edge instead of on engineering. If you don't have a distribution edge, no amount of clever protocol work will save you.
Closing
If you're a builder considering this, my honest take: the path of building on top of existing infrastructure instead of rebuilding it is the right one for almost everyone. The protocol work is the hard part. It's already live. Anyone can build on it.
*This is the OddMaki team's blog, so my view is biased toward the path I took. But the path itself — building on top, not from scratch — is the one I'd recommend regardless.
Curious? Start at oddmaki.com.*
— Carlos Revelo