Deploy the App

Want to see what you're forking? Live Sepolia demo — the same Venue Starter code running against a demo venue on Base Sepolia, default branding, no customizations. Grab testnet ETH from the Base faucets and test USDC from faucet.circle.com to place real-looking orders.

Fork the Starter

The Venue Starter is a white-label Next.js 15 app pre-configured to work with OddMaki. It includes market browsing, trading (limit, market, and batch orders), market creation (binary, groups, and Pyth price markets) for whitelisted creators, UMA resolution flows, a leaderboard, trader profiles, and a live theme editor.

Venue-level admin (settings, oracle, fees, access control, earnings) is not done in the starter — manage your venue in the OddMaki App instead.

Forking (rather than cloning directly) is the recommended path. Your fork is your own GitHub repo — your theme.config.json, env changes, and any custom code live there, and you can pull starter updates with one click via GitHub's Sync fork button.

The fastest way to fork and deploy in one step is the Deploy with Vercel button on the starter README — it forks the repo into your GitHub account and ships it to Vercel in the same flow.

If you'd rather work locally first:

# Fork + clone in one command (requires the GitHub CLI: https://cli.github.com)
gh repo fork oddmaki/oddmaki-venue-starter --clone
cd oddmaki-venue-starter

Or click Fork on the repo page and clone your fork the normal way. Operators who want a fully disconnected copy (no link back to the starter) can git clone directly instead.

Configure Environment Variables

Copy the example file and fill in your values:

cp .env.local.example .env.local

Required

These two are all you need to boot the app and start trading — perfect for a quick assessment of the protocol.

# Your venue ID from the createVenue step
NEXT_PUBLIC_VENUE_ID=1

# 8453  = Base mainnet
# 84532 = Base Sepolia (testnet — recommended for evaluation)
NEXT_PUBLIC_CHAIN_ID=84532

Required only for production

# The Graph gateway API key. Optional locally and on staging — the SDK falls back
# to a hosted Studio endpoint. Set this in production for the decentralized
# gateway. See "The Graph API Key" below.
NEXT_PUBLIC_GRAPH_API_KEY=

The Deploy with Vercel button only prompts for NEXT_PUBLIC_VENUE_ID and NEXT_PUBLIC_CHAIN_ID so you can evaluate the protocol with zero friction. Add NEXT_PUBLIC_GRAPH_API_KEY in Settings → Environment Variables before you point real users at the deployment.

Optional

# Display name shown in the UI
NEXT_PUBLIC_VENUE_NAME="My Prediction Market"

# Auth provider: "rainbowkit" (default, free) or "privy" (consumer-friendly, paid at scale)
NEXT_PUBLIC_AUTH_PROVIDER=rainbowkit
# NEXT_PUBLIC_PRIVY_APP_ID=your-privy-app-id   # required if AUTH_PROVIDER=privy
NEXT_PUBLIC_WALLETCONNECT_ID=                   # required for RainbowKit mobile wallets

# Feature flags
NEXT_PUBLIC_ENABLE_THEME_EDITOR=true            # enable /admin/theme

# IPFS (optional — for uploading market images and metadata)
PINATA_JWT=your-pinata-jwt
NEXT_PUBLIC_IPFS_GATEWAY=https://gateway.pinata.cloud/ipfs/

The Graph API Key

Production deployments query market data from The Graph's decentralized gateway, which requires a free API key. Local development and staging fall back to a hosted Studio endpoint and need no key.

How it works

The OddMaki SDK has the canonical Subgraph IDs baked in for both Base mainnet and Base Sepolia — you never configure them. What you supply is your own gateway API key:

• Local dev / staging / evaluation: leave NEXT_PUBLIC_GRAPH_API_KEY unset. The SDK falls back to a free, rate-limited Studio endpoint. Fine for development and for kicking the tires on the protocol.
• Production: set NEXT_PUBLIC_GRAPH_API_KEY. The SDK switches to the decentralized gateway for both Base mainnet and Base Sepolia, which has higher limits, redundant indexing, and is what you should be paying for in production.

Get an API key (free, ~2 minutes)

1. Go to thegraph.com/studio and connect a wallet.

2. Sidebar → API Keys → Create API Key.

