WebSocket streaming
with seq, replay and 31 channels.

No. The daily and per-minute limits meter authenticated REST requests; a frame pushed over the stream is not a request and is never written to the request log. The only REST call involved is POST /api/v1/stream/token, which has its own 10-per-minute bucket exempt from the daily and burst pools, and since 2026-08-27 returns the same token forever, so a client calls it once at boot. A PRO key with 10,000 calls/day can receive an unlimited number of pushed events.

Event frames carry seq and id; token:price ticks carry neither. seq is one ordinal per server process, shared by every channel and every customer and assigned before your filters run, so the seq values you receive have gaps in normal operation: a gap is not evidence of loss. id is stable: the same event has the same id when it is delivered live, replayed from memory or rebuilt from storage, so delivery is at-least-once and you dedupe by id. To recover, keep a cursor {instance, seq, ts} of the last frame your handler finished processing (the handler returned, or its promise settled) and reconnect with subscribe { ..., resume: {instance, seq, ts} }. The subscribed ack echoes the cursor with accepted: true. If the server is the same instance and the cursor is still inside its in-memory buffer (the last 20,000 frames, about ~6-8 min), the missed frames are re-sent from memory. Otherwise (the server restarted, or you were away longer) each channel is rebuilt from storage from your cursor's ts: at most 60 minutes back, 2,000 rows per channel and 20,000 in total. Rebuilt frames carry seq: null and mode: "durable", plus partial: true and missing[] where a field is not stored. Everything is bracketed by replay_start and replay_end, and replay_end states per channel what was sent, whether it is complete and why not. Frames that arrive live meanwhile are held and delivered after replay_end, skipping ids already sent. The older replay_since_seq / replay_since_ts fields still work and replay from memory only; they now report replay_truncated with a reason when the cursor is too old or from a previous server instance. Save your cursor only when a recovery completes: replayed frames arrive channel by channel, so on replay_end complete: true commit last_seq / last_ts, and on complete: false with retryable: true keep the old cursor and resume again after retry_after_ms (duplicates are dropped by id). A resume_ts_hint is only sent when every incomplete channel that a retry could still fill hit the row cap (a permanently missing channel does not block it); without a hint, resume from the cursor you already had. Gaps reported with retryable: false are final; backfill them from REST. When many clients resume at once, a resume can wait up to 20 s and then get reason source_busy with a retry time. How far your cursor may move is also limited by a per-channel watermark (replay_end.channels.<channel>.watermark, and watermark_safe_ts overall): a row is stamped when it is written, not when it commits, so the server only lets you commit across rows whose write had finished, holds the watermark 5 s behind now and re-scans the last 60 s on your next resume. Frames are still delivered as they are read. Recovery is bounded, not a completeness guarantee: each channel states its own bound in watermark.guarantee, a write that commits more than about 65 s after it was stamped can be missed (about 6 minutes instead while holdback_capped_ms is set), and the Robinhood Chain DEX trade channels are bounded by the producer's 600 s freshness rule, so a trade already older than 600 s when it was ingested is not recoverable that way at all. Our SDKs apply all of this for you: they retry a retryable recovery (up to 5 times per connection, with the counter reset on every reconnect; after that the gap says exhausted: true and the next reconnect picks it up) and, on a final gap, report the channels, the reason and the RANGE that may be incomplete before moving the cursor past it. That last step is the library's own decision, not your approval, and onUnrecoverableGap: "stop" turns it off. The number of missing events is never stated, because it cannot be known.

No, since 2026-08-27. POST /api/v1/stream/token returns the same token on every call, forever; expires_at and next_refresh_at are always null. It stops working only when the subscription is no longer an active PRO/ULTRA/BUSINESS plan, or when you explicitly send {"rotate": true} — after which the previous value keeps working for 60 seconds and live sockets receive a token_refresh frame. Present it as Authorization: Bearer <token> on the handshake (preferred) or ?token=; an msk_ API key is never accepted as a stream token and is closed with an explicit reason. A 4001 close means mint again, never a timer.

