Builder ≠ builder dex. Builder dexes, such as
xyz, io, mkts and para, are one kind of builder — venues that list their own markets. But any front-end can run a builder code without being a dex (wallet apps are among the largest). This page and the builder endpoints use “builder” to mean any builder-code operator.Two data planes
Every builder response mixes two data sources with different guarantees:
The one-line rule: revenue is exact; detail metrics are attributed. When a leaderboard row says a builder earned $1.2M last week, that number reconciles with the chain. When it says 4,812 users generated it, that count comes from the fill join and can slightly undercount.
The trigger-order gap (read dataNotes)
Trigger-order fills (stop-loss / take-profit) currently attribute at ledger level only — roughly 6% of fees ecosystem-wide, which puts per-builder attribution coverage at ~77–95%. Trigger-order placements (used by/orders) are captured live since 2026-08-20 and backfilled to 2026-03-24. Their fills are not yet joined to builders, so attributed metrics undercount.
Practical consequence: attributed fills, volume, and user counts slightly undercount versus ledger revenue. Every builder response says so in its dataNotes field:
The verified stamp
Every builder response carries averified stamp, the same pattern as the census stamp on entity responses:
ledger_block/ledger_chain_time— the latest block in Hyperliquid’s builder-fee ledger this response was verified against. Treatledger_chain_timeas the freshness timestamp.coverage— null today, by design. When the attribution-reconciliation pipeline ships, it becomes a live ratio object (window_start,window_end,ledger_fees_usd,attributed_fees_usd,ratio,computed_at) quantifying exactly how much of ledger revenue the fill-level metrics account for.
coverage: null means “not yet provisioned” — it is never an error, and nothing about the response is degraded when it’s null. Don’t retry on it.Builder names
builderName comes from a curated registry of 115 known builders. When a builder isn’t in the registry, the field is omitted — never guessed. Builder addresses in responses are always canonical lowercase 0x-hex; path parameters accept any 0x spelling.
Cohort tiers on builder endpoints
The/traders and /cohorts endpoints label wallets with their exchange-wide all-time pnlTier / sizeTier, returned as legacy slugs (smart_money, whale, …) per the trader cohorts vocabulary. These are lifetime classifications — the pulse cohorts-recent endpoints classify by 30-day-rolling tiers, so the same wallet can carry a different tier there. Wallets not yet in the cohort rollup appear as null tiers on /traders and in an untracked bucket on /cohorts, so per-tier user counts always sum to totalUsers.
History depth
Coinversa’s copy of the builder-fee ledger begins 2026-08-11. Windows that reach earlier serve revenue from the attributed rollup (a floor, ≥97% of ledger on reconciled days), anddataNotes says so. Attributed history is visible through the retention endpoint’s 12-month cohort triangle and the firstSeen / lastSeen timestamps on builder profiles.
Per-request query windows are narrower than the underlying history: period is day | week | month, and since parameters clamp to 90 days — see Data windows.
Which endpoint answers what
Cross-builder overlap is only possible because Coinversa attributes fills for all builders, not one — a single-builder integration can’t see where its users go.
Builder analytics is available over REST, x402 pay-per-call and the MCP connector — eleven
builder_* tools plus trader_builders, the per-wallet inverse.