Attribution and builder programs

How attribution works technically

Attribution is implemented via a builder code embedded in the trade request — typically via an HTTP header (e.g., X-Builder-Id), a query parameter, or a signed field in the order payload. When the platform processes the trade, it stores the builder code alongside the trade record. At settlement or periodic payout time, the platform aggregates fees per builder code and distributes revenue-share.

Revenue-share structures

Typical tiers observed across major prediction market platforms in 2026:

• Polymarket-style fee-share: a percentage of the platform fee generated by attributed trades; higher tiers unlock at volume thresholds.
• PredictAsiaX-style bps split + grant program: a fixed 5-actor split on the 50-bps taker fee (10 bps to execution_builder, 10 bps to acquisition_builder among 5 roles), plus a tiered PAX-token grant program (Hackathon 0.5-2k / Builder 5-50k / Partner 100-500k) with cliff and linear vesting. Rate-limit multipliers rise by tier (Verified 1× → Genesis 10× → Partner up to 20×).
• Kalshi affiliate: a per-referred-user activity share, similar to traditional affiliate marketing.
• Manifold creator model: flat share on markets you personally operate; no tiering.

Revenue-share is calculated on the platform fee (typically 1-4 percent of profit or 0.1-1 percent of volume — see settlement for fee structures), not on the trade's gross value.

Builder program vs affiliate program

Both pay for user activity, but they differ structurally:

• Affiliate: refers users to the platform via a link. Paid on signups, deposits, or a percentage of the referred user's fees for a fixed window. Does not host trading UX.
• Builder: hosts an interface, agent, or app that routes trades through the platform's API. Paid on fees from each attributed trade. Takes on uptime, support, and UX responsibility.

Builders typically earn higher per-trade share than affiliates because they carry more operational responsibility.

Attribution window

The attribution window is the period during which subsequent trades from a user acquired by a builder are credited back to that builder. Common designs:

• Session-only: only the specific trade requests carrying the builder code count.
• 24-hour cookie window: any trade from that user in the next 24 hours counts, regardless of routing.
• Lifetime attribution: rare, only in Genesis tier or specific partnership agreements.

Integrity enforcement

Well-designed builder programs prevent gaming via:

1. ToS bans on self-trading, wash trading, and Sybil-farmed accounts.
2. Automated monitoring of trade patterns per builder code (velocity anomalies, offsetting trades, coordinated behavior).
3. Periodic manual review with revocation of attribution status for violations.
4. Reserve funds withheld pending an appeal window on flagged activity.
5. Public builder directory with reputation signals so downstream users can evaluate which builders they trust.

Technical requirements

Standard requirements to become a builder:

• HMAC-signed API requests with a builder-specific API key.
• Attribution code embedded in each trade request via header or payload field.
• Webhook endpoint to receive fill and settlement events.
• Idempotency handling for request retries.
• Compliance with platform rate limits.
• Sandbox environment for testing before going live.

Legal considerations

Builders operating trading interfaces face regulatory classification that varies by jurisdiction. In most modern frameworks, builders who do not custody user funds and route trades to a licensed platform operate as introducing brokers or interface providers. Builders who custody funds or process user KYC face additional licensing requirements. Most modern builder programs require the platform to hold custody so builders operate as pure interface providers.