Skip to main content
​
MCPv0.17.6

​
Connector v0.17.5–v0.17.6: clearer tool names

Eleven connector tools have new names that say what they return. The old names keep working as aliases, with the same inputs, plan and output, but the connector no longer lists them; update saved prompts and agents when convenient.Tool titles and descriptions across the catalog were reworded to describe the data plainly, and the connector’s server instructions are now reference notes (coverage, which tool answers which question, freshness, plans and tier names). Tier parameters now list only the current tier names (Apex, Sharps, … Heavyweights, …); the older tier identifiers are still accepted. The best_traders_positioning prompt is now tier_positioning_by_coin. No endpoint, output or plan changed. The catalog is still 115 tools (114 advertised while builder_heatmap is withheld). See the MCP tool catalog.
​
APIMCPv0.17.4

​
Sharpe ratios in the connector, and every pending TP/SL order on Hyperliquid

Sharpe ratios (Starter). The realized-PnL Sharpe from October 13 is now in the connector, with two new ways to slice it. Four tools, each with its endpoint:
  • pulse_sharpe_leaderboard — /pulse/sharpe-leaderboard: the 50 most consistent wallets over the last 30 completed UTC days, among wallets with at least $2,500 of stored equity. **New:** activity floors `minActiveDays` (default 10 fill days) and `minPnl` (default $1,000 of window realized PnL), applied before ranking; each row reports activeDays
  • pulse_trader_sharpe — /pulse/trader/{address}/sharpe: one wallet’s 30-day score
  • New: pulse_trader_sharpe_interval — /pulse/trader/{address}/sharpe/interval: any window of 1–90 completed days within the last 90. Out-of-range windows are rejected, not clamped: a bad startDay or a window outside the last 90 days is a 400, a days value outside 1–90 a 422
  • New: pulse_trader_sharpe_monthly — /pulse/trader/{address}/sharpe/monthly: three buckets, newest first — 3 × 30 days, or the current and two previous calendar months — to see whether a wallet is getting more or less consistent
