Polymarket Builder Program: Fees, Tiers & Attribution (2026)

Polymarket's Builder Program changes the product calculus for applications built on its order book. A builder code can attribute matched orders, power a public leaderboard, unlock relayer tiers, and support additive builder fees. It also creates new responsibilities: public fee disclosure, wallet architecture, reconciliation, eligibility, and a clear statement of what the application actually routes.

What counts as a builder?

Polymarket defines a builder as a person, group, or organization whose application routes user orders through Polymarket. This is narrower than "someone who reads the market API." A read-only odds screen, research notebook, or alert feed does not become an order-routing integration merely because it displays Polymarket data.

The documented order path is:

1. a user places an order through the builder's application;
2. the application attaches its registered builderCode;
3. the signed order goes to the CLOB;
4. the order matches and settles through the supported flow;
5. matched volume is attributed to the builder profile.

The current V2 documentation says attribution is part of the signed order structure and appears in on-chain fill events. That makes attribution more durable than an analytics query parameter—but it does not prove that a product is non-custodial, secure, eligible for every user, or correctly handling failures.

Unverified, Verified, and Partner tiers

A relayer transaction is not the same as a matched order, API request, active user, or dollar of volume. The relayer covers supported on-chain operations such as wallet deployment, approvals, and Conditional Token Framework operations. The tier page separately describes API rate limits and notes that requests beyond a daily relayer limit can be rate-limited.

The Verified path currently asks for a builder key, use-case description, expected volume, and supporting material. It is an external application and should remain a human action. A roadmap item, research page, or domain name is not evidence that verification has been requested or granted.

Builder fees are additive

Polymarket's current fee documentation says builder fees stack on top of any platform fee; they do not replace it. A market with no platform fee can still charge a builder fee when an attributed order is routed through an application. Where a platform fee exists, the user can pay both.

The published configuration currently allows:

• taker builder fees from 0 to 100 basis points (1%);
• maker builder fees from 0 to 50 basis points (0.5%);
• one-basis-point granularity;
• one rate change per seven days;
• three days' advance notice before a scheduled change takes effect.

The builder fee is a flat percentage of trade notional. Platform fees use their own per-market formula and configuration. The order and balance checks must therefore use the complete current fee stack. Marketing a "zero-fee market" while an application adds a builder fee would be materially incomplete.

Fee rates and builder profiles are publicly queryable. Treat that transparency as a product requirement: show the user the current builder rate, platform fee state, estimated complete order cost, and effective date before submission. Do not hide the fee in a wallet or signature screen.

Wallet and relayer questions come before growth

The examples cover Safe and Proxy wallets, embedded-wallet providers, user credential derivation, token approvals, CTF split/merge/redeem operations, and CLOB order placement. That is a real application surface with a large blast radius. Before routing an order, an operator needs written answers to:

• Who creates and controls each wallet and signing key?
• What can the application sign, and how is intent constrained?
• How are user API credentials derived, stored, rotated, and revoked?
• Which jurisdictions and product paths are supported?
• How are partial fills, retries, duplicate orders, and reconnects reconciled?
• What happens when the relayer is limited or unavailable?
• How are platform and builder fees disclosed before signature?
• How can a user export assets and close the relationship?

Remote signing can reduce where a secret appears, but it does not make the design safe by itself. The security review must follow the complete authority chain from user intent to signed order and settlement. The Bot for Polymarket security checklist covers the same principle for repositories and hosted tools: never paste a funded-wallet secret into software you have not fully reviewed.

What the leaderboard and grants do—and do not—prove

Attributed volume and a public leaderboard can create distribution. Verified builders may also receive program rewards, grants, engineering help, or marketing support, subject to approval. These are meaningful go-to-market advantages because usage can become visible and credited to the application.

They are not an audit. Volume does not establish profitability, customer outcomes, safe custody, correct settlement, or honest fee disclosure. A grant does not transfer responsibility for the product. Leaderboard rank is a program metric, not a recommendation to users.

A responsible go/no-go gate

Before Bot for Polymarket creates a profile or routes an order, the decision should require:

1. Product truth: a specific supported user, path, workflow, and venue—not a generic "Polymarket bot" claim.
2. Wallet architecture: documented key authority, recovery, revocation, and exit.
3. Order correctness: idempotency, stale-data limits, fee-aware balance checks, partial fills, and reconciliation.
4. Disclosure: current platform and builder fees shown before signing.
5. Eligibility: a reviewed onboarding and geographic policy.
6. Operational controls: logging, alerting, rate-limit behavior, support, and a kill switch.
7. Human approval: explicit authorization for the external profile, application, and any live-money test plan.

Until that gate is satisfied, the honest work is research, source mapping, read-only tools, and paper workflows. This article does not claim that Bot for Kalshi routes Polymarket orders, and it does not claim that Bot for Polymarket is currently verified.

Continue with the Bot for Polymarket operator handbook for the broader product-path checklist, or compare the separate venue structures in Kalshi vs Polymarket. For the evidence and correction rules behind this guide, read our public research methodology.