PRO 2, ULTRA 3, BUSINESS 10 concurrent connections on the main stream, enforced in memory by the service. PRO was raised from 1 to 2 on 2026-08-16 because with a single slot a reconnecting client evicts its own live socket. When a reconnect is refused the 4002 close reason names how long the holder has been connected; GET /api/v1/stream/sessions lists your live sessions and DELETE /api/v1/stream/sessions/{id} frees a slot without support. The DEX firehose (wss://madeonsol.com/ws/v1/dex-stream) is a separate endpoint with its own slots: ULTRA 2, BUSINESS 5.

The server sends a {"type":"heartbeat"} frame and a protocol ping every 15 seconds and terminates a socket that does not answer the ping by the next tick (close code 1006, ping-timeout). If you miss two heartbeats, reconnect and pass your resume cursor on the subscribe. Nothing is delivered until you send a subscribe message; the server sends a hint frame after 10 s if no channels are active.

token:prices is mint-scoped: filters.mints is required and capped per connection at 25 mints on PRO, 100 on ULTRA and 250 on BUSINESS. A subscribe above the cap is rejected outright, never truncated, so you never silently watch fewer mints than you asked for; a later subscribe replaces the watched set. Ticks are the pricing bus's ~250 ms coalesced updates — the same feed the site's charts run on — not per-trade. Per-trade delivery across all 14 DEX programs is the ULTRA DEX firehose.

Yes. A subscribe carrying a sub_id (1-64 characters of A-Z a-z 0-9 _ . -) opens a named subscription with its own channels and filters; update {sub_id, filters} replaces its filters, unsubscribe {sub_id} removes it, and list returns every subscription the socket holds. A subscribe without sub_id is the connection's default subscription, unchanged from before. Frames delivered under a named subscription carry sub_id, and an event that matches several subscriptions is delivered once per subscription, each copy stamped with its sub_id, so dedupe by sub_id plus id. Filters of one subscription never affect another. The cap counts every subscription on the connection, the default one included: PRO 5, ULTRA 10, BUSINESS 20; above it the subscribe is refused with a warning (too_many_subscriptions), never silently dropped. Resume works per subscription: on reconnect send every subscribe with the same cursor, the server serves the replays one after another and holds live frames until the last replay_end, and you commit the cursor at the smallest last_seq across them. The SDKs expose this as subscribe({ subId, channels, filters }), updateSubscription, unsubscribe(subId) and listSubscriptions (snake_case in Python).

Use webhooks when you cannot hold a socket open (serverless, batch jobs). The registry accepts 11 event types (kol:trade, kol:coordination, deployer:alert, deployer:bond, wallet_tracker:event, sniper:deploy, rhc:kol_trade, token:surge, token:revival, dev:activity, rhc:dev_activity); payloads are HMAC-SHA256 signed in the x-madeonsol-signature header, retried 3 times (5 s, 30 s, 2 min) and auto-disabled after 10 consecutive failures, with the owner emailed. PRO 3, ULTRA 10, BUSINESS 30 webhooks. Copy-trade, price-alert, coordination and first-touch rules deliver from the rule's own webhook_url with a per-rule secret, not through this registry; the RHC DEX firehose is WebSocket-only.

Parsed real-time delivery starts at €43/month here (2 connections, 31 channels) and the full all-DEX firehose at €131/month; Birdeye unlocks WebSocket at $199, Codex at $350, Solana Tracker's Datastream at €397 (all verified 2026-08-16). Helius gRPC offers 24-hour replay and Bitquery Kafka 4 hours — both deeper than our resume window of up to 60 minutes, but on raw or partially decoded data; among parsed WebSocket vendors we found none that publishes a per-event seq and client-side replay. If you need hours of replay on raw chain data, gRPC from an RPC provider is the better tool.