Polymarket Builder Fee Disclosure Checklist

Last verified: 2026-07-07 PDT

Builder fees sound like backend plumbing. For a user, they are part of the cost review.

Polymarket's builder documentation explains that CLOB V2 includes a fee layer that lets builders earn a fee on orders routed through their applications. When a builder attaches a unique builder code and the order matches, a builder fee can be collected alongside any platform fee. The docs describe builder fees as flat percentages of trade notional, configured within enforced limits, and additive rather than a replacement for platform fees.

This page turns that into a practical disclosure checklist for traders, builders, affiliates, and research-tool users. It is educational. It does not tell anyone what to trade.

Key concepts in plain English

  • ▸Builder: A developer, app, or interface routing users into Polymarket markets.
  • ▸Builder code: The attribution code attached to routed orders.
  • ▸Builder fee: A fee collected on matched routed orders when configured and attached.
  • ▸Platform fee: A separate fee layer that may apply depending on market configuration.
  • ▸Spread: The difference between the best bid and best ask; often a larger practical cost than a visible fee.
  • ▸Trade notional: The dollar amount of the transaction used to calculate percentage-based costs.

What Polymarket documents support

Polymarket's Builder Fees docs say builder fees are independent from platform fees. The user cost depends on market configuration and whether a builder code is attached. The docs also explain that builder fees are configured by builders within enforced limits and are collected when an attributed routed order matches.

That means a good disclosure does not stop at "fee" or "no fee." It should show the full cost stack:

Market price:
Order size:
Notional:
Best bid:
Best ask:
Estimated spread cost:
Platform fee if shown:
Builder fee if attached:
Total cost notes:
Builder/app attribution:
Timestamp:

Why disclosure matters

Prediction markets are price-sensitive. A one-cent difference can matter when you are thinking in probabilities. If the Yes price is 52 cents, you are effectively reading a 52% market-implied probability before costs. But if the ask, spread, and routed-order costs make the true entry worse, the clean probability number can be misleading.

Example:

Displayed midpoint: 52 cents
Best ask: 54 cents
Visible spread: 4 cents wide
Order size: $100 notional
Builder/platform fee: check interface and docs
Research note: the midpoint is not the fill price

The point is not that fees are bad. The point is that costs need to be visible before the user evaluates a market.

Builder disclosure checklist

If you build a Polymarket-adjacent app, dashboard, bot monitor, or research workflow, use this front-of-user checklist:

  • ▸Say when an order is routed through a builder integration.
  • ▸Explain whether a builder code is attached.
  • ▸Show any builder fee before submission when available.
  • ▸Separate builder fees from platform fees.
  • ▸Show bid, ask, midpoint, and last trade separately.
  • ▸Do not use midpoint as a promised fill.
  • ▸Warn when spreads are wide or depth is thin.
  • ▸Log the cost estimate and timestamp for review.
  • ▸Keep a cancel/pause path visible.
  • ▸Recheck current Polymarket docs before changing fee behavior.

Trader-side checklist

Before interacting with a routed order, write:

Am I using the main Polymarket interface or a builder app?
Is a builder code attached?
What is the best bid/ask right now?
What price am I actually submitting?
What size is visible at that price?
What fees are shown before submission?
Can I cancel or edit the order?
What would make me pause?

Common mistakes

  • ▸Treating midpoint as the real execution price.
  • ▸Looking at fees while ignoring spread and depth.
  • ▸Assuming a builder fee replaces a platform fee.
  • ▸Hiding attribution details in footer text only.
  • ▸Showing projected outcomes without cost assumptions.
  • ▸Building automation that keeps routing orders after costs, spreads, or access status change.

How Bucko fits

Bucko can turn fee and spread checks into a repeatable research note: quote snapshot, order size, spread, depth, routed-app status, visible fee fields, and post-event review. The useful output is a clean audit trail, not a promise that routing improves results.

Polymarket CTA

If you are eligible for the US app offer, use code BUCKO for a $50 deposit bonus on the Polymarket US app: https://www.poly.market/BUCKO. Confirm current eligibility, app screens, and offer terms before depositing.

Sources and last-verified notes

  • ▸Polymarket docs checked 2026-07-07 PDT: llms.txt, llms-full.txt, Builder Program, Builder Fees, Builder Tiers, Order Attribution, CLOB market data, price/spread/midpoint references, and create-order docs.
  • ▸Public Gamma samples checked 2026-07-07 PDT showed active markets across crypto, politics, sports, and international events with varied liquidity and volume.
  • ▸Bucko/Polymarket partner offer wording is user-provided: code BUCKO, $50 deposit bonus for eligible U.S. app downloads, https://www.poly.market/BUCKO. No newer official affiliate term sheet was independently located during this run.

Frequently Asked Questions

What is a Polymarket builder fee?
Polymarket docs describe builder fees as flat percentages of trade notional that can be collected on matched orders routed with a builder code, within enforced limits.
Is a builder fee the same as the spread?
No. A builder fee is a fee layer. The spread is the gap between bid and ask. Both can affect the real cost of entering or exiting.
What should a builder disclose to users?
Disclose routed-order attribution, any visible builder fee, platform fee context, bid/ask spread, depth, submitted price, timestamp, and cancellation or pause controls.

Related Library pages