How to Build Your Own Polymarket

How to Build Your Own Polymarket



Tópico: How to Build Your Own Polymarket
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
What it takes to build a prediction market platform like Polymarket in 2026, why you can't just fork it, and how to ship one on Base with an onchain CLOB, dual-oracle resolution, and a TypeScript SDK.

People ask me how to build their own Polymarket more than they ask anything else. The reasons vary. Polymarket isn't available where they live. They want a venue for a specific crowd: a sports community, a DAO, an NFT project, a trading desk. They have an audience and want to give it somewhere to trade.

The question underneath is always the same. Where do you start?

Short answer: you don't build the hard part. You build on top of it. The orderbook, the matching engine, custody, settlement, and resolution add up to roughly a year of engineering before a single trade clears. That work is already done and live onchain. What's left for you is the part that makes a platform yours: the brand, the markets, the frontend.

This post covers why building from scratch is so expensive, and then two concrete paths to ship one anyway. There's code.



Can You Just Fork Polymarket?


Not really, and the reason shapes everything else.

Polymarket and Kalshi are platforms, not protocols. Polymarket's stack has two halves. The onchain half (outcome tokens, collateral, settlement, UMA resolution) is public and forkable. The other half (the orderbook, the matching engine, the API, the indexer) runs on their own servers and isn't open. When you place an order on Polymarket, it sits in their offchain book. Their backend matches it. Only the settled result lands onchain.

So "forking Polymarket's contracts" gets you the bottom of the stack. The part traders actually touch, the order matching, you'd rebuild from scratch. That's a backend project on its own: API servers, a signature scheme, batching logic, anti-front-running protections, indexers, monitoring, and the ops to keep all of it running every hour of every day.

The real question isn't how to fork Polymarket. It's which engineering you want to do yourself, and which you want already done.



What Building From Scratch Costs You


From zero, here's the shape of the work:

•
Outcome tokens. Usually ERC-1155 conditional tokens via Gnosis CTF. Easy. The standard exists.

•
The exchange. Order representation, the matching engine, settlement against collateral. This is where most of the work lives. Offchain means servers, signatures, and 24/7 ops. Onchain means a matcher that fits inside gas limits and handles the cases with no direct counterparty.

•
Resolution. Wire UMA's optimistic oracle for human-asserted markets. Wire Pyth or Chainlink for price-based ones. Then handle disputes, edge cases, and markets nobody resolves.

•
Access control and fees. Who can list, who can trade, what each side pays, how fees route.

•
The frontend. Order entry, positions, discovery, portfolio, wallet flows.

•
The data layer. An indexer or subgraph, because the frontend needs fast reads.

•
Ops and distribution. Hosting, monitoring, an entity, banking, and the only part that decides whether anyone shows up: an audience.

Honest estimate for a competent team: twelve to eighteen months before the platform takes its first trade. That's why most "Polymarket competitor" announcements never ship. The work is real.



Build on Top Instead


The other path is to not build the infrastructure at all. Build on something that already did.

OddMaki is permissionless onchain infrastructure for prediction markets, live on Base. One Diamond proxy contract (EIP-2535, 21 facets) at 0x025d086a62d93e24f3cb3f161612ca8e9530127d, deployed on Base (chain ID 8453) and Base Sepolia (84532). It's an open protocol: no subscription, no listing fee, no charge to deploy. You pay gas, plus a flat protocol fee on trades (50 bps, taker-only) that your users pay.

What you get without writing it:

•
A fully onchain CLOB. A tick-based central limit order book in a smart contract, denominated in USDC. Every order, fill, and cancel is a transaction on Base. No offchain matching server.

•
Three settlement paths. The matcher runs them in one call: Normal Fill (a YES buyer meets a YES seller), Mint-to-Fill (two opposite buyers whose prices sum to at least $1 fund fresh token issuance from collateral), and Merge-to-Fill (two opposite sellers redeem a matched pair back to collateral). That last two are what keep thin markets liquid when there's no direct counterparty.

•
Custody and settlement, onchain. Outcome tokens are ERC-1155 via Gnosis CTF, the same standard Polymarket uses. Collateral sits in the protocol contract, not in anyone's wallet.

•
Dual-oracle resolution, permissionless. UMA V3 for human-asserted markets, Pyth for price markets (instant, no dispute window). Anyone can submit the result. No privileged resolver, including the protocol team.

•
A subgraph. Every market, order, fill, and position indexed into a GraphQL API, so your frontend has fast reads out of the box.

What's left for you is two things. Your frontend, and your distribution. The frontend reads straight from the chain and the subgraph, so there's no backend to run.



Path A: Fork, Brand, Deploy (No Contract Code)


The fast path uses a white-label Next.js 15 frontend called the Venue Starter. It ships with trading (limit, market, batch), market creation, UMA resolution flows, a leaderboard, and a live theme editor.

1. Create your venue. Run the wizard at app.oddmaki.com → Create Venue. Set your fees, access rules, and oracle params. It registers onchain and hands you a venueId. About ten minutes, gas only.

2. Fork the starter.

# Fork + clone in one step (needs the GitHub CLI)
gh repo fork oddmaki/oddmaki-venue-starter --clone
cd oddmaki-venue-starter
pnpm install

3. Point it at your venue. Two env vars are all you need to boot:

cp .env.local.example .env.local