Sharpe filters on nine cohort and positioning endpoints and their tools — /live/cohort-bias/{coin}, /live/positioning-by-entry/{coin}, the lifetime cohort positions and trades, and the five /pulse/cohorts-recent/* drill-downs: minRecentSharpe (30-day score, refreshed hourly) and minTotalSharpe (full-history score, refreshed daily) keep only wallets above a threshold, so “how are Apex wallets positioned on BTC” can become “how are the consistent Apex wallets positioned”. Filters use each wallet’s current score and do not change any endpoint’s tier.The method is unchanged and stays a proxy: √365 × mean daily realized PnL ÷ its standard deviation, with no equity normalization and no fees, funding or unrealized PnL. It rewards consistency, not size. The leaderboard’s default floors keep few-day and few-dollar wallets off it, but the wallet scores and cohort filters have no activity floor, so read the score with realizedPnl and trades. See Sharpe ratios.TP/SL trigger orders (Pro). Every untriggered stop-loss and take-profit order on Hyperliquid, one by one with the wallet that placed it:
  • book_triggers — /market/book/triggers/{coin}: every pending trigger order on a market
  • pulse_trader_trigger_orders — /pulse/trader/{address}/trigger-orders: one wallet’s pending triggers, across markets or for one coin
One exchange-wide snapshot covers native perps, builder dexes and HIP-4, refreshed roughly every minute, latest only (no history); a snapshot older than 1,200 seconds (20 minutes) is a 503 rather than a stale answer. Pages are pinned to a snapshot with snapshot_height. book_stop_map keeps the bucketed view; these are the orders behind it (Hyperliquid’s own API returns trigger orders one wallet at a time — this is the whole exchange in one call). See TP/SL trigger orders.The catalog is 115 tools, up from 109; builder_heatmap is still withheld, so the connector advertises 114. The API has 124 endpoints.
​
APIMCPPricing

​
Starter now includes live positioning, risk and the chart

Starter ($29/month) now includes the “right now” tools that most people use:
  • /live/cohort-bias/{coin} (live_cohort_bias)
  • /live/liquidation-heatmap/{coin} (live_liquidation_heatmap)
  • /live/risk/overview and /live/risk/coins/{coin} (live_risk_overview, live_coin_risk_snapshot)
  • /live/risk/liquidations/recent and /live/risk/liquidations/summary (live_recent_liquidations, live_liquidation_summary)
  • /pulse/market/candles/recent/{symbol} (market_recent_candles, the interactive chart)
  • /market/book/summary/{coin} (book_summary)
Free now includes official open interest for one coin, /live/official-oi/{coin} (live_official_oi), for the last 24 hours. A longer window on Free or Starter returns the last 24 hours with a note; Pro keeps the 7-day default and up to 30 days.New on Starter (beta): realized-PnL Sharpe. GET /pulse/sharpe-leaderboard ranks the top 50 wallets with at least $2,500 of stored equity, and GET /pulse/trader/{address}/sharpe scores one wallet. The score is annualized: √365 × mean daily realized PnL ÷ its sample standard deviation over the last 30 completed UTC days, counting days without fills as zero. It is a proxy, not a portfolio Sharpe: it is not normalized by equity and excludes fees, funding and unrealized PnL. REST only for now; the connector tools follow once the leaderboard has minimum-activity filters.Pro ($199/month) keeps the history and depth behind those snapshots: cohort-bias, risk and open-interest history, the chart’s Coinversa layers (entry profile, average entries, Apex vs Crowd history, biggest trades), cohort drill-downs, entities, and the per-order book tools. On a Starter key the chart keeps its candles, indicators and the Starter snapshots, and marks the Pro layers with an upgrade link. The full list is in the tier matrix.A plan limit is now an answer, not an error, in the hosted connector (https://mcp.coinversa.ai/mcp; the npm stdio package picks it up in its next release). When a key’s plan does not include a tool, the result says which plan it needs and the price, which plan the key is on, and where to upgrade. Where the key’s plan allows it, the result also includes a partial answer from tools the key can call, such as the current price and long/short ratio for the same coin. Every gated tool’s description now states its plan. See When the plan does not include a tool. The REST 403 is unchanged.
​
MCPAPIv0.17.0

​
Connector v0.17.0: an interactive chart with Coinversa layers, and two new endpoints

market_recent_candles gains an interactive MCP Apps chart for Pro users, with candlesticks, dollar volume and technical indicators. The chart is not just a price chart: alongside candles and indicators it draws where open positions got in, who holds them and how Apex and The Crowd have moved — data a standard exchange chart does not show, because it comes from every open Hyperliquid position matched to its wallet’s cohort. Text-only clients keep the candle result. Use market_price for a quick price lookup and market_recent_candles for chart questions.Two new Pro endpoints, each with a matching tool:
  • Positioning by entry — /live/positioning-by-entry/{coin} and live_positioning_by_entry. Open positions bucketed by entry price, long vs short and by cohort, with each cohort’s average entry, average leverage, in-profit vs underwater notional and notional near liquidation — against Hyperliquid’s live mark, with the stored mark’s divergence disclosed. A current snapshot, never a history.
  • Whale trades — /live/whale-trades/{coin} and live_whale_trades. The largest fills by USD notional over up to 24 hours (default $1M, floor $100K), with both counterparties’ cohorts and what each fill did to their position. “Whale” means the trade is large, not the size tier; the aggressor is not recorded.
/live/cohort-bias-history/{coin} takes tiers (several series in one call, e.g. tiers=apex,crowd), format=layer (a chart envelope with a −1..1 net bias, explicit UTC window, per-series hour counts and provenance) and tierType=pnl_recent (30-day PnL cohorts — who is winning now). History stays honest: missing hours stay missing, and because some hours are reconstructed with today’s labels the envelope marks it backtestSuitable: false. live_cohort_bias_history gains the same options and reaches back 90 days./pulse/market/candles/recent/{symbol} now has an explicit contract: limit up to 500 (larger values are clamped, with X-Limit-Clamped: 500), an interval allowlist (1m, 5m, 15m, 1h, 4h, 1d — anything else is 422), 404 for a market Hyperliquid does not list, and a 15-second cache. The connector applies the same 500 cap, clamping larger values rather than rejecting them; aggregated intervals can contain fewer output bars because the cap applies to their source history. Volume is USD notional; hourly-source bars estimate it from base quantity and typical price before aggregation. VWAP uses base quantity: sum(HLC3 × base quantity) / sum(base quantity), resetting at the UTC day for intraday candles and anchoring at the first loaded bar for daily candles. When the source lacks base quantity, VWAP is unavailable.The chart has a searchable market picker, cached market/interval switching, synchronized indicator panes, candle readouts, keyboard inspection, and local pan/zoom/range controls. list_markets supports case-insensitive symbol search before pagination, including builder-dex symbols such as xyz:GOLD; inactive listings remain hidden by default. Refresh fetches candles explicitly and retains the previous chart on failure; liquidation and cohort snapshots refresh separately. Host-supported expansion and a previewed analysis prompt connect chart exploration to the conversation; hosts without text messaging keep the prompt available for copying.A Market read strip explains the indicators in plain English (momentum, trend, MACD, Bollinger, and with Coinversa overlays on, positioning and the nearest liquidation cluster), with the number behind each item. It describes data, not trades. An optional Stochastic (14, 3, 3) pane and RSI zone markers are under Indicators.Under Layers, Entry profile, Average entry lines, Apex vs Crowd history and opt-in Biggest trades join liquidation levels, with an all-time / 30-day PnL grouping. Biggest trades shows, by default, up to 50 fills of $100K or more from the last 24 hours (window and size filters adjustable). Each layer loads once, says how fresh it is, and never polls. A new Share composer turns the chart or a cohort positioning card into an X landscape or Instagram portrait PNG, rendered on your device and never posted for you. Interactive availability depends on MCP Apps being enabled and supported by the client.The catalog is 109 tools, up from 107 (adds live_positioning_by_entry and live_whale_trades). builder_heatmap is still withheld while its rollup backfills, so the connector advertises 108. See Chart layer endpoints and the interactive chart notes.
​
WebSocket

​
Derived quotes: bbo, l2Book and allMids

Three feeds now publish a derived view of the same resting book l4Book is built from, instead of the raw orders. Two of them are on every plan.The catalog is twenty-four feeds, up from twenty-one.bbo sends a message only when the top of book changes. l2Book and allMids each replace their whole view on every frame — the top-20 depth and the entire mids map respectively — so neither is a diff stream, and applying them as diffs corrupts the result.allMids is an initial version and is narrower than Hyperliquid’s own: it covers native perpetual markets only, with no spot, no builder dexes and no fall back to the last trade when a book side is empty. A coin missing either side is omitted from the map, so absence means one-sided, not zero.All three share one book per coin. The subscribe is acked at once; what waits is the first data frame, while the server re-requests the snapshot every 250 ms behind that ack. If the book is not ready in 2 minutes (bbo, l2Book) or 5 minutes (allMids), quote book warming up arrives instead of the snapshot. Do not time out waiting for the first frame sooner than that. seq is the source book height and skips blocks that changed nothing visible.
​
MCP

​
Connector v0.13.0: payload controls on the five heaviest tools

live_risk_overview, live_coin_risk_snapshot, list_assets, hip4_questions and pulse_trader_daily_stats returned payloads with no way to trim them. All five now take shaping parameters — include, search, detail, status, startDate/endDate, and limit/offset as each one warrants — and every capped response carries totalCount, truncated and a note naming the next offset.These are applied by the connector, after it fetches the endpoint. The API routes take none of them: /live/risk/overview and /hip4/questions accept no query parameters at all, /live/risk/coins/{coin} and /pulse/trader/{address}/daily accept only their path parameter, and /assets accepts only crossMarketOnly. A route ignores a parameter it does not declare, so GET /assets?limit=3 still returns all 415 assets. See Connector-side parameters.The catalog page also now lists builder_lifecycle, builder_journey and builder_orders (shipped in 0.11.1 but never added) and drops pulse_market_overview, removed in 0.12.0. builder_heatmap is registered but withheld while its hourly rollup backfills, so the connector advertises 106 of its 107 tools.
​
WebSocket

​
TWAP statuses: the node’s own state machine, with a live-set snapshot

Two new Pro feeds close the last gap in the TWAP product. twapStatuses and twapStatusesByUser carry the node’s own TWAP state machine — activated, waiting on a trigger, finished, terminated, stopped, or refused mid-run — and a subscription opens with a snapshot of the TWAPs running right now. The catalog is twenty-one feeds, up from nineteen.
That makes three views of one TWAP, joined on twap_id:Two things to know before building on it. The snapshot reports its own coverage: complete says whether the upstream reaches back far enough to hold every activated TWAP, and coverage_from_ms is the oldest block time it has applied — when complete is false, a TWAP that activated before that bound may be missing from the set, so apply the stream on top of the snapshot and insert a twap_id you had not seen rather than discarding the event. And twapStatuses sequences on the source block height, while its sibling twapOrders sequences on a nanosecond replica timestamp: the two views join on twap_id, never on seq, and one cursor cannot span them.There is deliberately no twapStatusesByUsers — this is the one wallet-scoped family with no multi-wallet list variant. Follow a set of accounts by filtering the unfiltered feed on state.user.Full contract in TWAP statuses; the snapshot and error frames are on the wire protocol page.
​
WebSocket

​
Multi-wallet feeds: 1,000 addresses on one subscription

Every by-user websocket feed now has a list variant that follows a set of wallets on a single subscription. The catalog is nineteen feeds, up from fourteen.Each carries exactly what its singular feed carries — the same [wallet, fill] pairs, liquidation objects or replica updates, under the same seq — filtered to any wallet in the list. The wallets go in a required users JSON string array:
A list holds up to 1,000 distinct wallets, and counts as one subscription against your per-connection cap. The ceiling is the same on every plan. (Hyperliquid’s own websocket allows ten unique users across every user-specific subscription per IP — that ceiling is what these feeds exist to lift.) The list is hashed as a set, so order and duplicates never change the subscription id: a copy-trading bot re-sending its roster in a different order rejoins the same stream rather than opening a second one.Full contract in multi-wallet subscriptions; the refusal strings are on the wire protocol page. The singular feeds are unchanged.
​
APIMCP

​
L4 order book: four tools, four routes, and the wallet on every order

Four question-shaped views over the order-level book — every resting order with the wallet behind it, not an aggregated ladder. Each answers one question rather than handing you a book to parse:All four are Pro. /market/book/coverage is Free and reports coins covered, the latest L1 height and how fresh it is.The wallets join to the trader tools. book_whales returns addresses that go straight into pulse_trader_profile — so “who is holding up this bid, and are they any good” is one follow-up call. That join is the reason these exist as question-shaped views rather than a raw book dump.
The coin is CASE-SENSITIVE on these four, unlike every other coin-taking tool. It must be the node’s own spelling — BTC, xyz:GOLD, #28200. btc returns a 404 carrying a hint rather than being normalised, because the rollups are keyed on the node’s own spelling.
Snapshot-derived and latest-only: one row per coin, replaced when its block height advances, so there is no history. Every response carries as_of_height and age_s — check age_s before citing a number, and past the staleness ceiling the routes answer 503 rather than serving a stale book. data_coverage gains a book dataset. For the aggregated L2 view with no tier gate, market_orderbook is unchanged.Full contract: MCP tools and tier matrix.Connector v0.12.0 is published — npx @coinversaa/mcp-server now carries these four tools, taking the catalog to 107. It also picks up two data_coverage fixes that shipped between releases: source calls are now sequential and paced 250 ms apart, with 429 backoff, so a coverage call no longer burns a key’s burst allowance. Anyone pinned to 0.11.1 has been hitting the old behaviour.
​
API

​
Five new feeds: allCandles and TWAP

allCandles streams the same OHLC candles as candle for every market at once on one subscription — interval and an optional source, no coin. Starter and above.twapSliceFills and twapSliceFillsByUser carry every fill the node attributes to a TWAP order, as the node’s own [wallet, fill] pairs — so a client that already reads trades reads these unchanged. Group by twapId to follow one order and sum sz to track its executed size. Starter for the unfiltered feed, every plan for the by-user one.twapOrders and twapOrdersByUser carry TWAP placements, refusals and cancellations. Refusals are emitted rather than dropped, because a refused TWAP leaves no other trace anywhere on the network — filter on update_type if you only want orders that ran. Pro and above.twap_id is the join key between the two: one gives an order’s terms, the other its executions. Subscribe to both for a wallet and join on it.
A refused TWAP comes back from the node with an outer status of ok. Acceptance is read from the inner response.data.status, never from the outer status alone. If you reimplement this against raw node output and check only the outer status, you will report TWAPs as started that never ran — and the only symptom is slices that never arrive.
Also on candle: a closed candle is now republished once with "closed": true (an omitempty addition, so nothing that ignores it is affected). Without it the newest candle had to be treated as open indefinitely. Hyperliquid’s own channel has no such flag, so this is an addition rather than parity.And for the record, since it reads like a bug and is not: 1M is thirty days, not a calendar month, and 1w opens on a Thursday. Every interval is a flat bucket floored against the Unix epoch. That is measured against api.hyperliquid.xyz, where every observed 1M bucket is exactly 30 days wide — keeping 30 days is matching Hyperliquid.
​
API

​
candle — live OHLC on every plan

candle streams live OHLC candles for one market on one of 14 intervals (1m … 1M). It is the first new websocket feed since launch that is not Pro-gated: it is on every plan, Free included.
Candles are trade-based by default — built from fills, so o/h/l/c are traded prices, v is traded base volume and n is the trade count, the same meanings Hyperliquid’s own candle channel carries. Both sides of a trade arrive as separate fills under one tid, and volume is counted once per tid rather than once per fill, so v matches Hyperliquid instead of doubling it. Trade candles sequence on the source block height, like the fill and book feeds.The previous mark-price behaviour is still available, now opt-in as "source":"mark". It is byte-for-byte what it was. source defaults to trade before the subscription id is hashed, so an omitted source and an explicit "trade" are one subscription, not two.
On source: "mark", v is always the string "0" and n counts mark-price observations, not trades. A mark-price update carries no traded size. Hyperliquid client code pointed at a mark candle compiles, runs, and quietly produces zeros in volume and a wrong VWAP — nothing errors. Mark candles also sequence on the replica block’s Unix timestamp in nanoseconds rather than on block height, so one candle channel can carry both kinds of seq depending on the argument; see sequence numbers.
interval is case-sensitive and it bites: 1m is one minute, 1M is 30 days, and both are valid, so an upper-cased argument subscribes successfully to the wrong interval. coin is not case-sensitive here — btc and BTC are one subscription — and s echoes the market as the data spells it. A value outside the allowed set is refused in band with a new exact error string, invalid argument <arg> — invalid argument interval and invalid argument source. Full contract: candles.
​
API

​
Four new websocket feeds: liquidations and leverage

liquidations and liquidationsByUser stream every liquidation on Hyperliquid as it lands — the liquidated account, the counterparty that took the other side, the coin, the penalty fee and the realized loss. Filtered out of the same fill stream, so they carry the source block height as seq like every trade feed.
leverageUpdates and leverageUpdatesByUser stream accepted leverage and isolated-margin changes read from the node’s replica-command stream — leverage, isolated_margin and top_up_isolated_margin, with the account each one applied to. Rejected actions never appear: every request is paired with its accepted response by bundle hash and action index before anything is published as an applied change, and user comes from the response rather than the broadcaster, so an agent-signed action reaches the account it applied to.
All four are Pro and above, and all four accept any address — not only wallets you control. Full field tables: feeds and the fill object.
seq is no longer one kind of number. It stays the source block height on the fill, liquidation and book feeds, but leverageUpdates sequences on the replica block’s Unix timestamp in nanoseconds, because the replica stream does not expose its height outside the payload. Both only increase and both are valid reconnect cursors — but never compare one against the other, and never hold a single “last seq” across a mixture of the two. See sequence numbers.
​
APIBreaking

​
seq is now the source block height

Breaking for any client that checks sequence contiguity. seq used to be a per-subscription counter that started at 1 and incremented by one per frame. It is now the source block height, the same number on every feed. A client that checks seq === last + 1 will report almost every frame on a filtered feed as a lost message.
Check that seq increases, not that it increases by one. A filtered feed sends no frame for a block that matched nothing, so tradesByCoin on a quiet coin legitimately skips hundreds of numbers between frames. What is actually broken is seq going backwards or repeating — the chain only moves forward, so that means frames were replayed or reordered.On l4Book the snapshot now carries seq equal to its height (it was 0), and every update carries seq == height. The replay-bridge frames that used to arrive with seq: 0 are gone. Keep gating the book on prev: it names the exact predecessor block, which seq alone does not.New: resume instead of starting over. Pass the last seq you applied back on resubscribe and the server replays what you missed, with no snapshot:
Retention is 10,000 messages per feed per connection manager, and an idle feed group stays warm for 60 seconds; past either you get sequence is not retained or sequence is older than retained history, and should subscribe without the cursor. sequence and snapshot are control data — they do not change the subscription id, so a resume continues the same subscription. To skip initial state entirely, pass "snapshot": false.Also changed: the 8-concurrent-l4Book-subscriptions limit is gone — book subscriptions count against the per-connection cap like any other. Book failures no longer arrive as {"channel":"l4Book","error":…,"reason":…}; they are dropped and reported on the ordinary error channel, without the coin on them.Expect a slower first book frame. The server now buffers about 105 source blocks before it fetches the snapshot, so it has history to join the snapshot onto. A cold subscription commonly waits 10–60 seconds, up to about 100 if all ten attempts are needed — but only on a coin nobody else is subscribed to: a warm feed group passes straight through. Two new errors end the wait, snapshot buffer did not fill and snapshot is older than retained history. The 30 MB message requirement for BTC is unchanged.See sequence numbers, reconnecting and Order book (L4).
​
API

​
The full L4 order book, with wallets, on the WebSocket

A new feed, l4Book, streams the complete order book of one Hyperliquid market — every resting order with the wallet behind it, plus the untriggered stop and take-profit orders — straight from the node, as one snapshot followed by a diff message per block (Hyperliquid’s own public l2Book aggregates by price level; this is the order-level book, with the trader on every order). Any market the node knows, spelled as the node spells it: BTC, xyz:GOLD, #28200. The server holds no book; you apply the diffs, and the wire gives you what you need to do it safely — height and prev chain every block, empty blocks are still sent so silence is detectable, and a partial flag marks a block the node only half delivered. The client rule is one line: apply an update only if its prev is the last height you applied; otherwise reconnect with the last seq you applied, falling back to a fresh snapshot if that cursor is no longer retained.Pro and above, and listed in the connected frame’s limits.feeds when your account has it. Two things to size for: the snapshot is the whole book in one message — about 30 MB for BTC, a few KB for most coins — so set your client’s read limit, and book subscriptions count against your connection’s subscription cap like any other. Read the feed page at Order book (L4), copy an order-book client in Browser, Node, Python or Go, and see the plan limits for how snapshots count against fair use.
​
API

​
Browsers can connect to the WebSocket directly

A browser WebSocket cannot set headers, so until now no page could authenticate to wss://ws.coinversa.ai. The connection manager now also takes the key as the second subprotocol after the literal bearer — new WebSocket(url, ['bearer', key]) — so a dashboard or tool of your own can stream fills with no relay. The key still travels in a request header, never in the URL, and the Authorization header keeps working unchanged for every other client. A browser cannot read the HTTP status of a refused upgrade, so on this path the three refusals arrive as close codes instead: 4401 invalid or missing key, 4429 connection cap full, 4503 entitlement lookup unavailable. Details in WebSocket authentication.The portal’s Usage page now shows websocket usage honestly: bytes delivered against the fair-use allowance, frames and connections opened for the period, and connections and subscriptions open against the account’s resolved caps — enterprise overrides included — updated every minute.
​
API

​
The WebSocket API is live

Every fill on Hyperliquid — native perps, the seven builder dexes, spot — streamed over one socket at block cadence, with the trader’s wallet on every fill and closedPnl, dir and startPosition already attached. Three feeds: trades (the firehose, Starter and above), tradesByCoin and tradesByUser (every plan; tradesByUser takes any address, not only wallets you control). Frame shapes are Hyperliquid-compatible, so existing client code is familiar, and every data frame carries a per-subscription seq so you can tell what you missed.Authentication is your existing API key, sent as Authorization: Bearer on the HTTP upgrade — there is no separate websocket key and no auth frame. Limits are on capacity, not messages: connections per account (shared across your keys), subscriptions per connection, and a fair-use bandwidth allowance; streaming never draws down your REST quota. Start at the WebSocket overview, copy a working client, and read the plan limits.
​
API

​
Builder analytics arrives on MCP (connector v0.11.0)

The eight builder-analytics endpoints are now first-class MCP tools on both the hosted connector (https://mcp.coinversa.ai/mcp) and the npx package (@coinversaa/mcp-server@0.11.0), taking the tool surface from 91 → 99: builder_leaderboard, builder_profile, builder_traders, builder_fills, builder_cohorts, builder_retention, builder_overlap, and the inverse trader_builders. Ask your agent “which frontends do MetaMask’s traders also use?” and it can answer from cross-builder attribution no other data source has. Full catalog in MCP tools; endpoint semantics in Builder codes & attribution.

​
Builder analytics: ledger-exact revenue for every builder code

Eight new REST endpoints cover the Hyperliquid builder-code economy — the fees that front-ends, wallet apps, bots, and builder dexes earn on the order flow they route. Revenue is computed from Hyperliquid’s own on-chain cumulative builder-fee ledger (validated to ±0.1% against the chain); fill-level detail comes from order→fill attribution. See the new Builder codes & attribution concept page and the endpoint guide.Starter:
  • GET /builders/leaderboard — every builder ranked by exact ledger revenue, with attributed volume/users/fills and prior-period deltas.
  • GET /builders/{builder}/profile — one builder in depth: revenue, daily series, top coins, user base, fee rate, first/last seen.
  • GET /trader/{address}/builders — which builders a wallet trades through, ordered by fees paid.
Pro:
  • GET /builders/{builder}/traders — the builder’s users with PnL, fees paid, equity, and cohort tiers.
  • GET /builders/{builder}/fills — the raw attributed fill stream (perp / spot / HIP-4), filterable by coin and wallet.
  • GET /builders/{builder}/cohorts — who actually uses the builder: user composition by PnL and size tier.
  • GET /builders/{builder}/retention — a 12-month monthly retention triangle of first-order cohorts.
  • GET /builders/{builder}/overlap — the top 10 other builders a builder’s users also trade through (cross-builder switching — only possible with all-builder attribution).
Every response carries a verified stamp (the ledger block and chain time it was checked against) and a dataNotes disclosure. Attributed history is complete since 2025-01-25 (most trackers’ builder data starts around August 2025). Honest caveat: trigger-order (stop/TP) fills currently attribute at ledger level only — per-builder attribution coverage is ~77–95% while the backfill completes (live capture since 2026-08-20, backfilled to 2026-03-24) — so attributed fills/volume/users slightly undercount versus the exact ledger revenue; every response says so in dataNotes.All 8 endpoints also ship x402 pay-per-call twins — the first x402 surface in the docs (every GET endpoint has carried a keyless /x402 twin since May 2026; builder analytics is where we make it official): no API key, price quoted in the 402 challenge.In review: order-level lifecycle/journey/heatmap endpoints, weekly and revenue-weighted retention, and a live attribution-coverage ratio in the verified stamp. Builder MCP tools are also on the way.
​
API

​
Cohort tiers renamed

The trader cohort tiers have new display names and new canonical input slugs. The new slugs are rolling out with this release everywhere a tier is an input — path parameters, query parameters, and MCP tool arguments. Until the rollout reaches your endpoint (and until your MCP connector refreshes its cached tool schemas, which may still list only the legacy slugs), keep sending legacy slugs if a new slug is rejected. Nothing breaks either way: legacy slugs remain accepted on input indefinitely, and responses are unchanged — they continue to return the legacy slugs (e.g. pnlTier still returns money_printer).See Trader cohorts for the full tier reference.
​
API

​
Liquidation intelligence: notional, sides, and cohorts

The liquidation summary (GET /live/risk/liquidations/summary) now returns the full two-layer picture:
  • totalNotional — liquidated position value (the industry-standard headline number), alongside the existing totalClosedPnl realized losses.
  • longNotional / shortNotional and event counts — which side got force-closed.
  • byCohort — liquidated notional, losses, events, and wallets broken down by behavioral tier. See who actually gets liquidated.
  • wallets — distinct liquidated wallets in the window.
The same aggregates power the explorer’s new public liquidations page. Fields are additive — existing consumers are unaffected.
​
API

​
The Daily Pulse — frozen daily editions via the API

Two new FREE-tier endpoints expose The Daily Pulse, the auto-generated Hyperliquid morning edition:
  • GET /pulse/daily/{date} — the edition for a given YYYY-MM-DD date. Editions are frozen: once stamped (00:05 UTC), the document never changes, so any past date returns exactly what it returned on day one.
  • GET /pulse/daily/latest — the newest edition.
Each edition carries the surprise-ranked stories (whale moves, cohort divergences, OI rotations, liquidation spikes, settlement upsets) with full receipts, matched news headlines, the standing blocks (biggest moves, coin movers, settlements), and the chain-state census stamp the numbers were verified against.Also in recent releases: lifecycle fills now carry per-fill PnL/fee attribution fields (attributedPnl, attributedFee, attributedSize, rawClosedPnl, fillPnlBasis), and cohort bias responses include netBiasByCount / netBiasByNotional.
​
Security

​
Zero-knowledge connector: your API key never leaves our backend

The hosted MCP connector’s credential handling has been rebuilt end to end:
  • Connecting no longer transmits your API key. Picking a key on the authorization page hands over a single-use connect code (2-minute lifetime, dead after first redemption). The MCP server exchanges it server-to-server for an opaque key reference — the raw key never touches the browser or the connector host.
  • Pick any existing key. The authorization page now lists your active keys — connect one in a click, no need to have the value saved and no forced duplicate keys.
  • Encryption at rest for everything else. Sessions from the paste-a-key flow are now AES-256-GCM-encrypted under a key held outside the database, and all OAuth bearer tokens are stored as SHA-256 digests. A stolen copy of the connector’s database yields nothing.
  • Tiers, rate limits, metering, and instant revocation behave exactly as before — revoking a key still disconnects every agent authorized with it.
​
Connector

​
One-click connect: OAuth sign-up on the hosted MCP

Connecting Coinversa to Claude, Perplexity, Cursor, or any MCP client no longer requires copying an API key. Paste https://mcp.coinversa.ai/mcp into your client and it opens the new authorization page:
  • Existing users sign in with their Coinversa account and connect a key in one click — or paste a saved cvsa_ key directly.
  • New users create an account right on the page. Every new account gets 14 days of Pro — all 99 tools, no credit card — and the key is provisioned automatically.
  • Keys stay visible once at creation and revocable any time from the developer portal; revoking a key disconnects every agent authorized with it.
See the updated MCP setup guide — client configs no longer need auth headers.
​
v0.9.0

​
Entity resolution, tier-aware sessions & exchange aggregates

Pulse 0.9.0 adds owner-level intelligence: Hyperliquid traders run named sub-accounts that trade independently, so per-wallet views undercount every multi-account trader. Pulse now resolves any wallet to its owner entity and aggregates across the whole family — a view no other Hyperliquid data product offers. Under the hood, the position dataset is now reconciled hourly against Hyperliquid’s own chain state (the census pipeline), and responses carry the chain block they were last verified against.

​
New features

  • Entity resolution — GET /entity/{address} resolves any wallet (master, sub-account, or unknown) to its owner entity: master address, every named sub-account, each member’s open book, the combined positions across all of them, and a verified-vs-chain stamp. GET /entities/leaderboard ranks the top owners (not wallets) by combined open notional. Both Pro tier. MCP: pulse_entity_profile, pulse_entity_leaderboard.
  • Exchange aggregates — GET /exchange/volume (24h volume by dex — builder dexes are ~43% of Hyperliquid volume and most trackers’ headline numbers omit them), GET /exchange/oi (open interest by dex with long/short split), GET /exchange/active-traders (24h distinct traders). MCP: pulse_exchange_volume, pulse_exchange_oi, pulse_active_traders.
  • Plan introspection — GET /plan returns the caller’s tier, effective limits, and every tier’s limits with an upgrade link. MCP: pulse_my_plan.
  • Chain-verification stamp — GET /census/stamp exposes the chain-state block the dataset was last reconciled against; entity responses include it inline.

​
Updates

  • Tier-gated and rate-limited responses are now machine-actionable: 403s carry current_tier, required_tier, and an upgrade_url (code TIER_GATE), so agents can explain exactly what a request needs instead of a bare “forbidden”.
  • The MCP tool surface grew from 83 → 91 tools; the REST API from 87 → 96 endpoints.
  • Data-accuracy note: this release follows a full reconciliation of the position dataset against Hyperliquid chain state — open positions, open interest, and volumes now match independent trackers to well under 1%, with the residual continuously verified.
​
v0.8.0

​
Position lifecycles & execution quality

Pulse 0.8.0 is built on a fully re-derived position-lifecycle dataset — every position reconstructed open→close from on-chain fills, now carrying MAE/MFE (the worst adverse and best favorable price each position ever saw). For the first time you can analyze execution quality, not just realized PnL.

​
New features

  • Position lifecycles — per-wallet open→close history, aggregate lifecycle stats, single-lifecycle drill-downs (with composing fills), and a one-call wallet briefing. See Position lifecycles.
  • Execution quality (MAE/MFE) — per-position drawdown / run-up curves, “max-pain” survivors (winners that endured deep drawdowns), perfect exits (high MFE capture), and the most catastrophic individual liquidations.
  • Trader archetypes — survivors & anti-survivors, persistent winners, capital-efficient titans (PnL per fee), one-month wonders, newcomer whales, coin kings, top liquidators, and lethal coins — all derived from 90-day lifecycle behavior.
  • Market structure — per-coin winner/loser profit pools, profitability by UTC hour, alpha concentration (percentile profit share), HFT-vs-swing-vs-holder splits, and head-to-head wallet comparison.
  • Refreshed cohorts — pulse_cohort_recent_* tools label wallets by their last-30-day tier (not all-time), surfacing who is printing right now.
  • Global recent feed — pulse_lifecycles_recent streams the most recently closed positions across the entire exchange.

​
Updates

  • The Pulse MCP tool surface grew from 55 → 91 tools — see the full catalog in MCP tools. The REST API now exposes 96 endpoints.
  • The legacy closed-position tools (pulse_trader_closed_positions, pulse_trader_closed_position_stats, pulse_recent_closed_positions) are kept for backward compatibility but are superseded by the lifecycle tools, which read the corrected lifecycle dataset (more history, MAE/MFE, spot coverage).

​
Notes

  • MAE/MFE is perp-only (spot positions have no adverse/favorable excursion by design). The freshest closes may briefly show null MAE/MFE while the hourly risk backfill catches up.
​
v0.7.0

​
HIP-4 outcome intelligence

Coinversa Pulse now indexes the full HIP-4 outcome-contract wire format from Hyperliquid, with discovery, settlement, volume, recent trades, trader overlap, and perp-position context for every outcome.

​
New features

  • 12 HIP-4 MCP tools for outcome-contract discovery, settlements, volume, recent trades, and trader overlap. See the full surface in MCP tools.
  • Outcome + perp context tool lets agents pull a trader’s open perp position alongside their HIP-4 outcome exposure in a single call — useful for hedging and conviction-overlap analysis.
  • Hosted Remote MCP is now documented at https://mcp.coinversa.ai/mcp, so you can connect agents without installing the npm package. See MCP setup.

​
Updates

  • The Pulse MCP tool surface grew from 43 → 55 tools.
  • README, agent SKILL metadata, and server instructions updated for the new HIP-4 surface.

​
Breaking changes

  • Keyless / no-API-key mode has been removed. All MCP tools now require a Coinversa API key. Grab a free-tier key from the dashboard — see Authentication and Pricing for details.