Polymarket Builder explained: economics & tiers

Polymarket Builder explained in plain terms: the Builder Program lets third-party operators route orders through Polymarket's CLOB with attribution, earn builder fees in basis points, and access tiered relayer limits and rewards. This guide breaks down how the program works, how fees are paid and attributed, and what operators should consider when deciding whether to participate.

Key takeaways

• Builders route orders through the CLOB with attribution headers and earn builder fees denominated in basis points.
• Tiers (Unverified / Verified / Partner) control daily relayer limits and access to rewards and support.
• Builder fees are paid on routed volume; maker fees on Polymarket are zero, taker fees vary by category.
• Use the Polymarket Relayer and the Relayer-aware SDKs to handle wallet deployment, approvals, and CTF ops.
• Operational risks include slippage, partial fills, settlement timing, and UMA resolution disputes — do not treat the fee stream as guaranteed income.

What the Builder Program is, succinctly

The Builder Program is an attribution and routing layer for third-party order flow. A Builder sends orders into Polymarket's CLOB with an attribution header; Polymarket pays builder fees (in basis points of routed volume) and tracks placement on a public leaderboard. The program is explicitly built for operators who want to monetize order flow and receive recognition for volume.

Three tiers are offered:

• Unverified: daily relayer limit 100. Primary benefit is gasless trading with attribution.
• Verified: daily relayer limit 10,000. Verified builders earn weekly USDC rewards on volume plus builder fees.
• Partner: unlimited relayer volume, elevated support, and the highest reward potential.

Credentials to participate are managed in your account at https://polymarket.com/settings.

How builder fees and economics are structured

Builder fees are paid as basis points on routed trading volume. The fees accrue to the builder that supplied the attribution header on orders that execute. Polymarket's maker fees are zero; taker fees vary by market category and currently range from 0% to 1.8% depending on category. Builder fees are an additional revenue stream for the operator on top of any spread capture or execution margin the operator achieves.

Important operational points:

• Builder fees are basis-point based. The exact rate you receive depends on program configuration and any arrangements Polymarket publishes to builders.
• Builder rewards for Verified builders include weekly USDC payments tied to volume in addition to the per-trade basis-point fees.
• Attribution matters: the relayer header determines attribution. If your routing stack or SDK strips or mis-signs the header, you risk losing fee credit.

Note: specific per-basis-point rates and the exact weekly reward formula are managed by Polymarket and may change; consult the Builder dashboard for live rates.

Technical plumbing: relayer, SDKs, and order flow

Polymarket sponsors gas via the Relayer. Builders route orders through the same Relayer architecture and must respect relayer limits imposed by tier. The Polymarket Relayer Client SDK (TypeScript and Python) is the recommended integration point; it automates wallet deployment, ERC-20 approvals, CTF split/merge/redeem, and order placement.

A typical builder flow looks like this:

1. Your system constructs an order and includes the builder attribution header.
2. The order is sent to the CLOB endpoint through the Relayer using the SDK.
3. On execution, Polymarket records attribution and pays builder fees according to the configured rate and tier rules.

Operational notes:

• Reads from the CLOB are public. Order placement requires API key + HMAC.
• Market WebSocket endpoints provide real-time book events for up to 500 instruments per connection; use these to drive your execution logic.
• The Relayer enforces daily limits by tier; the Unverified tier is limited to 100 relayer calls per day, Verified to 10,000, and Partner is unrestricted.

Revenue math and example scenarios (operator-focused)

You should model three separate revenue lines when evaluating whether to run as a Builder:

• Builder fees (basis points on executed volume).
• Weekly volume-based USDC rewards for verified builders.
• Execution margin (spread capture) or arbitrage profits resulting from your routing and liquidity access.

Example (illustrative, not prescriptive): if you route $1,000,000 of executed volume and your builder fee is X basis points, your builder-fee revenue = (X / 10,000) * $1,000,000. Factor in taker fees paid by end users (0%–1.8% depending on category) and any rebate structures Polymarket may run. Always confirm X and reward mechanics in the Builder dashboard — rates and formulas can change.

Attribution, compliance, and limits

Attribution is the single point of truth for fee payment. Ensure your routing stack preserves the attribution header end-to-end. Common pitfalls include proxy layers or middleware that strip custom headers, and replay or idempotency logic that accidentally reassigns attribution.

Polymarket geo-blocks orders by IP. Builders must not advise users to bypass geo-restrictions (VPN evasion is prohibited by Polymarket's Terms of Service). Be aware of blocked countries and regional rules, and design your routing and KYC checks accordingly.

Risks and operational considerations

Do not treat builder fees as guaranteed income. Operational and market risks include:

• Execution risk: partial fills and slippage can reduce effective fee yield.
• Settlement and resolution risk: UMA disputes, delayed resolution, and smart-contract issues can change effective economics.
• Platform policy changes: fee structures, tier limits, or reward programs can be amended by Polymarket.
• Compliance and geo restrictions: orders blocked by IP or policy can reduce usable volume.

Plan for monitoring, alerting, and conservative run rates during onboarding.

How this affects your trading stack

If you're an operator evaluating Builder participation, focus on three engineering controls:

• Reliable attribution propagation: make your headers immutable through the routing stack.
• Relayer budget management: implement throttles and prioritize high-ROI flows when near daily tier limits.
• Real-time market signals: use the CLOB and Market WS feeds for book and best_bid_ask events to avoid adverse selection.

Operationally, Verified tier is the breakpoint for scale. Unverified is useful for testing and low-volume attribution, but 100 daily relayer calls will constrain active strategies. Partner tier is for high-volume operators who need unlimited relayer capacity and elevated support.

Closing summary

Polymarket Builder explained: the program monetizes attributed order flow via basis-point builder fees and tiered rewards while relying on the same Relayer that powers Polymarket's gasless UX. For operators, the core work is ensuring clean attribution, managing relayer budgets, and accounting for execution and settlement risks. Treat the fee stream as an operational revenue source, not a guaranteed subsidy.

Frequently asked questions

How do I become a Polymarket Builder?

Credentials are obtained at https://polymarket.com/settings. You'll register for a builder identity there; tier assignment (Unverified, Verified, Partner) determines your daily relayer limits and access to rewards and support.

How are builder fees paid and measured?

Builder fees are paid as basis points on executed routed volume. Attribution headers on orders determine which builder receives fees. Verified builders also receive weekly USDC rewards based on reported volume in addition to per-trade fees.

What are the relayer limits for each tier?

Unverified builders have a daily relayer limit of 100 calls, Verified builders have a daily relayer limit of 10,000 calls, and Partner builders have unlimited relayer capacity.

Do builder fees replace taker or maker fees?

No. Maker fees on Polymarket are zero; taker fees vary by category (currently between 0% and 1.8%). Builder fees are an additional revenue layer paid to attributed builders on routed volume.

What operational risks should operators plan for?

Plan for execution risk (slippage, partial fills), settlement/resolution risk (UMA disputes, delayed redeem), platform policy changes to fee or tier structures, and geo-restriction-related volume loss. Monitor attribution integrity and relayer usage closely.