# .env.local
NEXT_PUBLIC_VENUE_ID=1        # the venueId from step 1
NEXT_PUBLIC_CHAIN_ID=84532    # 8453 = Base, 84532 = Base Sepolia (start here)

4. Brand it. Two colors generate the full design system:

// theme.config.json
{
"brand": {
"primary": "#00F0FF",
"secondary": "#FF00E5"
}
}

pnpm dev   # http://localhost:3000 — your market grid, your branding

5. Deploy. vercel from the CLI, or use the one-click Deploy with Vercel button in the starter README, which forks and ships in the same flow. Any Next.js host works.

That's a live prediction market platform with no contract code and no backend. The app talks directly to Base over RPC and to the subgraph over GraphQL. If your hosting goes down, users can still hit the contracts directly.

Forking (not cloning) is the recommended path, because GitHub's Sync fork button pulls starter updates into your repo with one click while your theme.config.json and any custom code stay yours.



Path B: Drive It With the SDK


If you're building a custom frontend, a market-making bot, or an AI agent that trades onchain, skip the starter and use the TypeScript SDK directly.

pnpm add @oddmaki-protocol/sdk viem

The SDK wraps the Diamond ABIs, handles decimal and tick conversions, and exposes the subgraph through one client with eight modules: venue, market, trade, priceMarket, accessControl, public, token, and uma.

import { createOddMakiClient } from '@oddmaki-protocol/sdk';
import { base } from 'viem/chains';
import { createPublicClient, createWalletClient, custom, http } from 'viem';

const publicClient = createPublicClient({ chain: base, transport: http() });
const walletClient = createWalletClient({
chain: base,
transport: custom(window.ethereum!),
});

const client = createOddMakiClient({ publicClient, walletClient });
// pass baseSepolia to target the testnet

The method names below are exact. Treat the snippet as the shape of the flow, and check the SDK reference for full parameter and return types.

// 1. Register a venue onchain (fees, access rules, oracle params)
const venueId = await client.venue.createVenue({ /* ...config */ });

// 2. List a binary market on it
const marketId = await client.market.createMarket({ /* question, venueId, ... */ });

// 3. Place a limit order. Simple variants take human strings and
//    handle approvals for EOAs when you pass autoApprove.
await client.trade.placeOrderSimple({
marketId,
side: 'BUY',
outcome: 'YES',
price: '0.62',     // 62 cents
quantity: '100',
expiry: '24h',
autoApprove: true,
});

// 4. Anyone can trigger matching and earn the 10 bps operator fee
await client.trade.matchOrders({ marketId });

// 5. Read state straight from the subgraph (no backend)
const top = await client.public.getTopOfBook(marketId);

Price-handling is the part people usually reinvent, so the SDK ships the conversions:

import { priceToTick, parseTokenAmount, createExpiry } from '@oddmaki-protocol/sdk';

priceToTick('0.75');          // 75n  (at 1% tick size)
parseTokenAmount('100.5', 6); // 100500000n  (USDC, 6 decimals)
createExpiry('24h');          // BigInt(now + 86400)

Batch operations are first-class too: up to 20 orders in one transaction, up to 100 cancels across markets, or an atomic cancel-and-replace.



Resolution: UMA and Pyth


Resolution is per-market, picked at creation.

For markets a human has to settle (did the bill pass, who won the race), it's UMA V3. Someone asserts the outcome with a bond, a dispute window opens, and if undisputed it settles. Disputes fall back to UMA's DVM. In the SDK that's client.uma.assertMarketOutcome and friends.

For markets a price feed can settle (did ETH close above a strike), it's Pyth. Anyone calls client.priceMarket.resolvePyth(marketId) after the close time. The contract verifies the Pyth historical price and resolves. No bond, no liveness wait, no dispute path. Stuck markets can be invalidated for a 50/50 refund after seven days.

Both are permissionless. There is no "OddMaki resolves the market" step, because the team isn't a resolver and couldn't be.



What You Can Build


The protocol doesn't care what your markets are about or who trades them, so the shape is up to you. Access control is two independent axes (who can list, who can trade), each set to open, whitelist, NFT-gated, token-gated, or a custom contract.

• An open public venue, anyone listing and trading.

• A regional venue for a place the big platforms don't serve.

• A community venue gated to your DAO or NFT holders.

• A private institutional book, whitelisted counterparties, onchain clearing, no public exposure.

• An agent-native venue with open contracts and a public subgraph instead of a gated API.

Markets can be crypto prices, news, events, election outcomes, RWA milestones, anything with a clean answer a market can price. Multi-outcome groups (up to 50 mutually exclusive outcomes) resolve as a unit through a NegRisk cascade.

Same protocol underneath all of it. Polymarket is one venue. So is Kalshi. OddMaki is the thing that lets there be many.



Where to Start


The infrastructure is the hard part, and it's done. My honest take, as someone obviously biased here: building on top instead of from scratch is the right call unless you have a genuinely novel mechanism existing primitives can't express. Everyone else should spend their year on users, not on rebuilding an orderbook.

• Docs and the full launch playbook: oddmaki.com/docs

• The app (create a venue): app.oddmaki.com

• A live venue to click around: base-sepolia.demo.oddmaki.com

• Code: github.com/oddmaki · SDK: @oddmaki-protocol/sdk

Everything works end to end on Base Sepolia, so you can rehearse the whole launch on testnet before going to production. You don't need anyone's permission. Start at oddmaki.com.

— Carlos Revelo