3. Click into the new key, then open its security/settings tab. Configure all three:

   • Authorized Subgraphs — paste the OddMaki Subgraph IDs you'll query:

     # Base mainnet
     CxoYVjELrNCMLopAmVshnfVAie7yH6QZyCSKD3r41XSQ
     
     # Base Sepolia
     DCnd3ozSyvYxRg7kmZYiDWGBiJCe6QHwu8M93jMN1Q3b

     These are also exported from the SDK as SUBGRAPH_IDS[base.id] and SUBGRAPH_IDS[baseSepolia.id]. Locking the key to specific subgraphs means it can't be reused against unrelated subgraphs if it ever leaks.

   • Authorized Domains — add your production domain(s) (e.g. markets.example.com). Add *.vercel.app (or your preview pattern) if you want preview deployments to query through this key. Do not add localhost — local dev shouldn't drain your production billing cap.

   • Spending limit — set a monthly USD cap that fits your expected traffic. The first 100,000 queries/month are free; pay-as-you-go after that.

4. Copy the key into NEXT_PUBLIC_GRAPH_API_KEY in your hosting platform's environment variables (Vercel, Railway, etc.) and redeploy.

The key is exposed to the browser — it has to be, queries originate from the client. The subgraph allowlist + domain allowlist + spending cap are what keep it safe. A leaked key with all three set is largely useless to anyone else.

Domain changes take ~15 minutes to propagate. If you've just added your domain to the Authorized Domains list and queries still fail with auth error: domain not authorized by user, give it ~15 minutes before debugging anything else — the gateway caches the allowlist and won't honor a freshly added domain immediately.

Two-key strategy (optional)

If you'll be exercising the production query path during local dev (e.g. debugging gateway behavior or rate-limit handling), maintain two separate keys:

Set the production key in your hosting platform's env vars; set the dev key in .env.local (which is gitignored). A leaked dev key is then bounded to pennies of damage.

WalletConnect Project ID

NEXT_PUBLIC_WALLETCONNECT_ID is the Reown (formerly WalletConnect Cloud) project ID that RainbowKit uses to relay mobile wallet connections. It's free.

1. Sign in at cloud.reown.com and create a project.
2. Copy the Project ID into NEXT_PUBLIC_WALLETCONNECT_ID.
3. Under the project's Domains (Allowlist) settings, add every domain users will connect from — production (e.g. markets.example.com), preview URLs (*.vercel.app), and localhost for local dev. Reown blocks WalletConnect sessions from domains not on the list.

Domain changes take ~15 minutes to propagate. Newly added Reown domains aren't honored immediately. If wallet connections fail right after a domain edit, wait it out before changing anything else.

If you're using Privy instead (NEXT_PUBLIC_AUTH_PROVIDER=privy), skip this section — Privy doesn't use WalletConnect project IDs.

Run Locally

pnpm install
pnpm dev

Open http://localhost:3000. You should see your venue's market grid. Connect a wallet and verify that your venue name displays correctly.

Customize Branding

Edit theme.config.json — two colors are enough to generate a full design system:

{
  "brand": {
    "primary": "#00F0FF",
    "secondary": "#FF00E5"
  }
}

The starter auto-generates 10-shade scales, surface colors, and semantic tokens from these two colors. With NEXT_PUBLIC_ENABLE_THEME_EDITOR=true, visit /admin/theme for a live preview editor that exports a ready-to-commit theme.config.json. See Branding for details.

Deploy to Vercel

If you used the Deploy with Vercel button from the starter README, your fork is already deployed — open the project in your Vercel dashboard, set or update the env vars under Settings → Environment Variables, and redeploy.

To deploy a clone or an existing fork from the CLI instead:

# Install Vercel CLI if you haven't
pnpm add -g vercel

# Deploy
vercel

Set your environment variables in the Vercel dashboard (Settings → Environment Variables) and redeploy. Any Next.js-compatible platform (Netlify, Railway, self-hosted) works too.

Architecture Note

The app talks directly to the blockchain (via RPC) and the subgraph (via GraphQL). There is no backend server. This means:

• No infrastructure to maintain — the app is a Next.js frontend with client-side blockchain calls and a single optional IPFS upload route
• Minimal third-party dependencies — just an RPC provider, The Graph gateway for indexed data, and (optionally) Pinata for IPFS uploads
• No single point of failure — if your hosting goes down, users can still interact with the contracts directly

Real-time updates come from a WebSocket listener that subscribes to Diamond and CTF events and invalidates the relevant TanStack Query caches.

Next Step

Your venue is onchain and your app is deployed. Let's create your first market →