# Supanode — full documentation > High-performance multi-chain RPC & data infrastructure for Solana, Hyperliquid, > Polymarket, Monad, and BNB (a brand of Hightower LLC): JSON-RPC, Yellowstone gRPC > streaming, ShredStream (UDP shreds), WebSocket feeds, stake-weighted TPU > transaction landing, ClickHouse indexers, and dedicated nodes. Provisioning > is manual via Telegram, and Solana RPC/gRPC/WebSocket authenticate with an access token. > > This file concatenates every documentation page in sidebar order, followed by > agent briefs for every marketing page. Per-page markdown is also available at > /docs/.md and by appending .md to any site URL. HTML lives at /docs/. --- ## Welcome to Supanode Source: https://supanode.xyz/docs/welcome > Supanode is multi-ecosystem blockchain infrastructure — streaming, transaction landing, indexing, and dedicated nodes across Solana, Hyperliquid, Polymarket, Monad, and BNB Chain. Supanode is blockchain infrastructure for traders, indexers, and analytics teams. Pick your ecosystem in the sidebar — each one lists exactly what's available and what it costs. ## Ecosystems Full stack — RPC, gRPC, WebSocket, Shreds, TPU Sender, Indexer, Dedicated. WebSocket streaming, Indexer, Dedicated. Prediction-market Indexer. Native gRPC streaming, Dedicated. Dedicated nodes. ## What Supanode offers - **Data Streaming** — gRPC (Yellowstone), Shreds, and WebSocket. Real-time on-chain data. - **Transaction Landing** — TPU Sender with dual-path SWQoS + Jito (Solana). - **Data Analytics** — Indexer: decoded DEX and market data, queryable over SQL. - **Dedicated** — your own nodes, custom region and hardware. Not every product exists on every ecosystem — open a network in the sidebar to see its exact lineup and pricing. ## Get in touch Provisioning is manual and hands-on. Tell us what you need on Telegram and a real engineer sets you up directly, including free trials and custom plans. @supanode_tgs — onboarding, trials, and custom plans. --- ## Quickstart Source: https://supanode.xyz/docs/solana/quickstart > Get a Supanode endpoint and make your first Solana RPC call in 5 minutes, using your access token. From zero to your first successful Solana RPC call in 5 minutes. **Authorization is by token.** You get one key when your subscription is provisioned and send it as a header on every request. It is shown once - store it somewhere safe. ## What you'll need - HTTP client - `curl` works, any language with HTTP support works. - A Supanode Bundle subscription **or** active free trial. - Your access token - see [Authentication](https://supanode.xyz/docs/solana/authentication). ## How do I get access? Two paths: Choose a tier and message us on Telegram — we issue your token and you're live. 24-hour trial, no card required. Telegram us the tier you want - we set it up within hours. For details on trials, see [Free Trials](https://supanode.xyz/docs/solana/pricing/free-trials). ## 2. Make your first call The simplest possible call - `getSlot` returns the current Solana slot. The endpoint accepts the standard [Solana JSON-RPC HTTP methods](https://solana.com/docs/rpc/http): ```bash curl https://fra.sol.supanode.xyz:8899 \ -H "Content-Type: application/json" \ -H "x-token: sk_your_token_here" \ -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}' ``` `Authorization: Bearer sk_your_token_here` works just as well - use whichever suits your client. A successful response looks like this: ```json { "jsonrpc": "2.0", "result": 282729810, "id": 1 } ``` The `result` is the current slot. If you see this, your token works and you're ready to build. Got `401`? The token is missing, mistyped, or expired. Check the header name and the value, then contact [@supanode_tgs](https://telegram.me/supanode_tgs) if it still fails. ## Where to next Pick RPC, gRPC, WebSocket, or a specialized product. Code in TypeScript, Rust, Python, curl. Token auth, and how the other products authorize. 5 plans, all with free trials. --- ## Authentication Source: https://supanode.xyz/docs/solana/authentication > How access works on Supanode: a bearer token on RPC, WebSocket and gRPC, x-token plus database credentials for the Indexer, IP:Port for Shreds, and the tip for Sender. Access to RPC, WebSocket and gRPC is by **token**. You get one key when your subscription is provisioned and send it as a header on every request. **Provisioning is manual.** Subscriptions and credentials are arranged over Telegram ([@supanode_tgs](https://telegram.me/supanode_tgs)) - there is no self-serve sign-up in v1. The token itself is shown once, on issue. Store it somewhere safe; we cannot show it again. ## Authorization model by product | Product | Authorization | |---|---| | Bundle ([RPC](https://supanode.xyz/docs/solana/rpc/overview), [WebSocket](https://supanode.xyz/docs/solana/websocket/overview), [gRPC](https://supanode.xyz/docs/solana/grpc/overview)) | bearer token, sent as a header | | [Indexer](https://supanode.xyz/docs/solana/indexer/overview) | `x-token` + database credentials | | [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw) | IP:Port destination - Supanode pushes UDP to your endpoint | | [Sender](https://supanode.xyz/docs/solana/sender/overview) | open access - the tip on the transaction is the gate | | [Decoded Shreds](https://supanode.xyz/docs/solana/shreds/decoded) | to be confirmed - product is coming soon | | [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) | arranged individually on provisioning | ## Bundle - your token The same token works on all three interfaces, in either of two header forms. Pick one; they are equivalent. ``` x-token: sk_your_token_here ``` ``` Authorization: Bearer sk_your_token_here ``` A request without a valid token is rejected with **HTTP 401** on RPC and WebSocket, and with `PermissionDenied` on gRPC. ### Connecting ```bash # RPC curl https://fra.sol.supanode.xyz:8899 \ -H 'Content-Type: application/json' \ -H 'x-token: sk_your_token_here' \ -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}' ``` ```bash # WebSocket wscat -c wss://fra.sol.supanode.xyz:8900 \ -H 'x-token: sk_your_token_here' ``` ```bash # gRPC grpcurl -plaintext -import-path ./proto -proto geyser.proto \ -H 'x-token: sk_your_token_here' \ -d '{}' \ fra.sol.supanode.xyz:10010 geyser.Geyser/GetVersion ``` On RPC the token is also accepted as `x-api-key`, or as an `api-key` / `api_key` query parameter. The header forms are preferred - a query string ends up in logs and browser history. **Treat the token like a password.** Anyone holding it can spend your plan's quota. Keep it in an environment variable or a secrets manager, never in a repository or a client-side bundle. If it leaks, message us on Telegram and we will rotate it. ## Indexer - x-token plus database credentials Message us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). You receive an `x-token` plus a database username and password. HTTP Basic with the database credentials, and the `x-token` header alongside it. See [Indexer Access](https://supanode.xyz/docs/solana/indexer/access) for connection details and code samples. ## Raw Shreds - IP:Port destination Raw Shreds is a UDP push, so there is no header from your side: you tell us where to send the stream and Supanode sends only there. You give us the IP:Port on provisioning and can change it during the subscription over Telegram. One destination IP per subscription. ## Sender - open access [Sender](https://supanode.xyz/docs/solana/sender/overview) uses no token. The tip on every transaction is the gate - a System Program transfer of at least **1,000,000 lamports (0.001 SOL)** to one of Supanode's [tip accounts](https://supanode.xyz/docs/solana/sender/tips). Without a valid tip the transaction is rejected. ## Dedicated Node - custom [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) authorization is arranged individually on provisioning. ## Operational notes - **Everything runs through Telegram.** Onboarding, credentials, token rotation, refunds: [@supanode_tgs](https://telegram.me/supanode_tgs). - **One token per subscription.** Quota is counted against the token, so several machines sharing one token share one budget - see [gRPC limits](https://supanode.xyz/docs/solana/grpc/limits). ## See also First request in 5 minutes. How quota is counted against your token. All Bundle plans and add-ons. --- ## RPC Source: https://supanode.xyz/docs/solana/rpc/overview > Standard Solana JSON-RPC interface for on-demand queries: balances, transaction history, account state, sending transactions. Standard Solana JSON-RPC interface for on-demand queries against the blockchain. **Token auth.** Send your token as `x-token` or `Authorization: Bearer` on every request - see [Authentication](https://supanode.xyz/docs/solana/authentication). A request without a valid token is rejected with `401`. ## What it's for Wallets reading balances, explorers showing transaction history, dashboards rendering account state, batch indexers pulling historical data, sending signed transactions. Anything that asks the chain a question and gets an answer. For a continuous stream of events instead of one-off queries, see [gRPC](https://supanode.xyz/docs/solana/grpc/overview) or [WebSocket](https://supanode.xyz/docs/solana/websocket/overview). ## When should I use JSON-RPC? | You need... | Use this | |---|---| | Look up a balance, account, transaction | **RPC** (this product) | | Continuous stream of on-chain events | [gRPC](https://supanode.xyz/docs/solana/grpc/overview) | | Lightweight subscriptions for browser apps | [WebSocket](https://supanode.xyz/docs/solana/websocket/overview) | | Send a signed transaction | **RPC** (`sendTransaction`) | ## Endpoint ``` https://fra.sol.supanode.xyz:8899 ``` Frankfurt region. Standard Solana JSON-RPC over HTTP, all commitment levels (`processed`, `confirmed`, `finalized`). ## What's included - All standard Solana JSON-RPC methods that aren't on the [Restrictions](https://supanode.xyz/docs/solana/rpc/restrictions) list. - All commitment levels. - Token authentication - `x-token` or `Authorization: Bearer` on every request. For the supported method reference and weights, see [What's available](https://supanode.xyz/docs/solana/rpc/whats-available). ## Pricing RPC is included in **every Bundle plan**: | Plan | Price (30 days) | |---|---| | STARTER | \$40 | | FOCUS | \$99 | | BUILD | \$159 | | GROW | \$259 | | PROFESSIONAL | \$459 | **No credits, no compute units.** Unlimited usage within your RPS limit. Some methods cost more than 1 RPS unit per call - see [Limits](https://supanode.xyz/docs/solana/rpc/limits) for the weights table. ## Free trial **24 hours, no card.** Contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). For details, see [Free Trials](https://supanode.xyz/docs/solana/pricing/free-trials). ## External references - [Solana RPC HTTP methods](https://solana.com/docs/rpc/http) - [Commitment levels explained](https://solana.com/docs/rpc#configuring-state-commitment) ## Next steps Methods you can call, plus weights. Rate limits and per-method costs. Edge cases and the method-weight budget. Working code in 4 languages. --- ## What's available Source: https://supanode.xyz/docs/solana/rpc/whats-available > Solana JSON-RPC methods supported on Supanode, with method weights for the RPS budget. Supanode implements the standard Solana JSON-RPC specification and supports every method that isn't on the [Restrictions](https://supanode.xyz/docs/solana/rpc/restrictions) list. For the full method reference with parameters and response shapes, see the [official Solana RPC docs](https://solana.com/docs/rpc/http). ## Method categories | Category | Sample methods | Notes | |---|---|---| | **Account state** | `getAccountInfo`, `getMultipleAccounts`, `getBalance`, `getProgramAccounts` | `getProgramAccounts` is heavy - see [weights](#method-weights) | | **Transactions (read)** | `getTransaction`, `getSignaturesForAddress`, `getSignatureStatuses` | Historical lookups | | **Transactions (send)** | `sendTransaction`, `simulateTransaction` | Counted as TPS, not RPS | | **Slots and blocks** | `getSlot`, `getBlock`, `getBlocks`, `getBlockHeight`, `getLatestBlockhash` | | | **Tokens** | `getTokenAccountsByOwner`, `getTokenAccountBalance`, `getTokenSupply`, `getTokenLargestAccounts` | | | **Network info** | `getEpochInfo`, `getEpochSchedule`, `getInflationRate`, `getInflationGovernor`, `getVersion` | | | **Validators** | `getVoteAccounts`, `getLeaderSchedule` | | ## Method weights Some methods cost more than 1 RPS unit per call. The weight table is the same on every plan - only your RPS budget changes. | Method | Cost (RPS units) | |---|---| | `getProgramAccounts` | 30 | | `getTransaction` | 10 | | `getTokenAccountsByOwner` | 10 | | `getTokenAccountsByDelegate` | 10 | | `getTokenLargestAccounts` | 10 | | `getMultipleAccounts` | 5 RPS units per 100 accounts (high-throughput batched) or 2 RPS units per account (standard) | | `getAccountInfo` | 2 | | `getTokenAccountBalance` | 2 | | All others | 1 | For detailed RPS limits per plan, see [Limits](https://supanode.xyz/docs/solana/rpc/limits). ## Commitment levels All methods support three commitment levels via the `commitment` parameter: - **`processed`** - fastest, can revert. - **`confirmed`** - practical default. - **`finalized`** - adds ~13 seconds of latency, no revert risk. If you don't pass `commitment`, the default is `finalized`. ## External references - [Solana RPC API methods](https://solana.com/docs/rpc/http) - [Commitment levels explained](https://solana.com/docs/rpc#configuring-state-commitment) ## Next steps RPS budget and method weights. Edge cases and the method-weight budget. Code in 4 languages. --- ## Limits Source: https://supanode.xyz/docs/solana/rpc/limits > Rate limits and per-method weights for RPC across plans. All RPC limits by plan, in one place. ## What are the RPC rate limits per plan? | Limit | STARTER | FOCUS | BUILD | GROW | PROFESSIONAL | Dedicated | |---|---|---|---|---|---|---| | Price | \$40/mo | \$99/mo | \$159/mo | \$259/mo | \$459/mo | custom | | RPS (shared with gRPC) | 15 | 25 | 200 | 300 | 500 | unlimited | | TPS | 5 | 10 | 30 | 50 | 100 | unlimited | RPS is shared between RPC HTTP calls and gRPC `SubscribeRequest` updates (where applicable). WebSocket subscribe / unsubscribe also counts toward RPS. ## Aggregation window RPS is calculated over a **10-second sliding window**. This makes the limit burst-friendly - a brief spike that averages within your plan won't be rate-limited. ## Which RPC methods cost more than one request unit? Some methods cost more than 1 RPS unit per call: | Method | Cost (RPS units) | |---|---| | `getProgramAccounts` | 30 | | `getTransaction` | 10 | | `getTokenAccountsByOwner` | 10 | | `getTokenAccountsByDelegate` | 10 | | `getTokenLargestAccounts` | 10 | | `getMultipleAccounts` | 5 RPS units per 100 accounts (high-throughput pattern) or 2 RPS units per account (standard) | | `getAccountInfo` | 2 | | `getTokenAccountBalance` | 2 | | All others | 1 | Weights are the same on every plan - only your RPS limit changes. ## What happens when I hit a rate limit? - **RPS exceeded** - standard `429 Too Many Requests`. Back off and retry. - **TPS exceeded** - `sendTransaction` rejected with `429`. Back off, then retry the transaction. ## External references - [Solana RPC HTTP methods](https://solana.com/docs/rpc/http) ## See also - [What's available](https://supanode.xyz/docs/solana/rpc/whats-available) - [Restrictions](https://supanode.xyz/docs/solana/rpc/restrictions) - [All limits at a glance](https://supanode.xyz/docs/solana/pricing/limits) - [Plans](https://supanode.xyz/docs/solana/pricing/plans) --- ## RPC restrictions Source: https://supanode.xyz/docs/solana/rpc/restrictions > No RPC methods are blocked on Supanode. Heavy methods like getProgramAccounts cost more RPS units; archival mode and multi-region are not available in v1. RPC restrictions are validated by Supanode engineering for v1, pending final sign-off before public launch. What you should know about edge cases on Supanode RPC. ## No methods are explicitly disabled Supanode supports every method in the [official Solana RPC spec](https://solana.com/docs/rpc/http). RPC traffic is governed by the method weight system rather than a blocklist, so heavy calls stay available but cost more. (For comparison, [gRPC](https://supanode.xyz/docs/solana/grpc/restrictions) and [WebSocket](https://supanode.xyz/docs/solana/websocket/restrictions) do block specific high-traffic subscriptions.) Methods that touch many accounts or scan large indexes cost more RPS units per call: - `getProgramAccounts` costs 30 RPS units per call. - `getTransaction` costs 10. - See [Limits](https://supanode.xyz/docs/solana/rpc/limits#which-rpc-methods-cost-more-than-one-request-unit) for the full table. This means a 100 RPS plan handles ~100 simple `getAccountInfo` calls per second, but only ~3 `getProgramAccounts` calls per second. The plan's price reflects this implicit budget. ## Known constraints - **No archival mode toggle.** All Supanode nodes are configured the same way. There's no separate "archival" tier - history depth is what the network provides. - **Single region in v1.** All nodes serve from Frankfurt. Multi-region is on the roadmap. ## What you can do instead - **For heavy-program scans** - use [gRPC](https://supanode.xyz/docs/solana/grpc/overview) `accounts` subscription with filters instead of polling `getProgramAccounts`. - **For historical replay** - `getSignaturesForAddress` plus per-signature `getTransaction` works for historical transaction lookups. - **For TLS-encrypted gRPC streams** - [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node). ## See also - [Limits](https://supanode.xyz/docs/solana/rpc/limits) - method weights and RPS budget. - [What's not allowed](https://supanode.xyz/docs/solana/pricing/restrictions) - global restrictions across all products. --- ## RPC examples Source: https://supanode.xyz/docs/solana/rpc/examples > Copy-paste Solana JSON-RPC examples for getBalance, getAccountInfo, and getTransaction in TypeScript, Rust, Python, and curl. Copy-paste working examples for the four most common languages. ## Prerequisites - An active Supanode Bundle subscription or free trial. Don't have one? Contact [@supanode_tgs](https://telegram.me/supanode_tgs) on Telegram. - Your access token, issued on provisioning - see [Authentication](https://supanode.xyz/docs/solana/authentication). - The RPC endpoint URL (default: `https://fra.sol.supanode.xyz:8899`). The token goes in the `x-token` header. `Authorization: Bearer`, `x-api-key`, and the `api-key` / `api_key` query parameters are accepted too - useful for clients that cannot set headers. Prefer a header: a query string ends up in logs. ## Test connection Before writing code, verify your token and endpoint: ```bash curl https://fra.sol.supanode.xyz:8899 \ -H "Content-Type: application/json" \ -H "x-token: sk_your_token_here" \ -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}' ``` A JSON response with a `result` field containing a slot number means the connection works. `401` means the token is missing or wrong. ## Get account info Fetches account balance and owner for a given address. ```typescript import { Connection, PublicKey } from "@solana/web3.js"; const connection = new Connection("https://fra.sol.supanode.xyz:8899", { commitment: "confirmed", httpHeaders: { "x-token": process.env.SUPANODE_TOKEN! }, }); const accountAddress = new PublicKey("YOUR_ACCOUNT_PUBKEY"); const accountInfo = await connection.getAccountInfo(accountAddress); console.log("Balance (lamports):", accountInfo?.lamports); console.log("Owner:", accountInfo?.owner.toBase58()); ``` ```rust use solana_client::rpc_client::RpcClient; use solana_sdk::pubkey::Pubkey; use std::str::FromStr; fn main() { // RpcClient cannot set custom headers, so pass the token in the query string. let token = std::env::var("SUPANODE_TOKEN").unwrap(); let client = RpcClient::new( format!("https://fra.sol.supanode.xyz:8899?api-key={token}") ); let account_pubkey = Pubkey::from_str("YOUR_ACCOUNT_PUBKEY").unwrap(); let account = client.get_account(&account_pubkey).unwrap(); println!("Balance (lamports): {}", account.lamports); println!("Owner: {}", account.owner); } ``` ```python from solana.rpc.api import Client from solders.pubkey import Pubkey import os client = Client( "https://fra.sol.supanode.xyz:8899", extra_headers={"x-token": os.environ["SUPANODE_TOKEN"]}, ) account_pubkey = Pubkey.from_string("YOUR_ACCOUNT_PUBKEY") response = client.get_account_info(account_pubkey) print("Balance (lamports):", response.value.lamports) print("Owner:", response.value.owner) ``` ```bash curl https://fra.sol.supanode.xyz:8899 \ -H "Content-Type: application/json" \ -H "x-token: sk_your_token_here" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "getAccountInfo", "params": ["YOUR_ACCOUNT_PUBKEY", {"encoding": "base64"}] }' ``` ## Get recent transactions for an address ```bash curl https://fra.sol.supanode.xyz:8899 \ -H "Content-Type: application/json" \ -H "x-token: sk_your_token_here" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "getSignaturesForAddress", "params": ["YOUR_ACCOUNT_PUBKEY", {"limit": 10}] }' ``` `getSignaturesForAddress` returns up to 1,000 signatures per call. Follow up with individual `getTransaction` calls for each signature you want details on. ## Production tips 1. **Reuse connections.** HTTP keep-alive is on by default in most clients. Don't create a new client per request. 2. **Keep the token out of your repository.** Read it from an environment variable or a secrets manager. Anyone holding it spends your plan's quota - see [Authentication](https://supanode.xyz/docs/solana/authentication). 3. **Backoff on `429`.** Rate-limit responses include a `Retry-After` header where possible. Implement exponential backoff starting at 1 second. 4. **Choose commitment carefully.** `confirmed` is the safe default. `finalized` adds ~13 seconds of latency. 5. **Batch when you can.** `getMultipleAccounts` (up to 100 accounts per call) is much cheaper than 100 individual `getAccountInfo` calls. 6. **Don't poll for live data.** If you find yourself running a tight `getAccountInfo` loop, switch to [WebSocket](https://supanode.xyz/docs/solana/websocket/overview) `accountSubscribe` or [gRPC](https://supanode.xyz/docs/solana/grpc/overview) `accounts` stream. ## Where to go next RPS budget and method weights. Edge cases. 24-hour RPC trial. gRPC for real-time. --- ## gRPC Source: https://supanode.xyz/docs/solana/grpc/overview > Real-time Yellowstone gRPC streaming with rich filters. The recommended interface for trading bots, indexers, and any high-throughput workload. Real-time streaming of Solana blockchain data via the standard Yellowstone gRPC interface. **Region:** gRPC is served from **Frankfurt (FRA) only** - the gRPC endpoint has no other region. **Running an automated trading strategy?** gRPC is almost certainly what you need - higher throughput, more granular filtering, and lower per-event latency than WebSocket. ## What it's for Trading bots, market makers, indexers, and analytics systems use gRPC to react to on-chain events with minimal latency. ## When should I use gRPC instead of WebSocket? | You need... | Use this | |---|---| | Real-time streams of on-chain events | **gRPC** (this product) | | On-demand queries (balances, transaction history) | [RPC](https://supanode.xyz/docs/solana/rpc/overview) | | Lightweight subscriptions for browser apps | [WebSocket](https://supanode.xyz/docs/solana/websocket/overview) | | Entire blocks streamed (HFT, MEV) | [gRPC + unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming) | ## Endpoints | Type | URL | |---|---| | gRPC | `fra.sol.supanode.xyz:10010` | Frankfurt region. Authenticate with your token in the `x-token` header (or `Authorization: Bearer`) - see [Authentication](https://supanode.xyz/docs/solana/authentication). ## What's included - **Standard interface:** [Yellowstone gRPC](https://github.com/rpcpool/yellowstone-grpc) - the open-source streaming standard maintained by Triton One. - **Subscription types:** accounts, transactions, slots, blocks, blocks_meta, entries. - **Commitment levels:** processed, confirmed, finalized. - **Token auth** - the same token as RPC and WebSocket, sent as `x-token` on the connection. - **Unlimited, unmetered throughput** - no per-MB or per-credit billing on the data your streams deliver, on every gRPC tier. **Throughput is unlimited and unmetered.** Supanode bills by plan tier, so stream data carries no per-MB or per-GB charge. What scales by plan is your **concurrent subscription count** and the **total addresses** you can watch - see [Limits](https://supanode.xyz/docs/solana/grpc/limits). For the full list of streams and parameters, see [What's available](https://supanode.xyz/docs/solana/grpc/whats-available). ## Pricing gRPC is included in 4 of the 5 Bundle plans. What scales by tier is how many subscriptions you can hold at once and how many addresses you can watch in total. Separately, the node caps every filter at 2 000 addresses and every subscription at 10 filters, so a large address budget has to be spread across several filters and subscriptions - [Limits](https://supanode.xyz/docs/solana/grpc/limits) shows the layout for each plan. | Plan | Concurrent subscriptions | Max accounts watched | |---|---|---| | STARTER | not included | — | | FOCUS | 1 | up to 100 | | BUILD | 10 | up to 5,000 | | GROW | 20 | up to 24,000 | | PROFESSIONAL | 50 | up to 100,000 | **STARTER (\$40/mo) is WebSocket-first** - no gRPC. For gRPC start at FOCUS (\$99/mo). Throughput on every gRPC tier is **unlimited and unmetered**. For full per-stream caps see [Limits](https://supanode.xyz/docs/solana/grpc/limits); for the full plan comparison see [Plans](https://supanode.xyz/docs/solana/pricing/plans). ## Free trial **24 hours, no card.** Contact [@supanode_tgs](https://telegram.me/supanode_tgs) on Telegram - tell us you'd like to try gRPC and we'll set up your trial within hours. ## External references - [geyser.proto (SubscribeRequest definition)](https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto) ## Next steps Streams you can subscribe to. Rate limits and connection caps. What's not supported and why. Copy-paste code in 4 languages. Empty-filter mode for HFT and indexers. --- ## What's available Source: https://supanode.xyz/docs/solana/grpc/whats-available > Supported gRPC streams, filter parameters, and common subscription patterns. Supanode gRPC follows the standard Yellowstone gRPC specification. For the full protocol specification, see the [official Yellowstone documentation](https://github.com/rpcpool/yellowstone-grpc). ## Supported streams | Stream | What it does | Notes | |---|---|---| | `accounts` | Streams updates to specified accounts | Filterable by owner, account list, data slice | | `transactions` | Streams transactions matching filters | See [Restrictions](https://supanode.xyz/docs/solana/grpc/restrictions) for excluded programs | | `transactions_status` | Lighter version of `transactions` - status only, no full payload | Useful when you only need landing notifications | | `slots` | Streams new slot updates | All commitment levels | | `blocks` | Full block streams | High bandwidth - see [Limits](https://supanode.xyz/docs/solana/grpc/limits) | | `blocks_meta` | Block metadata only (no transactions) | Lightweight alternative to `blocks` | | `entry` | Entry-level updates | Standard Yellowstone behavior | ## Commitment levels All streams support three commitment levels: - **`processed`** - fastest, can revert. - **`confirmed`** - practical default for trading. - **`finalized`** - adds ~13 seconds of latency, no risk of revert. ## Filters Yellowstone gRPC filters compose like this: - **Different categories** in one `SubscribeRequest` (e.g. `accounts` plus `transactions`) - **logical AND**. The stream emits messages only when filters across categories all match. - **Multiple named filters within the same category** (e.g. two named entries inside `transactions:`) - **logical OR**. Each named filter is an independent subscription; a transaction matches if any named filter accepts it. - **Multiple values within a single field's array** (e.g. several pubkeys in `accountInclude`) - **logical OR**. For complete filter options, see [Yellowstone subscription specification](https://github.com/rpcpool/yellowstone-grpc?tab=readme-ov-file#filters-for-streamed-data). ## Common patterns ### Subscribe to a specific program's transactions ```typescript transactions: { myFilter: { vote: false, failed: false, accountInclude: ["YOUR_PROGRAM_ID"], } } ``` ### Subscribe to account changes with data slicing ```typescript accounts: { myAccounts: { account: ["YOUR_ACCOUNT_PUBKEY"], owner: [], filters: [] } }, accountsDataSlice: [{ offset: 0, length: 40 }] ``` ### Subscribe to slot updates only ```typescript slots: { mySlots: { filterByCommitment: false } } ``` ## Filter limits Filter complexity caps depend on your plan. See [Limits](https://supanode.xyz/docs/solana/grpc/limits) for the full breakdown. ## External references - [Yellowstone gRPC GitHub](https://github.com/rpcpool/yellowstone-grpc) - [geyser.proto (SubscribeRequest definition)](https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto) - [Triton One Dragon's Mouth docs](https://docs.triton.one/project-yellowstone/dragons-mouth-grpc-subscriptions) - [Solana Geyser plugin documentation](https://solana.com/docs) ## Next steps Filter caps and connection limits. Programs blocked on shared plans. Working code in 4 languages. --- ## gRPC limits Source: https://supanode.xyz/docs/solana/grpc/limits > How Supanode gRPC limits work: plan quotas for simultaneous subscriptions, addresses and owner programs, the node's fixed caps of 2000 addresses per filter and 10 filters per subscription, and how to lay your address budget out across them. Two different things limit a gRPC stream, and they fail in different ways. Knowing which one you hit tells you whether to reshape your request or buy a bigger plan. | | Set by | Changes with your plan? | Error code | |---|---|---|---| | **Plan quotas** | your subscription | yes | `ResourceExhausted` | | **Node caps** | Yellowstone itself | no, identical on every plan | `InvalidArgument` | **The short version.** One filter holds at most **2 000 addresses**. One subscription holds at most **10 filters**, so at most **20 000 addresses**. Your plan then caps how many subscriptions you can hold at once and how many addresses you can watch in total. Spread your addresses accordingly. ## How a stream is structured ``` TCP connection └─ subscription (one Subscribe call) ← your plan caps how many └─ filter (a named rule) ← max 10 per subscription └─ addresses / owners ← max 2 000 per filter ``` One TCP connection can carry as many subscriptions as your plan allows - there is no separate limit on connections, and no benefit to opening several. What is counted is **subscriptions**. ## Node caps: the same on every plan These come from Yellowstone and do not change with your tier. | Cap | Value | Error you get | |---|---|---| | Addresses in one filter | **2 000** | `failed to create filter: Max amount of Pubkeys reached, only 2000 allowed` | | Filters in one subscription | **10** | `failed to create filter: Max amount of filters/data_slices reached, only 10 allowed` | | **Addresses in one subscription** | **20 000** | (10 filters × 2 000) | **This is the trap.** If your plan includes 24 000 addresses and you send all 24 000 in a single filter, you get `only 2000 allowed` - a message that says nothing about splitting them up. Nothing is wrong with your plan: you just have to lay the addresses out across filters and subscriptions. ## Plan quotas | Plan | Concurrent subscriptions | Addresses watched, total | Owner programs, total | |---|---|---|---| | STARTER | not included | — | — | | FOCUS | 1 | 100 | — | | BUILD | 10 | 5 000 | 5 | | GROW | 20 | 24 000 | 20 | | PROFESSIONAL | 50 | 100 000 | 50 | | Dedicated | unlimited | unlimited | unlimited | **Addresses and owner programs are counted across everything you have open at once** - every filter, in every subscription, in every connection. Opening a second connection does not give you a second budget. Going over returns, for example: ``` accounts.account: too many values across filters and active streams (26000 > 24000) accounts.owner: too many values across filters and active streams (21 > 20) ``` **The budget is "at once", not "per month".** Close a subscription and its addresses are immediately free again. You can rotate through far more addresses over a day than your plan number - you just cannot watch more than that number simultaneously. ## How to lay out your address budget Fill filters to 2 000, pack 10 filters per subscription, then open as many subscriptions as you need. | Plan | Addresses | Minimum layout | Subscriptions used, of your quota | |---|---|---|---| | FOCUS | 100 | 1 filter × 100 | 1 of 1 | | BUILD | 5 000 | 3 filters (2 000 + 2 000 + 1 000) | 1 of 10 | | GROW | 24 000 | 12 filters: one subscription of 10, one of 2 | 2 of 20 | | PROFESSIONAL | 100 000 | 50 filters, 10 per subscription | 5 of 50 | On every plan the layout leaves most of your subscription quota free for other streams - transactions, slots, block metadata. **Filter names are yours.** Each filter is a named rule inside the request, and the name comes back on every update so you know which rule matched. Split by whatever grouping is useful to you - by market, by strategy, by customer - the limit only cares about the counts. ## Reading the error you get | Error | Source | What to do | |---|---|---| | `InvalidArgument` · `failed to create filter: ...` | the node | reshape the request - fewer addresses per filter, fewer filters per subscription | | `ResourceExhausted` · `too many values across filters and active streams` | your plan | close a stream you no longer need, or move up a tier | | `ResourceExhausted` · `too many simultaneous connections (limit: N)` | your plan | you are at your subscription count - close one first | **The subscription-count error says "connections", but it counts subscriptions.** You will see `too many simultaneous connections (limit: 20)` even when every one of those subscriptions is inside a single TCP connection. ## Request size A `SubscribeRequest` must stay under **4 MiB** (4 194 304 bytes) - the standard gRPC message limit. Above it the request is dropped before it reaches the node, and you get no error at all: the stream opens, sends you a `ping`, and then stays silent forever. An address costs about 46 bytes on the wire, so the ceiling is roughly 91 000 addresses in one request. You cannot reach it while respecting the node caps - 10 filters × 2 000 addresses is about 0.9 MB - so this only bites if you try to send a whole plan's worth of addresses in one filter. **Do not treat silence as success, and do not treat a slow answer as failure.** A rejection arrives *after* the first `ping`, and a multi-megabyte request spends most of its time uploading - on a slow uplink that is seconds. Wait for an actual error or an actual data message before deciding your subscription is live. ## Filter update rate You can re-send a `SubscribeRequest` to swap filters up to **30 times per minute**, the same on every tier. A new request fully replaces the old one on that subscription. | Plan | Filter updates | |---|---| | FOCUS | 30 / min | | BUILD | 30 / min | | GROW | 30 / min | | PROFESSIONAL | 30 / min | | Dedicated | unlimited | ## Streams without addresses `slots`, `blocks_meta` and `entry` carry no addresses, so they draw on nothing but your subscription count. They are also not deduplicated: open the same `slots` subscription four times and you receive the same stream four times over. Measured on a live plan, one `slots` subscription delivered 38 messages in five seconds and four identical subscriptions delivered 144. Subscribe once and fan the data out inside your own application. ## Throughput **Throughput is unlimited and unmetered on every gRPC tier.** Supanode bills by plan tier, so the data your streams deliver carries no per-MB, per-GB, or per-credit charge. The only volume gate is [unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming), which is included in the PROFESSIONAL tier. ## Per-tier reference ```json { "concurrent_subscriptions": 1, "addresses_total": 100, "owner_programs_total": null, "filter_updates_per_min": 30, "node_caps": { "addresses_per_filter": 2000, "filters_per_subscription": 10 }, "throughput": "unlimited" } ``` ```json { "concurrent_subscriptions": 10, "addresses_total": 5000, "owner_programs_total": 5, "filter_updates_per_min": 30, "node_caps": { "addresses_per_filter": 2000, "filters_per_subscription": 10 }, "throughput": "unlimited" } ``` ```json { "concurrent_subscriptions": 20, "addresses_total": 24000, "owner_programs_total": 20, "filter_updates_per_min": 30, "node_caps": { "addresses_per_filter": 2000, "filters_per_subscription": 10 }, "throughput": "unlimited" } ``` ```json { "concurrent_subscriptions": 50, "addresses_total": 100000, "owner_programs_total": 50, "filter_updates_per_min": 30, "node_caps": { "addresses_per_filter": 2000, "filters_per_subscription": 10 }, "throughput": "unlimited" } ``` ## Other per-stream caps | Field | FOCUS | BUILD | GROW | PROFESSIONAL | Dedicated | |---|---|---|---|---|---| | `accounts.data_slice_max` | 10 | 10 | 10 | 10 | unlimited | | `slots.max` | 10 | 25 | 50 | 100 | unlimited | | `blocks_meta.max` | 10 | 10 | 10 | 10 | unlimited | | `entry.max` | 10 | 10 | 10 | 10 | unlimited | ## External references - [Yellowstone gRPC GitHub](https://github.com/rpcpool/yellowstone-grpc) - [geyser.proto (SubscribeRequest definition)](https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto) ## See also - [Restrictions](https://supanode.xyz/docs/solana/grpc/restrictions) - programs you cannot put in a filter, and how to get one unblocked - [What's available](https://supanode.xyz/docs/solana/grpc/whats-available) - [All limits at a glance](https://supanode.xyz/docs/solana/pricing/limits) - [Plans](https://supanode.xyz/docs/solana/pricing/plans) --- ## gRPC restrictions Source: https://supanode.xyz/docs/solana/grpc/restrictions > Which programs are blocked in accounts.owner and transactions.account_include on shared gRPC plans, what is still allowed, and how to have a specific program unblocked for your account. What is not available on shared gRPC plans (FOCUS, BUILD, GROW, PROFESSIONAL), why, and what to do instead. ## Blocked programs A handful of programs touch such a large share of Solana traffic that subscribing to them on shared infrastructure would drown out other tenants. They are rejected by the node, per field. | Program | Address | In `accounts.owner` | In `transactions.account_include` | |---|---|---|---| | System Program | `11111111111111111111111111111111` | blocked | blocked | | Compute Budget | `ComputeBudget111111111111111111111111111111` | blocked | blocked | | Associated Token Account | `ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL` | blocked | blocked | | Token Program | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | blocked | **allowed** | | Token-2022 | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | **allowed** | **allowed** | Everything not in this table is allowed. The rejection looks like this, with code `InvalidArgument`: ``` accounts filter: owner 11111111111111111111111111111111 is not allowed ``` **The Token Program is only blocked as an owner.** `accounts.owner` on the Token Program fans out to every token account on Solana, which is why it is closed. Naming the same program in `transactions.account_include` matches a bounded set of transactions and works normally. **Need one of these? Ask us and we will open it.** The list is a default, not a policy - if a blocked program is central to what you are building, message [@supanode_tgs](https://telegram.me/supanode_tgs) and tell us which program and roughly what volume you expect. We lift it for your account, or move you to a [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) if the volume warrants it. ## Working around a blocked program - **Filter by account instead of by owner.** If you know which accounts you care about, list them in `accounts.account` - there is no restriction on which accounts you name, only on the total count your plan allows. - **Use the transaction filter.** For the Token Program, `transactions.account_include` is open and usually closer to what you actually want. - **Ask for it to be unblocked**, as above. - **Move to a Dedicated Node** if you genuinely need a firehose-scale owner subscription. ## Subscription types not supported on shared plans - **Unfiltered block streaming** - `blocks` with an empty `account_include` is rejected on shared plans below PROFESSIONAL: `blocks filter: subscription with empty account_include is not allowed`. Included in the PROFESSIONAL tier; see [Unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming). - **Replay (`from_slot`)** - historical replay is not available on shared plans. [Dedicated Nodes](https://supanode.xyz/docs/solana/dedicated/node) only. - **Custom filter extensions** - only standard Yellowstone filters are supported. ## Other constraints - **Block reconstruction** - the `entries` count in blocks is always 0. This is a Yellowstone-wide limitation, not specific to Supanode. ## What you can do instead - **For replay needs** - use [RPC](https://supanode.xyz/docs/solana/rpc/overview) `getSignaturesForAddress` for historical lookups, or the [Indexer](https://supanode.xyz/docs/solana/indexer/overview) for decoded history in SQL. - **For full blocks** - [Unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming) on PROFESSIONAL. ## See also - [Limits](https://supanode.xyz/docs/solana/grpc/limits) - what is allowed but capped, and how to lay addresses out - [What's not allowed](https://supanode.xyz/docs/solana/pricing/restrictions) - global restrictions across all products --- ## gRPC examples Source: https://supanode.xyz/docs/solana/grpc/examples > Copy-paste Yellowstone gRPC subscription code with token auth for accounts, transactions, and slots in TypeScript, Rust, Python, and grpcurl. Working code to connect to Supanode gRPC and subscribe to streams. ## Prerequisites - A Supanode account on a plan with gRPC (FOCUS, BUILD, GROW, or PROFESSIONAL). - Your **token**, issued on provisioning. Send it as `x-token` (or `Authorization: Bearer`) on every connection - see [Authentication](https://supanode.xyz/docs/solana/authentication). - Your gRPC endpoint - default Frankfurt: `fra.sol.supanode.xyz:10010`. - Yellowstone gRPC client library for your language, plus `geyser.proto` and `solana-storage.proto` from the [Yellowstone repo](https://github.com/rpcpool/yellowstone-grpc/tree/master/yellowstone-grpc-proto/proto). Server reflection is disabled, so the proto files are required. **Before you write filters, read [Limits](https://supanode.xyz/docs/solana/grpc/limits).** One filter holds at most 2 000 addresses and one subscription at most 10 filters. Sending your whole address budget in a single filter is the most common first mistake. **Don't have an account yet?** Get a 24-hour free trial - contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). ## Test connection Before writing code, verify your endpoint is reachable using `grpcurl`: ```bash grpcurl -plaintext -import-path ./proto -proto geyser.proto \ -H 'x-token: sk_your_token_here' \ -d '{}' \ fra.sol.supanode.xyz:10010 geyser.Geyser/GetVersion ``` If you see a version number in the response, your token and connection both work. A missing or wrong token returns `PermissionDenied`. ## Basic subscribe example Subscribes to all successful transactions involving a specific program. The Python example generates its stubs from the Yellowstone gRPC [geyser.proto](https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto). ```typescript import Client, { CommitmentLevel, SubscribeRequest } from "@triton-one/yellowstone-grpc"; // Second argument is your token — the client sends it as x-token. const client = new Client( "http://fra.sol.supanode.xyz:10010", process.env.SUPANODE_TOKEN, { "grpc.max_receive_message_length": 64 * 1024 * 1024 } ); const stream = await client.subscribe(); const request: SubscribeRequest = { commitment: CommitmentLevel.CONFIRMED, accounts: {}, slots: {}, transactions: { myFilter: { vote: false, failed: false, accountInclude: ["YOUR_PROGRAM_ID"], accountExclude: [], accountRequired: [], }, }, transactionsStatus: {}, blocks: {}, blocksMeta: {}, entry: {}, accountsDataSlice: [], }; stream.write(request); stream.on("data", (data) => { if (data.transaction) { console.log(`Transaction: ${data.transaction.signature}`); } }); ``` ```rust use yellowstone_grpc_client::GeyserGrpcClient; use yellowstone_grpc_proto::geyser::{ SubscribeRequest, SubscribeRequestFilterTransactions, CommitmentLevel, }; use std::collections::HashMap; #[tokio::main] async fn main() -> anyhow::Result<()> { let token = std::env::var("SUPANODE_TOKEN")?; let mut client = GeyserGrpcClient::build_from_shared("http://fra.sol.supanode.xyz:10010")? .x_token(Some(token))? .connect() .await?; let mut transactions = HashMap::new(); transactions.insert( "my_filter".to_string(), SubscribeRequestFilterTransactions { vote: Some(false), failed: Some(false), account_include: vec!["YOUR_PROGRAM_ID".to_string()], account_exclude: vec![], account_required: vec![], signature: None, }, ); let request = SubscribeRequest { commitment: Some(CommitmentLevel::Confirmed as i32), transactions, ..Default::default() }; let (mut subscribe_tx, mut stream) = client.subscribe().await?; subscribe_tx.send(request).await?; while let Some(message) = stream.message().await? { println!("Received: {:?}", message); } Ok(()) } ``` ```python import grpc # Generate the stubs from the Yellowstone geyser.proto first, e.g.: # python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. geyser.proto from geyser_pb2 import ( SubscribeRequest, SubscribeRequestFilterTransactions, CommitmentLevel ) from geyser_pb2_grpc import GeyserStub import os TOKEN = os.environ["SUPANODE_TOKEN"] channel = grpc.insecure_channel("fra.sol.supanode.xyz:10010") stub = GeyserStub(channel) request = SubscribeRequest( commitment=CommitmentLevel.CONFIRMED, transactions={ "my_filter": SubscribeRequestFilterTransactions( vote=False, failed=False, account_include=["YOUR_PROGRAM_ID"], ) } ) # The token travels as gRPC metadata on the call. metadata = (("x-token", TOKEN),) for response in stub.Subscribe(iter([request]), metadata=metadata): if response.HasField("transaction"): print("Transaction received") ``` ```bash grpcurl -plaintext -import-path ./proto -proto geyser.proto \ -H 'x-token: sk_your_token_here' \ -d '{ "commitment": "CONFIRMED", "transactions": { "my_filter": { "vote": false, "failed": false, "account_include": ["YOUR_PROGRAM_ID"] } } }' \ fra.sol.supanode.xyz:10010 \ geyser.Geyser/Subscribe ``` ## Production tips 1. **Reconnection with exponential backoff.** Network blips happen. Implement retry logic that starts at 1 second and backs off to 30 seconds. On `429` or `503` errors, always back off before retrying. 2. **Ping/pong for keepalive.** Yellowstone server sends ping every 15 seconds. Most client libraries handle this automatically. 3. **Use `accountsDataSlice` to reduce bandwidth.** If you only need part of an account's data, specify `accountsDataSlice: [{offset: 0, length: 40}]`. 4. **Choose commitment level wisely.** `processed` is fastest but can revert. `confirmed` is the practical default for trading. `finalized` adds ~13 seconds of latency. 5. **Handle stream restart gracefully.** When your stream restarts, you'll miss events during downtime. Design your application to recover from this. 6. **Do not read the first message as an acceptance.** The server sends a `ping` immediately, and a rejection arrives after it. Wait for a real data message or an error before you consider the subscription live - see [Limits](https://supanode.xyz/docs/solana/grpc/limits#request-size). 7. **Close streams you stop using.** Your address budget is counted across everything open at once, and closing a subscription frees it immediately. ## Where to go next Subscription caps and how to lay out addresses. What's not supported on shared. 24-hour gRPC trial. More examples on GitHub. --- ## Unfiltered block streaming Source: https://supanode.xyz/docs/solana/grpc/full-block-streaming > Receive every transaction in every block via gRPC — the full blocks stream with no account filter. Included in the PROFESSIONAL tier. Full Solana blocks over gRPC - every transaction, every block, no filter. Included in the **PROFESSIONAL** Bundle. ## What it is Standard gRPC `blocks` subscriptions require a non-empty `account_include` filter on shared plans. Unfiltered block streaming lifts that requirement: you subscribe to `blocks` with an empty `account_include` and receive every transaction in every block. This is roughly **3,000 transactions per block, every ~400ms**. Bandwidth is high - typically megabytes per block. ## When to use this | Use case | Why unfiltered block streaming | |---|---| | HFT and MEV | You need to see every transaction to find opportunities, not just the ones matching a known filter. | | Full-state indexers | You're rebuilding ledger state and can't predict which programs will be relevant. | | Market-wide analytics | You're computing aggregate metrics across all activity. | If you only need transactions involving a specific program or account, regular [gRPC](https://supanode.xyz/docs/solana/grpc/overview) with filters is cheaper and lighter. ## What's included - Full `blocks` stream with empty `account_include` filter, returning every transaction in every block. - All commitment levels - processed, confirmed, finalized. - Standard Yellowstone gRPC interface, same as the regular gRPC product. - Authentication with the same token as regular gRPC. ## Availability Unfiltered block streaming is included in the **[PROFESSIONAL](https://supanode.xyz/docs/solana/pricing/plans)** Bundle - it is not a paid add-on and not sold separately. Lower tiers use regular filtered gRPC. ## How to get access 1. Subscribe to the PROFESSIONAL Bundle (it includes gRPC). 2. Contact [@supanode_tgs](https://telegram.me/supanode_tgs) on Telegram to activate the endpoint. 3. The empty-`account_include` mode is enabled on your gRPC endpoint. ## See also - [gRPC Overview](https://supanode.xyz/docs/solana/grpc/overview) - [gRPC Limits](https://supanode.xyz/docs/solana/grpc/limits) - [gRPC Restrictions](https://supanode.xyz/docs/solana/grpc/restrictions) --- ## WebSocket Source: https://supanode.xyz/docs/solana/websocket/overview > Standard Solana WebSocket subscriptions for browser apps, dashboards, and lightweight integrations. Included with every plan. Standard Solana WebSocket subscriptions for browser apps, dashboards, and lightweight integrations. **Included with every Bundle plan.** STARTER, FOCUS, BUILD, GROW, PROFESSIONAL - all include WebSocket at no extra cost. ## What is WebSocket good for? WebSocket keeps **one open connection** and the server pushes updates to you as they happen — ideal when you watch a **small number of things** with zero setup overhead. Browser apps, wallets, internal dashboards, hobby projects. It's the lightweight option. The trade-off: if you subscribe to something **busy** — e.g. a `programSubscribe` over an active DEX program — the firehose of notifications can overwhelm a WebSocket. That high-volume, multi-filter case is exactly what [gRPC](https://supanode.xyz/docs/solana/grpc/overview) is built for. **Rule of thumb:** a handful of accounts/signatures → WebSocket; production trading or full-state indexing → gRPC. ## Endpoint ``` wss://fra.sol.supanode.xyz:8900 ``` Frankfurt region. Standard Solana WebSocket protocol. Pass your token as an `x-token` header on the handshake - see [Authentication](https://supanode.xyz/docs/solana/authentication). ## What's included - **Subscription types:** account, signature, slot, root, program (with required filters). - **All commitment levels:** processed, confirmed, finalized. - **Token auth** - the same token as RPC and gRPC, sent as a header on the handshake. ## STARTER: the WebSocket-first plan **STARTER (\$40/mo) gives you 10 concurrent WS connections** at the lowest entry price - no gRPC. Built for WebSocket-heavy workloads. Connection caps scale up on every higher tier. ## Pricing | Plan | WebSocket | |---|---| | STARTER | included (10 connections) | | FOCUS | included (20 connections) | | BUILD | included (30 connections) | | GROW | included (40 connections) | | PROFESSIONAL | included (70 connections) | **No credits, no compute units.** See [Limits](https://supanode.xyz/docs/solana/websocket/limits) for connection caps and subscription totals per plan. ## Free trial WebSocket is part of the **24-hour Bundle free trial**. Contact [@supanode_tgs](https://telegram.me/supanode_tgs) on Telegram. For details, see [Free Trials](https://supanode.xyz/docs/solana/pricing/free-trials). ## External references - [Solana WebSocket API methods](https://solana.com/docs/rpc/websocket) ## Next steps Subscription methods supported. Connections and total subscription caps. Blocked subscriptions. Code in TypeScript, Rust, Python. --- ## What's available Source: https://supanode.xyz/docs/solana/websocket/whats-available > Supported WebSocket subscriptions, authentication, and protocol patterns. Supanode implements the standard Solana WebSocket subscription protocol. For the full reference, see the [official Solana WebSocket docs](https://solana.com/docs/rpc/websocket). ## Supported subscriptions | Subscription | What it streams | Notes | |---|---|---| | `accountSubscribe` | Updates to a specific account | One subscription per account | | `signatureSubscribe` | Notification when a signature commits | One-shot - fires once and unsubscribes | | `slotSubscribe` | Every new slot | Lightweight | | `rootSubscribe` | New roots (finalized slots) | Lightweight | | `programSubscribe` | Account updates owned by a program | **Requires `dataSize` or `memcmp` filter** - see [Restrictions](https://supanode.xyz/docs/solana/websocket/restrictions) | | `logsSubscribe` | Transaction logs matching a filter | Mention-filter only on shared. `logsSubscribe("all")` is blocked - see [Restrictions](https://supanode.xyz/docs/solana/websocket/restrictions) | ## Authentication WebSocket uses the same token as RPC and gRPC - see [Authentication](https://supanode.xyz/docs/solana/authentication). Send it as an `x-token` header on the handshake; a connection without it is refused with `401`. ``` wss://fra.sol.supanode.xyz:8900 ``` ## Subscribe / unsubscribe protocol Subscriptions follow the standard JSON-RPC over WebSocket pattern. **Subscribe:** ```json { "jsonrpc": "2.0", "id": 1, "method": "accountSubscribe", "params": ["YOUR_ACCOUNT_PUBKEY", {"commitment": "confirmed"}] } ``` The server responds with a numeric subscription ID. Updates stream as notifications until you unsubscribe. **Unsubscribe:** ```json { "jsonrpc": "2.0", "id": 2, "method": "accountUnsubscribe", "params": [SUBSCRIPTION_ID] } ``` Both `subscribe` and `unsubscribe` calls count against your RPS budget - this is intentional anti-abuse. The connection itself is admitted by the token; in-flight subscribe/unsubscribe RPCs go through the standard RPS budget. ## Commitment levels Most subscriptions accept a `commitment` parameter (`processed`, `confirmed`, `finalized`). Defaults to `finalized` if omitted. ## External references - [Solana WebSocket API methods](https://solana.com/docs/rpc/websocket) ## Next steps Connection caps and subs. Blocked subscriptions. Working code. --- ## WebSocket limits Source: https://supanode.xyz/docs/solana/websocket/limits > Per-plan WebSocket caps: concurrent connections, subscriptions per connection, and total subscriptions per plan from STARTER to PROFESSIONAL. All WebSocket limits by plan. ## What are the WebSocket connection and subscription limits? | Limit | STARTER | FOCUS | BUILD | GROW | PROFESSIONAL | Dedicated | |---|---|---|---|---|---|---| | Concurrent WS connections | 10 | 20 | 30 | 40 | 70 | unlimited | | Subscriptions per connection | 100 | 100 | 100 | 500 | 1,000 | unlimited | | Total subscriptions per plan | 1,000 | 5,000 | 5,000 | 10,000 | 25,000 | unlimited | | Idle timeout | 10 min | 10 min | 10 min | 10 min | 10 min | 10 min | | Required ping interval | ≤60 sec | ≤60 sec | ≤60 sec | ≤60 sec | ≤60 sec | ≤60 sec | **Total subs is a hard cap, not connections × subs/conn.** See [How pricing works](https://supanode.xyz/docs/solana/pricing/how-it-works#how-total-ws-subs-works). ## STARTER: the WebSocket-first plan STARTER (\$40/mo) is the WebSocket-friendly entry plan - no gRPC, lower RPS - with **10 concurrent WS connections** at the lowest price. STARTER users typically run browser clients or lightweight listeners. WS connection caps then scale up with each tier (FOCUS 20, BUILD 30, GROW 40, PROFESSIONAL 70). ## RPS counts subscribe and unsubscribe Incoming `subscribe` / `unsubscribe` commands count against your RPS limit, the same as RPC requests. This is a deliberate anti-abuse measure. ## What happens when you hit a limit - **Connection limit exceeded** - new connection rejected. - **Subscription limit exceeded** - subscribe call returns an error, existing subscriptions keep working. - **RPS exceeded** - `429`. Calculated over a 10-second sliding window. ## External references - [Solana WebSocket API methods](https://solana.com/docs/rpc/websocket) ## See also - [What's available](https://supanode.xyz/docs/solana/websocket/whats-available) - [Restrictions](https://supanode.xyz/docs/solana/websocket/restrictions) - [All limits at a glance](https://supanode.xyz/docs/solana/pricing/limits) - [Plans](https://supanode.xyz/docs/solana/pricing/plans) --- ## WebSocket restrictions Source: https://supanode.xyz/docs/solana/websocket/restrictions > Subscriptions blocked on shared WebSocket plans: blockSubscribe, voteSubscribe, slotsUpdatesSubscribe, unfiltered programSubscribe and logsSubscribe. Restrictions are validated by Supanode engineering for v1, pending final sign-off before public launch. What's not supported on shared WebSocket plans (STARTER, FOCUS, BUILD, GROW, PROFESSIONAL). Available on Dedicated Node. ## Subscriptions blocked on shared plans | Subscription | Reason | |---|---| | `blockSubscribe` | Full block payloads - too heavy for shared infrastructure | | `voteSubscribe` | Validator vote firehose | | `slotsUpdatesSubscribe` | Sub-step slot updates | | `logsSubscribe("all")` and `logsSubscribe("allWithVotes")` | All logs of all transactions | | `programSubscribe` without `dataSize` or `memcmp` filter | Whole-program subscriptions are blocked unconditionally | ## `programSubscribe` requires a filter To use `programSubscribe`, you must include either a `dataSize` or `memcmp` filter. Unfiltered program subscriptions are blocked. ## What you can do instead - For `blockSubscribe` use cases → [Unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming) on gRPC - For `programSubscribe` without filters → [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) - For other blocked subscriptions → contact us ## See also - [What's not allowed](https://supanode.xyz/docs/solana/pricing/restrictions) - global view across all products --- ## WebSocket examples Source: https://supanode.xyz/docs/solana/websocket/examples > Copy-paste WebSocket subscription examples for slot, account, and program updates in TypeScript, Rust, and Python. Copy-paste working examples for connecting to Supanode WebSocket. ## Prerequisites - An active Supanode Bundle subscription or free trial. Don't have one? Contact [@supanode_tgs](https://telegram.me/supanode_tgs) on Telegram. - Your access token, issued on provisioning - see [Authentication](https://supanode.xyz/docs/solana/authentication). - The WebSocket endpoint URL (default: `wss://fra.sol.supanode.xyz:8900`). The token goes on the handshake, either as an `x-token` header or as an `api-key` query parameter. **Use the query parameter when your client cannot set handshake headers.** `@solana/web3.js` is the common case - its `wsEndpoint` takes a URL and nothing else, so append `?api-key=...` to it. Anything that lets you set headers should send `x-token` instead, since a query string ends up in logs. ## Subscribe to slot updates The lightest possible WebSocket subscription - useful as a smoke test. ```typescript import { Connection } from "@solana/web3.js"; const token = process.env.SUPANODE_TOKEN!; const connection = new Connection("https://fra.sol.supanode.xyz:8899", { httpHeaders: { "x-token": token }, // web3.js cannot set headers on the WS handshake — pass the token in the URL. wsEndpoint: `wss://fra.sol.supanode.xyz:8900/?api-key=${token}`, }); const subscriptionId = connection.onSlotChange((slotInfo) => { console.log("New slot:", slotInfo.slot); }); // To unsubscribe later: // await connection.removeSlotChangeListener(subscriptionId); ``` ```rust use solana_client::nonblocking::pubsub_client::PubsubClient; use futures::StreamExt; #[tokio::main] async fn main() -> anyhow::Result<()> { let token = std::env::var("SUPANODE_TOKEN")?; let url = format!("wss://fra.sol.supanode.xyz:8900/?api-key={token}"); let client = PubsubClient::new(&url).await?; let (mut stream, unsubscribe) = client.slot_subscribe().await?; while let Some(slot_info) = stream.next().await { println!("New slot: {}", slot_info.slot); } unsubscribe().await; Ok(()) } ``` ```python import asyncio import os from solana.rpc.websocket_api import connect async def main(): url = f"wss://fra.sol.supanode.xyz:8900/?api-key={os.environ['SUPANODE_TOKEN']}" async with connect(url) as websocket: await websocket.slot_subscribe() first_resp = await websocket.recv() subscription_id = first_resp[0].result async for msg in websocket: print("New slot:", msg[0].result.slot) asyncio.run(main()) ``` Send the subscribe request as JSON over the WebSocket connection: ```json { "jsonrpc": "2.0", "id": 1, "method": "slotSubscribe", "params": [] } ``` Server responds with a numeric subscription ID, then notifications stream: ```json { "jsonrpc": "2.0", "method": "slotNotification", "params": { "result": { "slot": 282729810, "parent": 282729809, "root": 282729778 }, "subscription": 12345 } } ``` ## Subscribe to an account Stream updates for a single account. ```typescript import { Connection, PublicKey } from "@solana/web3.js"; const token = process.env.SUPANODE_TOKEN!; const connection = new Connection("https://fra.sol.supanode.xyz:8899", { httpHeaders: { "x-token": token }, // web3.js cannot set headers on the WS handshake — pass the token in the URL. wsEndpoint: `wss://fra.sol.supanode.xyz:8900/?api-key=${token}`, }); const accountAddress = new PublicKey("YOUR_ACCOUNT_PUBKEY"); const subscriptionId = connection.onAccountChange( accountAddress, (accountInfo) => { console.log("Balance:", accountInfo.lamports); console.log("Data:", accountInfo.data.toString("base64")); }, "confirmed" ); ``` ```rust use solana_client::{ nonblocking::pubsub_client::PubsubClient, rpc_config::RpcAccountInfoConfig, }; use solana_account_decoder::UiAccountEncoding; use solana_sdk::{commitment_config::CommitmentConfig, pubkey::Pubkey}; use futures::StreamExt; use std::str::FromStr; #[tokio::main] async fn main() -> anyhow::Result<()> { let token = std::env::var("SUPANODE_TOKEN")?; let url = format!("wss://fra.sol.supanode.xyz:8900/?api-key={token}"); let client = PubsubClient::new(&url).await?; let pubkey = Pubkey::from_str("YOUR_ACCOUNT_PUBKEY")?; let config = RpcAccountInfoConfig { encoding: Some(UiAccountEncoding::Base64), commitment: Some(CommitmentConfig::confirmed()), ..Default::default() }; let (mut stream, unsubscribe) = client .account_subscribe(&pubkey, Some(config)) .await?; while let Some(update) = stream.next().await { println!("Lamports: {}", update.value.lamports); } unsubscribe().await; Ok(()) } ``` ```python import asyncio import os from solana.rpc.websocket_api import connect from solders.pubkey import Pubkey async def main(): url = f"wss://fra.sol.supanode.xyz:8900/?api-key={os.environ['SUPANODE_TOKEN']}" account = Pubkey.from_string("YOUR_ACCOUNT_PUBKEY") async with connect(url) as websocket: await websocket.account_subscribe( account, commitment="confirmed", encoding="base64", ) first_resp = await websocket.recv() subscription_id = first_resp[0].result async for msg in websocket: value = msg[0].result.value print("Lamports:", value.lamports) asyncio.run(main()) ``` ## Subscribe to a program (with required filter) `programSubscribe` requires either a `dataSize` or `memcmp` filter on shared plans. Whole-program subscriptions are blocked - see [Restrictions](https://supanode.xyz/docs/solana/websocket/restrictions). ```typescript import { Connection, PublicKey } from "@solana/web3.js"; const token = process.env.SUPANODE_TOKEN!; const connection = new Connection("https://fra.sol.supanode.xyz:8899", { httpHeaders: { "x-token": token }, // web3.js cannot set headers on the WS handshake — pass the token in the URL. wsEndpoint: `wss://fra.sol.supanode.xyz:8900/?api-key=${token}`, }); const programId = new PublicKey("YOUR_PROGRAM_ID"); const subscriptionId = connection.onProgramAccountChange( programId, (keyedAccountInfo) => { console.log("Account:", keyedAccountInfo.accountId.toBase58()); console.log("Lamports:", keyedAccountInfo.accountInfo.lamports); }, "confirmed", [{ dataSize: 165 }] // required filter ); ``` ```rust use solana_client::{ nonblocking::pubsub_client::PubsubClient, rpc_config::{RpcProgramAccountsConfig, RpcAccountInfoConfig}, rpc_filter::RpcFilterType, }; use solana_account_decoder::UiAccountEncoding; use solana_sdk::{commitment_config::CommitmentConfig, pubkey::Pubkey}; use futures::StreamExt; use std::str::FromStr; #[tokio::main] async fn main() -> anyhow::Result<()> { let token = std::env::var("SUPANODE_TOKEN")?; let url = format!("wss://fra.sol.supanode.xyz:8900/?api-key={token}"); let client = PubsubClient::new(&url).await?; let program_id = Pubkey::from_str("YOUR_PROGRAM_ID")?; let config = RpcProgramAccountsConfig { filters: Some(vec![RpcFilterType::DataSize(165)]), // required account_config: RpcAccountInfoConfig { encoding: Some(UiAccountEncoding::Base64), commitment: Some(CommitmentConfig::confirmed()), ..Default::default() }, ..Default::default() }; let (mut stream, unsubscribe) = client .program_subscribe(&program_id, Some(config)) .await?; while let Some(update) = stream.next().await { println!("Account: {}", update.value.pubkey); } unsubscribe().await; Ok(()) } ``` ```python import asyncio import os from solana.rpc.websocket_api import connect from solders.pubkey import Pubkey async def main(): url = f"wss://fra.sol.supanode.xyz:8900/?api-key={os.environ['SUPANODE_TOKEN']}" program = Pubkey.from_string("YOUR_PROGRAM_ID") async with connect(url) as websocket: await websocket.program_subscribe( program, commitment="confirmed", encoding="base64", filters=[{"dataSize": 165}], # required filter ) first_resp = await websocket.recv() subscription_id = first_resp[0].result async for msg in websocket: value = msg[0].result.value print("Account:", value.pubkey, "lamports:", value.account.lamports) asyncio.run(main()) ``` ```json { "jsonrpc": "2.0", "id": 1, "method": "programSubscribe", "params": [ "YOUR_PROGRAM_ID", { "encoding": "base64", "commitment": "confirmed", "filters": [{ "dataSize": 165 }] } ] } ``` ## Production tips 1. **Reconnect with exponential backoff.** WebSocket connections can drop. Implement retry starting at 1 second, capped at 30 seconds. 2. **Re-establish subscriptions on reconnect.** Subscription IDs are connection-scoped. After reconnect, all subscriptions are gone - resubscribe to what you need. 3. **Send a ping every 30-60 seconds.** Idle timeout is 10 minutes, but a periodic ping keeps the connection healthy and detects half-open sockets. 4. **Watch your subscription budget.** Total subs per plan is a hard cap. See [Limits](https://supanode.xyz/docs/solana/websocket/limits). 5. **Switch to gRPC for high throughput.** If you need many account / transaction streams at once, [gRPC](https://supanode.xyz/docs/solana/grpc/overview) is the right tool. ## Where to go next Connection caps and subscription totals. Blocked subscriptions. 24-hour trial. For high-throughput streams. --- ## Sender Source: https://supanode.xyz/docs/solana/sender/overview > Direct TPU transaction delivery via SWQoS plus Jito Bundle Engine in parallel. Pay-per-transaction via tip - no subscription. Direct TPU transaction delivery for traders. Routes transactions to slot leaders through stake-weighted TPU channels and Jito Bundle Engine in parallel - whichever lands first wins. **Currently unavailable.** The TPU Sender is temporarily paused while we rework the transaction-landing path. New sign-ups are on hold - this page describes the product for reference. Message [@supanode_tgs](https://telegram.me/supanode_tgs) to be notified when it returns. **Tips are required.** Every transaction must include a System Program transfer to one of Supanode's [tip accounts](https://supanode.xyz/docs/solana/sender/tips), minimum **1,000,000 lamports (0.001 SOL)**. Without a valid tip, the transaction is rejected at the gateway. ## What is Sender for? Public RPC drops transactions under heavy load. Sender bypasses the crowded RPC layer and pushes your transaction directly to the current slot leader. | Use case | Why Sender | |---|---| | HFT and arbitrage | You can't afford a missed leader window | | MEV extraction | Direct TPU + Jito tips in one call | | Sniper bots | Token launches need sub-second landing | | Liquidation keepers | Race conditions decided at TPU layer | | Trading in volatile markets | Reliability when public RPC is congested | ## How it works ``` Your app → Sender → [SWQoS TPU + Jito Bundle Engine] → Slot leader ``` Each transaction is forwarded along **two paths in parallel**: - **SWQoS** (stake-weighted Quality of Service) - directly to the current slot leader. - **Jito Bundle Engine** - via the validator block-building auction. Whichever path lands the transaction first wins. The other is dropped silently. Supanode tracks the leader schedule in real time so the SWQoS path always points at the correct validator. **Preflight is never run.** Sender doesn't simulate before forwarding. Validate locally first via [RPC](https://supanode.xyz/docs/solana/rpc/overview) `simulateTransaction`. ## What is the Sender rate limit? **5 TPS per client.** This is the throughput Sender provides — the same for every client. Sender is open access; no Bundle subscription is required. ## Pricing Pay-per-transaction via the **tip itself** - no subscription, no fixed monthly fee. The minimum tip is **1,000,000 lamports (0.001 SOL)** per transaction. See [Tips](https://supanode.xyz/docs/solana/sender/tips) for tip addresses and code samples. ## External references - [Jito documentation](https://docs.jito.wtf) ## Where to next First request in 5 minutes. JSON-RPC, HTTP Plaintext, HTTP Binary. Minimum tip and tip addresses. Regional endpoints and routing. --- ## Get started with Sender Source: https://supanode.xyz/docs/solana/sender/start > Send your first transaction through Supanode Sender in 5 minutes: pick a regional endpoint, attach a tip, and submit via JSON-RPC. From zero to first landed transaction in 5 minutes. **No API token, no IP allowlist.** Sender is open access - the tip in your transaction is your authorization. Tip and Bundle subscription are independent: Sender doesn't share auth with [RPC](https://supanode.xyz/docs/solana/rpc/overview) / [gRPC](https://supanode.xyz/docs/solana/grpc/overview) / [WebSocket](https://supanode.xyz/docs/solana/websocket/overview). ## What you'll need - A funded Solana wallet with enough SOL to cover the tip - minimum **1,000,000 lamports (0.001 SOL)** per transaction. See [Tips](https://supanode.xyz/docs/solana/sender/tips). - A signed transaction, base64-encoded. - An HTTP client - `curl` works, any language with HTTP support works. ## Send your first transaction Connect to the region nearest your servers for lowest latency. For most workloads in EU: `http://fra.landing.fast` (Frankfurt). See [Endpoints](https://supanode.xyz/docs/solana/sender/endpoints) for Amsterdam and Tokyo. Every transaction sent through Sender must include a System Program transfer to one of Supanode's [tip accounts](https://supanode.xyz/docs/solana/sender/tips). Without a tip, the transaction is rejected at the gateway. Minimum tip is **1,000,000 lamports (0.001 SOL)**. See [Tips](https://supanode.xyz/docs/solana/sender/tips) for tip addresses and code samples. ## Submit Pick the submission method matching your latency requirement. | Method | Latency | Best for | |---|---|---| | JSON-RPC | Low | Drop-in replacement for existing RPC clients | | HTTP Plaintext | Lower | Quick scripts, prototyping | | HTTP Binary | Lowest | Microsecond-critical workloads | Quick test using JSON-RPC: ```bash curl -sS 'http://fra.landing.fast' \ -H 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sendTransaction", "params": [ "YOUR_BASE64_ENCODED_TX", { "encoding": "base64", "skipPreflight": true } ] }' ``` For Plaintext and Binary methods, see [Submission methods](https://supanode.xyz/docs/solana/sender/send). ## Verify landing A `200` response means **forwarded**, not landed on-chain. Always verify with [RPC](https://supanode.xyz/docs/solana/rpc/overview) `getSignatureStatuses`. ```bash curl https://fra.sol.supanode.xyz:8899 \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "getSignatureStatuses", "params": [["YOUR_SIGNATURE"]] }' ``` Check that `confirmationStatus` is `confirmed` or `finalized`. ## Best practices - **Simulate before sending.** Sender never runs preflight. Run `simulateTransaction` against [RPC](https://supanode.xyz/docs/solana/rpc/overview) first. - **Single endpoint per app instance.** Pick the region closest to your servers, stick with it. - **Track landing rate.** Compare submitted transactions vs confirmed signatures. - **Exponential backoff on `429` / `500`.** Start at 1 second, cap at 30. ## Response codes | Code | Meaning | |---|---| | `200` | Transaction accepted and forwarded | | `429` | Rate limited - back off and retry | | `500` | Server error - retry with backoff | ## Where to next JSON-RPC, Plaintext, Binary. Minimum tip and tip addresses. Regional endpoints. What it is and how it works. --- ## Submission methods Source: https://supanode.xyz/docs/solana/sender/send > Three ways to submit transactions through Sender: JSON-RPC, HTTP Plaintext, HTTP Binary. Three ways to submit transactions, picked by latency requirement. **Tradeoff:** JSON-RPC is the easiest drop-in (existing Solana clients work unchanged). Plaintext and Binary trim parsing overhead for microsecond-sensitive paths. Pick by how much you care about latency vs simplicity. | Method | Latency | Body format | Max size | |---|---|---|---| | JSON-RPC | Low | JSON | - | | HTTP Plaintext | Lower | Base64 string | 2,048 bytes | | HTTP Binary | Lowest | Raw bincode | 1,232 bytes | All methods require a valid [tip](https://supanode.xyz/docs/solana/sender/tips) in the transaction. Preflight is never run regardless of `skipPreflight` value. ## JSON-RPC Standard Solana JSON-RPC `sendTransaction` format. Drop-in replacement for `https://api.mainnet-beta.solana.com`. **Endpoint:** `http://YOUR_REGION.landing.fast` ```bash curl -sS 'http://fra.landing.fast' \ -H 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sendTransaction", "params": [ "YOUR_BASE64_ENCODED_TX", { "encoding": "base64", "skipPreflight": true } ] }' ``` ```javascript const response = await fetch('http://fra.landing.fast', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'sendTransaction', params: [ base64EncodedTx, { encoding: 'base64', skipPreflight: true }, ], }), }); const { result: signature } = await response.json(); console.log('Signature:', signature); ``` ```rust use reqwest::Client; use serde_json::json; let client = Client::new(); let response = client .post("http://fra.landing.fast") .json(&json!({ "jsonrpc": "2.0", "id": 1, "method": "sendTransaction", "params": [ base64_encoded_tx, { "encoding": "base64", "skipPreflight": true } ] })) .send() .await?; let body: serde_json::Value = response.json().await?; let signature = body["result"].as_str().unwrap(); ``` **Response:** ```json { "jsonrpc": "2.0", "id": 1, "result": "5VBwR4LmgHpVvjqjNqKyL...SIGNATURE" } ``` **Required params:** - `encoding: "base64"` - required for reliable transmission. - `skipPreflight: true` - documented for compatibility. ## HTTP Plaintext Lower-overhead than JSON-RPC. Body is a single base64 string. Response is a plain bs58-encoded signature. **Endpoint:** `http://YOUR_REGION.landing.fast/plaintext` ```bash curl -sS 'http://fra.landing.fast/plaintext' \ -X POST \ -H 'Content-Type: text/plain' \ --data 'YOUR_BASE64_ENCODED_TX' ``` - **Body:** base64-encoded transaction. - **Max size:** 2,048 bytes. - **Response:** plain-text bs58-encoded signature. ## HTTP Binary Lowest overhead. Body is raw bincode-serialized transaction bytes. **Endpoint:** `http://YOUR_REGION.landing.fast/binary` ```bash curl -sS 'http://fra.landing.fast/binary' \ -X POST \ -H 'Content-Type: application/octet-stream' \ --data-binary @transaction.bin ``` - **Body:** raw transaction bytes (bincode serialized, same wire format as Solana SDK). - **Max size:** 1,232 bytes. - **Response:** plain-text bs58-encoded signature. ## Response codes | Code | Meaning | |---|---| | `200` | Transaction accepted and forwarded | | `429` | Rate limited - back off and retry | | `500` | Server error - retry with backoff | A `200` response means **forwarded**, not landed on-chain. Always verify with [RPC](https://supanode.xyz/docs/solana/rpc/overview) `getSignatureStatuses`. ## Constraints - No preflight - validate locally first. - No deduplication - submitting the same transaction twice forwards it twice. - One transaction per request. ## See also First request in 5 minutes. Minimum tip and tip addresses. Regional endpoints. --- ## Tips Source: https://supanode.xyz/docs/solana/sender/tips > Required tip on every Sender transaction. Minimum 1,000,000 lamports (0.001 SOL), tip addresses, and how to attach. Every transaction sent through Sender must include a tip. Without one, it's rejected at the gateway. ## Why are tips required? The tip pays for priority routing through Supanode's stake-weighted connection to the active leader and through Jito's bundle auction. Tips are paid only on transactions that get included - if your transaction doesn't land, the tip doesn't move. ## What is the minimum Sender tip? **1,000,000 lamports (0.001 SOL)** per transaction. Below this floor the transaction is rejected at the gateway. The amount above the minimum is your call - it depends on how aggressive you need to be during contention. Supanode doesn't publish recommended levels. ## How do you attach a tip? Add a System Program `transfer` instruction to your transaction, paying to one of the official tip addresses below. Placement within the transaction doesn't matter. ## Tip addresses Five rotating addresses. Choose **one randomly per transaction** to avoid hot-account contention. ``` 1andAhkXmzRbuD37iuzTLnYKRkBGU7X26zw1wv2FBpT 1andoC8jkb9EXEz1RpgQiuGqgm8sEAsASBScS2nip4f 1andeJ5dyAENtyMHSHv3ZXDzJEctmqgAFvGbssqoyvH 1andf7rAwTZHozYhEm7ieCMvWMczGbHDNbAR5ktsmAq 1andxYDwQuoWuDFJ1rdyGCXET5AfEc4H3nYJkaU9Eay ``` ## Code samples ### TypeScript ```typescript import { Connection, Keypair, SystemProgram, Transaction, PublicKey, LAMPORTS_PER_SOL, } from "@solana/web3.js"; const TIP_ACCOUNTS = [ "1andAhkXmzRbuD37iuzTLnYKRkBGU7X26zw1wv2FBpT", "1andoC8jkb9EXEz1RpgQiuGqgm8sEAsASBScS2nip4f", "1andeJ5dyAENtyMHSHv3ZXDzJEctmqgAFvGbssqoyvH", "1andf7rAwTZHozYhEm7ieCMvWMczGbHDNbAR5ktsmAq", "1andxYDwQuoWuDFJ1rdyGCXET5AfEc4H3nYJkaU9Eay", ]; function pickRandomTipAccount(): PublicKey { const random = TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)]; return new PublicKey(random); } const tipAmount = 1_000_000; // 0.001 SOL - minimum const tipInstruction = SystemProgram.transfer({ fromPubkey: payer.publicKey, toPubkey: pickRandomTipAccount(), lamports: tipAmount, }); transaction.add(tipInstruction); ``` ### Rust ```rust use solana_sdk::{pubkey::Pubkey, system_instruction}; use std::str::FromStr; use rand::seq::SliceRandom; const TIP_ACCOUNTS: [&str; 5] = [ "1andAhkXmzRbuD37iuzTLnYKRkBGU7X26zw1wv2FBpT", "1andoC8jkb9EXEz1RpgQiuGqgm8sEAsASBScS2nip4f", "1andeJ5dyAENtyMHSHv3ZXDzJEctmqgAFvGbssqoyvH", "1andf7rAwTZHozYhEm7ieCMvWMczGbHDNbAR5ktsmAq", "1andxYDwQuoWuDFJ1rdyGCXET5AfEc4H3nYJkaU9Eay", ]; fn pick_random_tip_account() -> Pubkey { let mut rng = rand::thread_rng(); let pick = TIP_ACCOUNTS.choose(&mut rng).unwrap(); Pubkey::from_str(pick).unwrap() } let tip_amount = 1_000_000u64; // 0.001 SOL - minimum let tip_ix = system_instruction::transfer( &payer.pubkey(), &pick_random_tip_account(), tip_amount, ); ``` ## Best practices - **Randomize per transaction.** Hot-account contention reduces throughput. Pick a different tip address each time. - **Track your landing rate.** If transactions aren't landing during contention, raising the tip is one lever. The right amount is workload-dependent. ## External references - [Jito documentation](https://docs.jito.wtf) ## See also - [Get started](https://supanode.xyz/docs/solana/sender/start) - [Submission methods](https://supanode.xyz/docs/solana/sender/send) - [Endpoints](https://supanode.xyz/docs/solana/sender/endpoints) --- ## Endpoints Source: https://supanode.xyz/docs/solana/sender/endpoints > Three regional Sender endpoints. Pick the closest one to your servers. Sender runs in three regions. Connect to **one endpoint** - the one closest to your servers. Pick the region closest to your **application server**, not your end users. Don't broadcast the same transaction to all three regions. ## Regional endpoints **Code:** FRA `http://fra.landing.fast` **Code:** AMS `http://ams.landing.fast` **Code:** TYO `http://tyo.landing.fast` ## Single endpoint, not broadcast Pick **one** regional endpoint per application instance. Don't broadcast the same transaction to all three. Once Sender forwards your transaction, it goes to the active Solana leader through SWQoS plus Jito Bundle Engine in parallel - that's already two parallel paths. Adding a third regional copy doesn't help landing rate; it just multiplies network load and tip risk (only one path can land, the others are wasted). ## Which region should I pick? The right choice is whatever's geographically closest to **your application server** (not your end users): - **EU servers** → Frankfurt or Amsterdam. - **APAC servers** → Tokyo. - **US East** → Frankfurt is usually fastest for trans-Atlantic. If you have NA latency-sensitive paths, contact us about adding NA capacity. ## Routing best practices - **One region per app instance.** Stick with it. Re-evaluate only if your infrastructure region changes. - **Measure before committing.** Latency from your specific datacenter may differ from textbook geography. Send a few `getVersion`-equivalent test calls to each candidate and pick the lowest RTT. - **No HTTPS yet.** All endpoints serve plain HTTP. HTTPS support is on the roadmap. ## See also First request in 5 minutes. JSON-RPC, Plaintext, Binary. Minimum tip and tip addresses. --- ## Indexer Source: https://supanode.xyz/docs/solana/indexer/overview > Decoded Solana DEX activity in ClickHouse: 21 tables across Pump.fun, PumpSwap, Raydium, Meteora and Jito, queryable with plain SQL. Flat $300/mo. Decoded Solana DEX transactions, indexed in real time and queryable with plain SQL. Run your own ClickHouse queries against the database, or have a recurring one deployed as a REST endpoint. **Skip the indexer, write queries.** Swaps, launches, migrations, transfers and tips are already decoded into typed columns - you write SQL instead of parsing transactions. ## What's covered | Protocol | Tables | |---|---| | **Pump.fun** | token creation, bonding-curve swaps, v2 swaps (including failed), AMM migrations, creator fee distributions, admin creator changes | | **PumpSwap** | swaps with pool reserves before/after, every fee component, creator / cashback / buyback fields, virtual quote reserves | | **Raydium** | AMM swaps, CPMM swaps, Launchpad swaps, Launchpad token creation, migrations into AMM and CPMM pools | | **LetsBonk.fun** | lands in the Raydium Launchpad tables | | **Meteora** | DLMM swaps, Dynamic Bonding Curve swaps | | **Jito** | transaction tips | | **Helper tables** | SPL and Token-2022 transfers, native SOL transfers, block index, high-precision transaction timestamps, precomputed peak market caps | Full column lists are in the [Table reference](https://supanode.xyz/docs/solana/indexer/tables). ## Scale Snapshot from 16 August 2026 - the database grows continuously. | | | |---|---| | Tables | **21** | | Columns | **463** | | Largest table | `pumpswap_all_swaps` - 5.06 billion rows, 1.6 TB | | Deepest history | `pumpfun_token_creation` - from 17 January 2024 | | Validation latency | **~15 seconds** from block confirmation | ## Key technical specs - **Engine:** ClickHouse, `MergeTree` family, daily partitioning, `default` database. - **Confirmed data only** - never `processed`-level rows that can revert. - **Retention is per table**, from 14 days on the timing tables to full history on the Pump.fun core - see [Schema conventions](https://supanode.xyz/docs/solana/indexer/database-schema#retention). - **Amounts are raw base units** - lamports for SOL, the mint's own base unit for tokens. - **Nanosecond timestamps** captured at our Amsterdam shred receiver, exposed through `tx_timestamps`. ## Two ways to query Production analytics, scheduled jobs, full SQL access. A recurring query deployed as a stable endpoint. ## Use cases - Launch-cohort and creator-quality analysis on Pump.fun and Raydium Launchpad. - Liquidity monitoring, pool reserve reconstruction, and fee-flow accounting. - Whale identification, wallet funding traces, and follow-the-leader strategies. - Splitting organic flow from aggregator-routed flow via `parent_program`. - MEV and market-microstructure work using sub-slot timing. - Cross-referencing on-chain swaps with off-chain market data. ## How to get access **v1 access is request-based**, not self-service. We review and provision manually. Message [@supanode_tgs](https://telegram.me/supanode_tgs) on Telegram. You receive your `x-token` plus a database username and password. See [Access](https://supanode.xyz/docs/solana/indexer/access) for connection details and code samples. ## Pricing **\$300/mo flat.** Full schema access, direct ClickHouse queries, and unlimited query volume within reason. Billed as its own subscription with the same duration slider as the Bundles (1 hour to 30 days). Custom REST endpoints and Python ETL flows are quoted per scope on top of the base \$300/mo. Contact [@supanode_tgs](https://telegram.me/supanode_tgs). ## Free trial **Up to 24 hours, no card**, with full schema access. Activate via Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). ## Where to next Connection, authentication, code samples. Shared columns, units, partitions, retention. All 21 tables, column by column. Working SQL you can paste. Sub-slot timing for MEV research. --- ## Access Source: https://supanode.xyz/docs/solana/indexer/access > Connect to the Solana Indexer via direct ClickHouse, custom REST APIs, or Python ETL. HTTP Basic plus an x-token header. Three ways to query the Indexer, picked by your workload. **Auth model:** every request needs both HTTP Basic (database `user` / `password`) **and** the `x-token` header. Missing or invalid `x-token` returns `403 Forbidden`. ## How to get credentials v1 access is **request-based**, not self-service. We provision manually after review. Request access via Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). After review, we issue your `x-token` plus database username and password. Use those credentials with the connection details below. ## Pick your access path Full SQL, your own queries, scheduled jobs. Recurring queries deployed as stable endpoints. Batch jobs, materialized aggregates, warehouse pushes. ## Direct ClickHouse ### Connection details | Property | Value | |---|---| | Host | `soldata.supanode.xyz` | | Port | `29001` | | Protocol | HTTPS / TLS 1.2+ | | Database | `default` | Tables live in the `default` database, so bare table names work; `default.pumpswap_all_swaps` is the fully qualified form. **Keep credentials out of source.** Put the host, port, user, password and token in environment variables or a local `.env` file - the `x-token` is the only thing standing between your quota and someone else's queries. ### Authentication layers Two layers required on every request: 1. **Database credentials** - HTTP Basic Auth (`user` / `password`). 2. **API token** - `x-token` header. ### First connection (curl) ```bash curl -H "x-token: YOUR_TOKEN" \ 'https://soldata.supanode.xyz:29001/?user=YOUR_USER&password=YOUR_PASSWORD' \ -d "SELECT version(), now(), 'Connect Success' as status" ``` If you get rows back, your connection and both auth layers are working. ### Code samples ```javascript import { createClient } from '@clickhouse/client'; const client = createClient({ url: 'https://soldata.supanode.xyz:29001', username: 'YOUR_USER', password: 'YOUR_PASSWORD', http_headers: { 'x-token': 'YOUR_TOKEN' }, tls: { rejectUnauthorized: false }, }); const result = await client.query({ query: ` SELECT signature, slot, signing_wallet, fee FROM pumpswap_all_swaps WHERE block_date_utc = today() ORDER BY slot DESC LIMIT 10 `, format: 'JSONEachRow', }); console.log(await result.json()); ``` The Python client requires injecting `x-token` via the underlying connection pool: ```python import clickhouse_connect from clickhouse_connect.driver import httputil # Inject the x-token header into all requests original_urlopen = httputil.PoolManager.urlopen def urlopen_with_token(self, *args, **kwargs): kwargs.setdefault('headers', {}) kwargs['headers']['x-token'] = 'YOUR_TOKEN' return original_urlopen(self, *args, **kwargs) httputil.PoolManager.urlopen = urlopen_with_token client = clickhouse_connect.get_client( host='soldata.supanode.xyz', port=29001, secure=True, username='YOUR_USER', password='YOUR_PASSWORD', ) result = client.query(""" SELECT signature, slot, signing_wallet, fee FROM pumpswap_all_swaps WHERE block_date_utc = today() ORDER BY slot DESC LIMIT 10 """) for row in result.result_rows: print(row) ``` ```go package main import ( "context" "fmt" "github.com/ClickHouse/clickhouse-go/v2" ) func main() { conn, err := clickhouse.Open(&clickhouse.Options{ Addr: []string{"soldata.supanode.xyz:29001"}, Auth: clickhouse.Auth{ Username: "YOUR_USER", Password: "YOUR_PASSWORD", }, Protocol: clickhouse.HTTP, HttpHeaders: map[string]string{ "x-token": "YOUR_TOKEN", }, }) if err != nil { panic(err) } rows, err := conn.Query(context.Background(), ` SELECT signature, slot, signing_wallet, fee FROM pumpswap_all_swaps WHERE block_date_utc = today() LIMIT 10 `) if err != nil { panic(err) } defer rows.Close() for rows.Next() { var signature, signingWallet string var slot, fee uint64 if err := rows.Scan(&signature, &slot, &signingWallet, &fee); err != nil { panic(err) } fmt.Printf("%s slot=%d wallet=%s fee=%d\n", signature, slot, signingWallet, fee) } } ``` ## Custom REST API For specific recurring queries you don't want to write each time, we deploy custom REST endpoints. You define what data you need (which tables, what filters, what aggregations); we deploy a stable URL that returns it. Useful for dashboards, partner integrations, and AI-agent workflows. **When to pick this over direct ClickHouse:** the same query runs over and over from many places, or non-engineers need access without learning SQL. To request a custom REST API, contact us with: - The query (or a sketch of what you need). - Expected request volume. - Authentication preference (`x-token`, public, OAuth - we can do most). Contact: [@supanode_tgs](https://telegram.me/supanode_tgs). ## Python ETL flows For batch transformations and scheduled aggregations beyond simple queries, we build custom Python ETL on top of the database. Examples: - Daily aggregates pushed to your warehouse. - Custom indicators computed and stored as new tables. - Cross-protocol joins materialized for low-latency reads. Same contact path: [@supanode_tgs](https://telegram.me/supanode_tgs). ## See also Shared columns, units, partitions, retention. All 21 tables, column by column. Working SQL you can paste. Sub-slot timing via `tx_timestamps`. --- ## Schema conventions Source: https://supanode.xyz/docs/solana/indexer/database-schema > How the Solana Indexer schema is put together: shared columns, raw base units, partition keys, retention windows, and the padding and naming gotchas that bite first. The Solana database holds 21 tables and 463 columns of decoded DEX activity. This page covers what is true across all of them; the per-table column lists live in the [Table reference](https://supanode.xyz/docs/solana/indexer/tables). **Read this page before your first query.** Four conventions - fixed-width padding, raw base units, per-table partition keys, and per-table retention - explain most of the surprises people hit in week one. ## Shared columns Almost every table carries the same transaction envelope. Use it for joins, time-series aggregation, and wallet-level work. | Column | Type | What it is | |---|---|---| | `block_time` | DateTime | UTC timestamp of the block | | `block_date_utc` | Date | UTC date, and on most tables the partition key | | `slot` | UInt32 / UInt64 | Solana slot number | | `tx_idx` | UInt16 / UInt32 | Transaction index within the block | | `signature` | String / FixedString(128) | Transaction signature, base58 | | `fee_payer` | String | Wallet that paid the fee | | `fee` | UInt64 | Fee actually paid, in lamports | | `provided_gas_fee` | UInt64 | Compute-unit price the transaction offered | | `provided_gas_limit` | UInt64 | Compute-unit limit requested | | `consumed_gas` | UInt64 | Compute units actually burned | | `parent_program` | String | Program that invoked this instruction through CPI | `(slot, tx_idx)` identifies a transaction inside a block, and together with `signature` it is what you join on across tables. **`parent_program` is the aggregator fingerprint.** A swap routed through Jupiter, a bot, or any other program carries that program's address here, while a direct call to the DEX does not. It is the cheapest way to split organic flow from routed flow. ## Four gotchas ### 1. Fixed-width columns are null-padded Older tables store mints, wallets, and signatures as `FixedString(48)` or `FixedString(128)`. ClickHouse pads the unused bytes with `\0`, so a raw value will not compare equal to a plain base58 string, and grouping by it produces keys with invisible trailing bytes. Strip the padding on both sides of any comparison or join: ```sql SELECT replaceAll(toString(mint), '\0', '') AS mint_clean, count() AS launches FROM pumpfun_token_creation WHERE block_time >= now() - INTERVAL 1 DAY GROUP BY mint_clean ``` Newer tables use plain `String` and need no cleanup. The [Table reference](https://supanode.xyz/docs/solana/indexer/tables) shows the exact type per column. ### 2. Every amount is a raw base unit Token and SOL amounts are integers in the smallest unit - lamports for SOL, and the mint's own base unit for SPL tokens. Nothing is pre-divided by decimals, and nothing is converted to USD. Divide by `1e9` for SOL; for a token, apply that mint's decimals. Fee-rate columns follow the same rule: `lp_fee_basis_points` and `protocol_fee_basis_points` are basis points, not fractions. ### 3. The partition key is not the same on every table Most tables partition on `block_date_utc`, but not all: | Partition key | Tables | |---|---| | `block_date_utc` | most swap and migration tables | | `block_date` | `meteora_swaps` | | `(block_date_utc, failed)` | `pumpfun_v2_swaps` | | `toYYYYMM(block_time)` | `pumpfun_amm_admin_set_coin_creator` | | `toYYYYMMDD(block_time)` | `pumpfun_creator_fee_distributions` | | `toYYYYMMDD(toDateTime(entry_timestamp))` | `tx_timestamps` | | none | `pumpfun_token_creation`, `pumpfun_all_swaps`, `raydium_launchpad_token_creation`, `solana_blocks`, `max_caps` | **Filter on the partition column, and do it in `PREWHERE`.** A swap query with no partition filter reads the whole table - on `pumpswap_all_swaps` that is 1.6 TB and 5 billion rows. `PREWHERE block_date_utc >= today() - 7` cuts it to the parts you need before any other column is read. ### 4. Some columns only carry data from a certain date Columns added after a table went live are marked *(populated since ...)* in the [Table reference](https://supanode.xyz/docs/solana/indexer/tables). The column exists on every row, but rows older than that date hold the type default - an empty string or a zero, not a NULL. Filter on the date range as well as the column value, or old rows will quietly look like real zeros. ## Retention Retention is per table. Nothing is a single global window. | Window | Tables | |---|---| | 14 days | `tx_timestamps`, `jito_tips` | | 31 days | `token_transfers`, `sol_top_ups` | | 90 days | `meteora_swaps`, `raydium_all_swaps`, `raydium_cpmm_swaps` | | 1 year | `pumpswap_all_swaps`, `pfamm_migrations`, `meteora_dynamic_bonding_swaps`, all `raydium_launchpad_*` | | Full history | `pumpfun_all_swaps`, `pumpfun_v2_swaps`, `pumpfun_token_creation`, `pumpfun_creator_fee_distributions`, `pumpfun_amm_admin_set_coin_creator`, `solana_blocks`, `max_caps` | **Need a longer window than the table keeps?** Extended retention and one-off exports are arranged per customer - message [@supanode_tgs](https://telegram.me/supanode_tgs) before you build a pipeline that assumes the data will still be there. ## Coverage and latency The deepest table, `pumpfun_token_creation`, starts **17 January 2024**. Every table's own window is listed in the [Table reference](https://supanode.xyz/docs/solana/indexer/tables). **~15 seconds** between block confirmation and the row being queryable. Confirmed transactions only - never `processed`-level data that can revert. ## Storage engine | Setting | Value | |---|---| | Database | ClickHouse, `default` database | | Engine | `MergeTree` family | | Partitioning | daily on the table's date column (see above) | | Sort order | `(slot, tx_idx)` on transaction tables | | Nanosecond timing | separate `tx_timestamps` table, joined on `(slot, tx_idx)` | ## See also All 21 tables, column by column. Working SQL you can paste. Sub-block timing via `tx_timestamps`. --- ## Solana table reference Source: https://supanode.xyz/docs/solana/indexer/tables > Full schema for the Supanode Solana Indexer - 21 tables and 463 columns across Pump.fun, PumpSwap, Raydium, Meteora and Jito, with every type, partition key and retention window. The Solana database contains decoded DEX activity plus reusable helper tables. This page documents every table, column, type, and description. For runnable patterns see [Query examples](https://supanode.xyz/docs/solana/indexer/examples); for the conventions that apply across tables see [Schema conventions](https://supanode.xyz/docs/solana/indexer/database-schema); for connection details see [Access](https://supanode.xyz/docs/solana/indexer/access). **Schema snapshot: 16 August 2026.** Row counts and sizes grow continuously. Columns marked *(populated since ...)* exist on every row but only carry data from that date onward - older rows hold the type default. ## Tables overview | Table | Protocol | Rows | Size | History | Retention | |---|---|---|---|---|---| | [`pumpfun_token_creation`](#pumpfuntokencreation) | Pump.fun | 16,158,167 | 4.10 GB | 2024-01-17 → 2026-08-16 | full history | | [`pumpfun_all_swaps`](#pumpfunallswaps) | Pump.fun | 2,447,780,900 | 322.27 GB | 2024-06-11 → 2026-08-16 | full history | | [`pumpfun_v2_swaps`](#pumpfunv2swaps) | Pump.fun | 1,352,692,572 | 185.82 GB | 2024-11-02 → 2026-08-16 | full history | | [`pfamm_migrations`](#pfammmigrations) | Pump.fun | 106,004 | 24.4 MB | 2025-08-16 → 2026-08-16 | 1 year | | [`pumpfun_creator_fee_distributions`](#pumpfuncreatorfeedistributions) | Pump.fun | 1,862,105 | 301.8 MB | 2026-02-15 → 2026-08-16 | full history | | [`pumpfun_amm_admin_set_coin_creator`](#pumpfunammadminsetcoincreator) | Pump.fun | 751 | 143.1 KB | 2026-03-15 → 2026-08-16 | full history | | [`pumpswap_all_swaps`](#pumpswapallswaps) | PumpSwap | 5,061,985,647 | 1656.07 GB | 2025-08-16 → 2026-08-16 | 1 year | | [`raydium_all_swaps`](#raydiumallswaps) | Raydium | 14,866,785 | 2.09 GB | 2026-05-18 → 2026-08-16 | 90 days | | [`raydium_cpmm_swaps`](#raydiumcpmmswaps) | Raydium | 15,924,873 | 3.73 GB | 2026-05-18 → 2026-08-16 | 90 days | | [`raydium_launchpad_swaps`](#raydiumlaunchpadswaps) | Raydium | 22,880,401 | 3.86 GB | 2025-08-16 → 2026-08-16 | 1 year | | [`raydium_launchpad_token_creation`](#raydiumlaunchpadtokencreation) | Raydium | 65,568 | 19.9 MB | 2025-04-16 → 2025-10-15 | full history | | [`raydium_launchpad_migrations`](#raydiumlaunchpadmigrations) | Raydium | 94 | 478.6 KB | 2025-08-16 → 2026-08-14 | 1 year | | [`raydium_launchpad_cpmm_migrations`](#raydiumlaunchpadcpmmmigrations) | Raydium | 3,664 | 4.0 MB | 2025-08-16 → 2026-08-16 | 1 year | | [`meteora_swaps`](#meteoraswaps) | Meteora | 75,434,658 | 13.48 GB | 2026-05-18 → 2026-08-16 | 90 days | | [`meteora_dynamic_bonding_swaps`](#meteoradynamicbondingswaps) | Meteora | 152,076,712 | 41.81 GB | 2025-08-18 → 2026-08-16 | 1 year | | [`jito_tips`](#jitotips) | Jito | 135,442,770 | 10.22 GB | 2026-08-02 → 2026-08-16 | 14 days | | [`token_transfers`](#tokentransfers) | Helper | 146,085,642 | 22.57 GB | 2026-07-20 → 2026-08-16 | 31 days | | [`sol_top_ups`](#soltopups) | Helper | 173,385,646 | 28.29 GB | 2026-07-20 → 2026-08-16 | 31 days | | [`solana_blocks`](#solanablocks) | Helper | 184,679,641 | 9.46 GB | full chain history → 2026-08-16 | full history | | [`tx_timestamps`](#txtimestamps) | Helper | 2,744,043,346 | 243.84 GB | rolling window | 14 days | | [`max_caps`](#maxcaps) | Helper | 9,353,726 | 438.8 MB | rolling window | full history | **Retention is per table, not one global window.** `tx_timestamps` and `jito_tips` hold 14 days, `token_transfers` and `sol_top_ups` hold 31 days, the Raydium and Meteora AMM tables hold 90 days, and the rest hold a year or their full history. If your analysis needs a longer window on a short-retention table, tell us before you start - extended retention and one-off exports are arranged per customer. **Always filter on the partition column first.** Each table lists its partition key below. A swap query without that filter scans the whole table - on `pumpswap_all_swaps` that is 1.6 TB. ## pumpfun_token_creation Every Pump.fun launch, with bundle forensics - bundle size and structure, bundled buys, and the dev's balance right after creation. **Partition key:** not partitioned **History:** 2024-01-17 → 2026-08-16 **Retention:** full history **Rows:** 16,158,167 · **Size:** 4.10 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `creator` | FixedString(48) | Wallet that created the token | | `name` | FixedString(20) | Token name | | `symbol` | FixedString(16) | Token ticker symbol | | `url` | FixedString(256) | Metadata URI (usually IPFS) | | `mint` | FixedString(48) | Token mint address | | `bundle_size` | UInt8 | Number of transactions in the bundle | | `gas_used` | UInt64 | Total gas used for token creation | | `amount_of_instructions` | Int32 | Number of instructions in the transaction | | `amount_of_lookup_reads` | Int32 | Number of address lookup table reads | | `amount_of_lookup_writes` | Int32 | Number of address lookup table writes | | `bundle_structure` | String | Structure of bundled transactions | | `bundled_buys` | UInt64 | Total SOL amount in bundled buys | | `bundled_buys_count` | UInt64 | Number of bundled buy transactions | | `dev_balance` | UInt64 | Developer's token balance after creation | | `creation_ix_index` | Int32 | Index of creation instruction | | `curve_address` | FixedString(48) | Bonding curve account address | | `pf_program_index` | UInt8 | Pump.fun program index in transaction | | `direct_pf_invocation` | UInt8 | Whether pump.fun was called directly (1=yes, 0=no) | | `version` | DateTime64(3) | Record version timestamp *(populated since 2024-01-17)* | | `mayhem_mode` | UInt8 | Whether mayhem mode was enabled *(populated since 2025-11-12)* | | `token_program` | String | Token program used (SPL Token or Token-2022) *(populated since 2024-01-17)* | | `signature` | String | Transaction signature (base58 encoded) *(populated since 2024-01-17)* | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2026-01-22)* | | `is_cashback_enabled` | UInt8 | Whether cashback was enabled for creation *(populated since 2026-02-18)* | ## pumpfun_all_swaps Pump.fun bonding-curve swaps. The deepest history in the database and one of its largest tables. **Partition key:** not partitioned **History:** 2024-06-11 → 2026-08-16 **Retention:** full history **Rows:** 2,447,780,900 · **Size:** 322.27 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `signing_wallet` | FixedString(48) | Wallet address that signed the transaction | | `direction` | String | Trade direction (buy/sell) | | `base_coin` | FixedString(48) | Base token mint address | | `base_coin_amount` | UInt64 | Base token amount (raw units, needs decimal adjustment) | | `quote_coin_amount` | UInt64 | Quote token amount (raw units) | | `virtual_token_balance_after` | UInt64 | Virtual token reserves after trade (bonding curve state) | | `virtual_sol_balance_after` | UInt64 | Virtual SOL reserves after trade (bonding curve state) | | `signature` | FixedString(128) | Transaction signature (base58 encoded) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | | `is_exact_quote` | UInt8 | Whether quote amount was exact (1=yes, 0=no) *(populated since 2025-12-03)* | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2024-11-02)* | ## pumpfun_v2_swaps The Pump.fun v2 instruction set, including failed transactions and the compute-budget instruction indexes. **Partition key:** `(block_date_utc, failed)` **History:** 2024-11-02 → 2026-08-16 **Retention:** full history **Rows:** 1,352,692,572 · **Size:** 185.82 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `ix_idx` | Int16 | Instruction index within the transaction *(populated since 2024-11-02)* | | `signing_wallet` | String | Wallet address that signed the transaction | | `fee_payer` | String | Wallet that paid the transaction fee *(populated since 2024-11-02)* | | `direction` | LowCardinality(String) | Trade direction (buy/sell) | | `base_coin` | String | Base token mint address | | `quote_coin` | LowCardinality(String) | Quote token mint address (usually SOL or USDC) | | `instruction_type` | LowCardinality(String) | Pump.fun instruction variant: `buy`, `sell`, `buy_v2`, `sell_v2`, `buy_exact_sol_in`, or `buy_exact_quote_in_v2` | | `base_coin_amount` | UInt64 | Base token amount (raw units, needs decimal adjustment) | | `quote_coin_amount` | UInt64 | Quote token amount (raw units) | | `virtual_token_balance_after` | UInt64 | Virtual token reserves after trade (bonding curve state) | | `virtual_sol_balance_after` | UInt64 | Virtual SOL reserves after trade (bonding curve state) | | `signature` | String | Transaction signature (base58 encoded) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | | `lookup_tables` | String | Pipe-delimited account addresses loaded through address lookup tables (writable first, then read-only) *(populated since 2024-11-02)* | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2024-11-02)* | | `failed` | UInt8 | Whether the transaction failed (1=yes, 0=no) *(populated since 2024-11-02)* | | `pf_program_account_index` | Int16 | Default: `-1` *(populated since 2024-11-02)* | | `cu_price_ix_index` | Int16 | Instruction index of the compute-unit price instruction *(populated since 2024-11-02)* | | `cu_limit_ix_index` | Int16 | Instruction index of the compute-unit limit instruction *(populated since 2024-11-02)* | | `tip_index` | Int16 | Default: `-1` *(populated since 2024-11-02)* | ## pfamm_migrations Pump.fun graduations to the PumpSwap AMM - one row per migrated mint. **Partition key:** `block_date_utc` **History:** 2025-08-16 → 2026-08-16 **Retention:** 1 year **Rows:** 106,004 · **Size:** 24.4 MB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `user` | String | User wallet address | | `mint` | String | Token mint address | | `mint_amount` | UInt64 | Token amount migrated | | `sol_amount` | UInt64 | SOL amount in the migration | | `pool_migration_fee` | UInt64 | Fee paid for pool migration | | `bonding_curve` | String | Bonding curve account address | | `timestamp` | UInt32 | Unix timestamp of migration | | `pool` | String | Pool account address | | `signature` | String | Transaction signature (base58 encoded) *(populated since 2025-11-10)* | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2026-01-22)* | ## pumpfun_creator_fee_distributions Creator fee payouts: which mint, which wallet received it, how much. **Partition key:** `toYYYYMMDD(block_time)` **History:** 2026-02-15 → 2026-08-16 **Retention:** full history **Rows:** 1,862,105 · **Size:** 301.8 MB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `ix_idx` | UInt32 | Instruction index within the transaction | | `signature` | String | Transaction signature (base58 encoded) | | `fee_payer` | String | Wallet that paid the transaction fee | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `mint` | String | Token mint address | | `receiver` | String | Creator wallet receiving the fee distribution | | `amount` | UInt64 | Fee amount distributed (lamports) | | `fee_distribution_method` | String | Method used for fee distribution *(populated since 2026-02-15)* | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2026-05-29)* | ## pumpfun_amm_admin_set_coin_creator Admin changes to a pool's coin creator. A small table, but it decides creator-fee attribution. **Partition key:** `toYYYYMM(block_time)` **History:** 2026-03-15 → 2026-08-16 **Retention:** full history **Rows:** 751 · **Size:** 143.1 KB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `swap_idx` | Int32 | Swap index within the transaction | | `signature` | String | Transaction signature (base58 encoded) | | `fee_payer` | String | Wallet that paid the transaction fee | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `pool` | String | Pool account being modified | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | ## pumpswap_all_swaps PumpSwap AMM swaps with complete reserve and fee accounting. The largest table here. **Partition key:** `block_date_utc` **History:** 2025-08-16 → 2026-08-16 **Retention:** 1 year **Rows:** 5,061,985,647 · **Size:** 1656.07 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `signing_wallet` | String | Wallet address that signed the transaction | | `fee_payer` | String | Wallet that paid the transaction fee | | `direction` | LowCardinality(String) | Trade direction (buy/sell) | | `base_token` | String | Base token mint address | | `quote_token` | String | Quote token mint address | | `base_token_amount` | UInt64 | Base token amount (raw units) | | `quote_token_amount` | UInt64 | Quote token amount (raw units) | | `quote_token_amount_limit` | UInt64 | Maximum quote token amount limit | | `quote_token_amount_without_lp_fee` | UInt64 | Quote amount before LP fee deduction | | `user_base_token_account` | String | User's base token account | | `user_quote_token_account` | String | User's quote token account | | `user_base_token_reserves` | UInt64 | User's base token balance | | `user_quote_token_reserves` | UInt64 | User's quote token balance | | `pool_base_token_reserves_before` | UInt64 | Pool base token reserves before swap | | `pool_quote_token_reserves_before` | UInt64 | Pool quote token reserves before swap | | `pool_base_token_reserves_after` | UInt64 | Pool base token reserves after swap | | `pool_quote_token_reserves_after` | UInt64 | Pool quote token reserves after swap | | `lp_fee_basis_points` | UInt16 | LP fee in basis points | | `lp_fee` | UInt64 | LP fee amount | | `protocol_fee_basis_points` | UInt16 | Protocol fee in basis points | | `protocol_fee` | UInt64 | Protocol fee amount | | `signature` | String | Transaction signature (base58 encoded) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `pool` | String | Pool account address *(populated since 2025-08-16)* | | `is_exact_quote` | UInt8 | Whether quote amount was exact (1=yes, 0=no) *(populated since 2025-12-03)* | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2025-12-13)* | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction *(populated since 2026-02-18)* | | `coin_creator` | String | Default: `''` *(populated since 2026-07-23)* | | `coin_creator_fees_basis_points` | UInt64 | Default: `0` *(populated since 2026-07-23)* | | `coin_creator_fees` | UInt64 | Default: `0` *(populated since 2026-07-23)* | | `cash_back_fees_basis_points` | UInt64 | Default: `0` *(populated since 2026-07-23)* | | `cash_back_fees` | UInt64 | Default: `0` *(populated since 2026-07-23)* | | `buy_back_fees_basis_points` | UInt64 | Default: `0` *(populated since 2026-07-23)* | | `buy_back_fees` | UInt64 | Default: `0` *(populated since 2026-07-23)* | | `virtual_quote_reserves` | Int128 | Default: `0` *(populated since 2026-07-23)* | | `can_boost` | UInt8 | Default: `0` *(populated since 2026-07-23)* | | `base_supply` | UInt64 | Default: `0` *(populated since 2026-07-23)* | ## raydium_all_swaps Raydium AMM swaps with pool balances before and after, plus the OpenBook market id. **Partition key:** `block_date_utc` **History:** 2026-05-18 → 2026-08-16 **Retention:** 90 days **Rows:** 14,866,785 · **Size:** 2.09 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `signing_wallet` | FixedString(48) | Wallet address that signed the transaction | | `direction` | String | Trade direction (buy/sell) | | `base_coin` | FixedString(48) | Base token mint address | | `quote_coin` | FixedString(48) | Quote token mint address (usually SOL or USDC) | | `base_coin_amount` | UInt64 | Base token amount (raw units, needs decimal adjustment) | | `quote_coin_amount` | UInt64 | Quote token amount (raw units) | | `base_pool_balance_before` | UInt64 | Pool base token balance before swap | | `quote_pool_balance_before` | UInt64 | Pool quote token balance before swap | | `base_pool_balance_after` | UInt64 | Pool base token balance after swap | | `quote_pool_balance_after` | UInt64 | Pool quote token balance after swap | | `signature` | FixedString(128) | Transaction signature (base58 encoded) | | `serum_market_id` | FixedString(48) | OpenBook/Serum market ID (for hybrid pools) | | `raydium_market_id` | FixedString(48) | Raydium AMM market ID | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2026-05-18)* | ## raydium_cpmm_swaps Raydium CPMM swaps with pool sizes, per-side fees, and swap type. **Partition key:** `block_date_utc` **History:** 2026-05-18 → 2026-08-16 **Retention:** 90 days **Rows:** 15,924,873 · **Size:** 3.73 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `swap_idx` | UInt16 | Swap index within the transaction | | `signature` | String | Transaction signature (base58 encoded) | | `fee_payer` | String | Wallet that paid the transaction fee | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `pool_id` | String | Pool account address | | `signer` | String | Wallet address that signed the transaction | | `direction` | LowCardinality(String) | Trade direction (buy/sell) | | `base_coin` | String | Base token mint address | | `quote_coin` | String | Quote token mint address (usually SOL or USDC) | | `base_coin_amount` | UInt64 | Base token amount (raw units, needs decimal adjustment) | | `quote_coin_amount` | UInt64 | Quote token amount (raw units) | | `base_coin_slippage` | Int64 | Slippage on base token | | `quote_coin_slippage` | Int64 | Slippage on quote token | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | | `input_token_pool_size_before` | UInt64 | Input token pool size before swap | | `output_token_pool_size_before` | UInt64 | Output token pool size before swap | | `tokens_in` | UInt64 | Tokens received by pool | | `tokens_out` | UInt64 | Tokens sent from pool | | `fee_in_token_in` | UInt64 | Fee denominated in input token | | `fee_in_token_out` | UInt64 | Fee denominated in output token | | `swap_type` | LowCardinality(String) | Type of swap (BaseIn/BaseOut) | | `instruction_input1` | UInt64 | First instruction input parameter | | `instruction_input2` | UInt64 | Second instruction input parameter | | `input_token_mint` | String | Input token mint address | | `output_token_mint` | String | Output token mint address | ## raydium_launchpad_swaps Raydium Launchpad bonding-curve swaps - this is where LetsBonk.fun activity lands. **Partition key:** `block_date_utc` **History:** 2025-08-16 → 2026-08-16 **Retention:** 1 year **Rows:** 22,880,401 · **Size:** 3.86 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `fee_payer` | String | Wallet that paid the transaction fee | | `direction` | LowCardinality(String) | Trade direction (buy/sell) | | `pool_status` | UInt8 | Pool status code | | `pool_state` | String | Pool state account address | | `base_token` | String | Base token mint address | | `quote_token` | String | Quote token mint address | | `total_base_sell` | UInt64 | Total base tokens available for sale | | `virtual_base` | UInt64 | Virtual base token reserves | | `virtual_quote` | UInt64 | Virtual quote token reserves | | `pool_base_token_reserves_before` | UInt64 | Pool base token reserves before swap | | `pool_quote_token_reserves_before` | UInt64 | Pool quote token reserves before swap | | `pool_base_token_reserves_after` | UInt64 | Pool base token reserves after swap | | `pool_quote_token_reserves_after` | UInt64 | Pool quote token reserves after swap | | `base_token_amount` | UInt64 | Base token amount (raw units) | | `quote_token_amount` | UInt64 | Quote token amount (raw units) | | `protocol_fee` | UInt64 | Protocol fee amount | | `platform_fee` | UInt64 | Platform fee amount | | `share_fee` | UInt64 | Share/referral fee amount | | `signature` | String | Transaction signature (base58 encoded) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | ## raydium_launchpad_token_creation Raydium Launchpad token launches, with bonding-curve parameters and bundle forensics. Historical only - no new rows since October 2025, as launches moved to the CPMM path. **Partition key:** not partitioned **History:** 2025-04-16 → 2025-10-15 **Retention:** full history **Rows:** 65,568 · **Size:** 19.9 MB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `creator` | FixedString(48) | Wallet that created the token | | `name` | FixedString(20) | Token name | | `symbol` | FixedString(16) | Token ticker symbol | | `url` | FixedString(256) | Metadata URI (usually IPFS) | | `mint` | FixedString(48) | Token mint address | | `bundle_size` | UInt8 | Number of transactions in the bundle | | `gas_used` | UInt64 | Total gas used for token creation | | `amount_of_instructions` | Int32 | Number of instructions in the transaction | | `amount_of_lookup_reads` | Int32 | Number of address lookup table reads | | `amount_of_lookup_writes` | Int32 | Number of address lookup table writes | | `bundle_structure` | String | Structure of bundled transactions | | `bundled_buys` | UInt64 | Total SOL amount in bundled buys | | `bundled_buys_count` | UInt64 | Number of bundled buy transactions | | `dev_balance` | UInt64 | Developer's token balance after creation | | `creation_ix_index` | Int32 | Index of creation instruction | | `pool_state` | FixedString(48) | Pool state account address | | `base_vault` | FixedString(48) | Base token vault address | | `quote_vault` | FixedString(48) | Quote token vault address | | `raydium_program_index` | UInt8 | Raydium program index in transaction | | `direct_raydium_invocation` | Bool | Whether Raydium was called directly | | `decimals` | UInt8 | Token decimals | | `cpmm_type` | UInt8 | CPMM pool type | | `supply` | UInt64 | Total token supply | | `bonding_curve_sell_amount` | UInt64 | Amount available for bonding curve sale | | `bonding_curve_raise_amount` | UInt64 | Target raise amount for bonding curve | | `migrate_type` | UInt8 | Migration type after bonding curve | | `version` | DateTime64(3) | Record version timestamp *(populated since 2025-04-16)* | ## raydium_launchpad_migrations Raydium Launchpad graduations into AMM / OpenBook markets. **Partition key:** `block_date_utc` **History:** 2025-08-16 → 2026-08-14 **Retention:** 1 year **Rows:** 94 · **Size:** 478.6 KB | Column | Type | Description | |---|---|---| | `signature` | String | Transaction signature (base58 encoded) | | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `payer` | String | Wallet that paid for the migration | | `base_coin` | String | Base token mint address | | `quote_coin` | String | Quote token mint address (usually SOL or USDC) | | `openbook_program` | String | OpenBook program address | | `serum_market_id` | String | OpenBook market ID | | `request_queue` | String | OpenBook request queue | | `event_queue` | String | OpenBook event queue | | `bids` | String | OpenBook bids account | | `asks` | String | OpenBook asks account | | `market_vault_signer` | String | OpenBook vault signer | | `market_base_vault` | String | OpenBook base token vault | | `market_quote_vault` | String | OpenBook quote token vault | | `raydium_program` | String | Raydium AMM program address | | `raydium_market_id` | String | Raydium AMM market ID | | `amm_authority` | String | Raydium AMM authority | | `amm_open_orders` | String | Raydium open orders account | | `lp_mint` | String | LP token mint address | | `base_pool_balance_before` | String | Pool base token balance before migration | | `quote_pool_balance_before` | String | Pool quote token balance before migration | | `amm_target_orders` | String | Raydium target orders account | | `amm_config` | String | Raydium AMM configuration | | `amm_create_fee_dest` | String | Destination for AMM creation fee | | `authority` | String | Launchpad authority account | | `pool_state` | String | Launchpad pool state account | | `global_config` | String | Global configuration account | | `user_token_coin` | String | User's base token account | | `user_token_pc` | String | User's quote token account | | `user_lp_token_account` | String | User's LP token account | | `token_program` | String | Token program address | | `associated_token_program` | String | Associated token program address | | `system_program` | String | System program address | | `rent_program` | String | Rent sysvar address | ## raydium_launchpad_cpmm_migrations Raydium Launchpad graduations into CPMM pools, with every account involved in the migration. **Partition key:** `block_date_utc` **History:** 2025-08-16 → 2026-08-16 **Retention:** 1 year **Rows:** 3,664 · **Size:** 4.0 MB | Column | Type | Description | |---|---|---| | `signature` | String | Transaction signature (base58 encoded) | | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `payer` | String | Wallet that paid for the migration | | `base_mint` | String | Base token mint address | | `quote_mint` | String | Quote token mint address | | `platform_config` | String | Platform configuration account | | `cpswap_program` | String | CPMM swap program address | | `cpswap_pool` | String | New CPMM pool address | | `cpswap_authority` | String | CPMM pool authority | | `cpswap_lp_mint` | String | CPMM LP token mint | | `cpswap_base_vault` | String | CPMM base token vault | | `cpswap_quote_vault` | String | CPMM quote token vault | | `cpswap_config` | String | CPMM configuration account | | `cpswap_create_pool_fee` | String | Fee account for pool creation | | `cpswap_observation` | String | CPMM observation account (for TWAP) | | `lock_program` | String | LP lock program address | | `lock_authority` | String | LP lock authority | | `lock_lp_vault` | String | Vault holding locked LP tokens | | `authority` | String | Launchpad authority account | | `pool_state` | String | Launchpad pool state account | | `global_config` | String | Global configuration account | | `base_vault` | String | Launchpad base token vault | | `quote_vault` | String | Launchpad quote token vault | | `pool_lp_token` | String | Pool LP token account | ## meteora_swaps Meteora DLMM swaps with the bin range crossed and the full fee breakdown. **Partition key:** `block_date` **History:** 2026-05-18 → 2026-08-16 **Retention:** 90 days **Rows:** 75,434,658 · **Size:** 13.48 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `signing_wallet` | String | Wallet address that signed the transaction | | `base_coin` | String | Base token mint address | | `quote_coin` | String | Quote token mint address (usually SOL or USDC) | | `base_coin_amount` | UInt64 | Base token amount (raw units, needs decimal adjustment) | | `quote_coin_amount` | UInt64 | Quote token amount (raw units) | | `start_bin_id` | Int32 | Starting bin ID in the DLMM pool | | `end_bin_id` | Int32 | Ending bin ID after the swap | | `fee` | UInt64 | Transaction fee paid (lamports) | | `protocol_fee` | UInt64 | Protocol fee amount | | `fee_bps_low` | UInt64 | Lower bound of fee in basis points | | `fee_bps_high` | UInt64 | Upper bound of fee in basis points | | `host_fee` | UInt64 | Host/frontend fee amount | | `signature` | String | Transaction signature (base58 encoded) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee_paid` | UInt64 | Total fee paid | | `consumed_gas` | UInt64 | Compute units actually consumed | | `lb_pair` | String | Liquidity bin pair (pool) address | | `from_wallet` | String | Source wallet for the swap | | `swap_for_y` | UInt8 | Whether swapping for Y token (1=yes, 0=no) | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) *(populated since 2026-05-18)* | ## meteora_dynamic_bonding_swaps Meteora Dynamic Bonding Curve swaps, including slippage, routing amounts, and referral fields. **Partition key:** `block_date_utc` **History:** 2025-08-18 → 2026-08-16 **Retention:** 1 year **Rows:** 152,076,712 · **Size:** 41.81 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `swap_idx` | UInt16 | Swap index within the transaction | | `signature` | String | Transaction signature (base58 encoded) | | `fee_payer` | String | Wallet that paid the transaction fee | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `pool_id` | String | Pool account address | | `signer` | String | Wallet address that signed the transaction | | `direction` | LowCardinality(String) | Trade direction (buy/sell) | | `base_coin` | String | Base token mint address | | `quote_coin` | String | Quote token mint address (usually SOL or USDC) | | `base_coin_amount` | UInt64 | Base token amount (raw units, needs decimal adjustment) | | `quote_coin_amount` | UInt64 | Quote token amount (raw units) | | `base_coin_slippage` | Int64 | Slippage on base token (negative = less than expected) | | `quote_coin_slippage` | Int64 | Slippage on quote token (negative = less than expected) | | `parent_program` | String | Parent program that invoked this instruction (for CPI calls) | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | | `orig_base_coin_amount` | UInt64 | Original base amount before slippage | | `orig_quote_coin_amount` | UInt64 | Original quote amount before slippage | | `config` | String | Pool configuration account | | `trade_direction` | UInt64 | Numeric trade direction indicator | | `has_referral` | UInt8 | Whether trade included a referral (1=yes, 0=no) | | `swap_amount0` | String | First swap amount in the route | | `swap_amount1` | String | Second swap amount in the route | | `swap_mode` | UInt64 | Swap mode (exact in/out) | | `input_amount` | String | Input amount for the swap | | `output_amount` | String | Output amount from the swap | | `base_mint` | String | Base token mint address | | `quote_mint` | String | Quote token mint address | | `referral` | String | Referral account address (if any) | ## jito_tips Jito tip payments: who tipped, which tip account received it, how much. **Partition key:** `block_date_utc` **History:** 2026-08-02 → 2026-08-16 **Retention:** 14 days **Rows:** 135,442,770 · **Size:** 10.22 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `signature` | String | Transaction signature (base58 encoded) | | `signer` | String | Wallet address that signed the transaction | | `sender` | String | Wallet that sent the tip | | `tip_account` | String | Jito tip account that received the tip | | `amount` | UInt64 | Tip amount in lamports | ## token_transfers SPL and Token-2022 transfers. The transfer variant is encoded in `flavour`. **Partition key:** `block_date_utc` **History:** 2026-07-20 → 2026-08-16 **Retention:** 31 days **Rows:** 146,085,642 · **Size:** 22.57 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `failed` | UInt8 | Whether the transaction failed (1=yes, 0=no) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `cu_price_ix_index` | Int16 | Instruction index of the compute-unit price instruction | | `cu_limit_ix_index` | Int16 | Instruction index of the compute-unit limit instruction | | `num_signatures` | UInt8 | Number of signatures on the transaction | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | | `transaction_version` | Int8 | Transaction message version (-1=legacy, 0=v0, -2=unknown) | | `lookup_tables` | String | Pipe-delimited account addresses loaded through address lookup tables (writable first, then read-only) | | `signature` | String | Transaction signature (base58 encoded) | | `fee_payer` | String | Wallet that paid the transaction fee | | `mint` | String | Token mint address | | `src_wallet` | String | Source wallet address | | `dst_wallet` | String | Destination wallet address | | `amount` | UInt64 | Token amount transferred in raw base units (apply the mint's decimals for display) | | `flavour` | UInt8 | Transfer encoding: add 16 for Token-2022; base values are 0=Transfer, 1=TransferChecked, 2=TransferCheckedWithFee, and 3=SetAuthority owner change | | `ix_idx` | Int16 | Instruction index within the transaction | ## sol_top_ups Native SOL transfers. Use it to trace funding paths into a wallet. **Partition key:** `block_date_utc` **History:** 2026-07-20 → 2026-08-16 **Retention:** 31 days **Rows:** 173,385,646 · **Size:** 28.29 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `block_date_utc` | Date | UTC date of the block (for partitioning) | | `slot` | UInt32 | Solana slot number (block height) | | `tx_idx` | UInt16 | Transaction index within the block | | `failed` | UInt8 | Whether the transaction failed (1=yes, 0=no) | | `provided_gas_fee` | UInt64 | Gas fee provided for the transaction (lamports) | | `provided_gas_limit` | UInt64 | Compute unit limit requested | | `fee` | UInt64 | Transaction fee paid (lamports) | | `consumed_gas` | UInt64 | Compute units actually consumed | | `cu_price_ix_index` | Int16 | Instruction index of the compute-unit price instruction | | `cu_limit_ix_index` | Int16 | Instruction index of the compute-unit limit instruction | | `num_signatures` | UInt8 | Number of signatures on the transaction | | `top_level_transfers_json` | String | JSON array of top-level SOL/token transfers in the transaction | | `transaction_version` | Int8 | Transaction message version (-1=legacy, 0=v0, -2=unknown) | | `lookup_tables` | String | Pipe-delimited account addresses loaded through address lookup tables (writable first, then read-only) | | `signature` | String | Transaction signature (base58 encoded) | | `fee_payer` | String | Wallet that paid the transaction fee | | `src_wallet` | String | Source wallet address | | `dst_wallet` | String | Destination wallet address | | `amount` | UInt64 | Amount of SOL transferred, in lamports | ## solana_blocks Block-level index: hash, validator identity, rewards, and transaction count. **Partition key:** not partitioned **History:** full chain history → 2026-08-16 **Retention:** full history **Rows:** 184,679,641 · **Size:** 9.46 GB | Column | Type | Description | |---|---|---| | `block_time` | DateTime | UTC timestamp when the block was produced | | `slot` | UInt32 | Solana slot number (block height) | | `hash` | FixedString(48) | Block hash | | `validator` | FixedString(48) | Validator identity that produced the block | | `rewards` | UInt64 | Total rewards in the block (lamports) *(populated since 2024-11-02)* | | `amount_of_transactions` | UInt64 | Number of transactions in the block *(populated since 1969-12-31)* | ## tx_timestamps High-precision entry timestamp per transaction - the join target for latency work. See [Nanosecond timestamps](https://supanode.xyz/docs/solana/indexer/nanosecond-timestamp). **Partition key:** `toYYYYMMDD(toDateTime(entry_timestamp))` **History:** rolling window **Retention:** 14 days **Rows:** 2,744,043,346 · **Size:** 243.84 GB | Column | Type | Description | |---|---|---| | `slot` | UInt64 | Solana slot number (block height) | | `tx_idx` | UInt32 | Transaction index within the block | | `entry_timestamp` | Float64 | Entry timestamp (high-precision Unix timestamp) | | `signature` | String | Transaction signature (base58 encoded) | ## max_caps Precomputed peak market cap per mint, in SOL and USDC, with the slot at which it was reached. **Partition key:** not partitioned **History:** rolling window **Retention:** full history **Rows:** 9,353,726 · **Size:** 438.8 MB | Column | Type | Description | |---|---|---| | `token_mint` | String | Token mint address | | `max_mcap_sol` | SimpleAggregateFunction(max, Float32) | Maximum market cap reached (in SOL) | | `max_mcap_usdc` | SimpleAggregateFunction(max, Float32) | Maximum market cap reached (in USDC) | | `max_slot` | SimpleAggregateFunction(max, UInt32) | Slot when maximum market cap was reached | ## See also Shared columns, units, and the gotchas that bite first. Working SQL against these tables. Connection details and code samples. --- ## Query examples Source: https://supanode.xyz/docs/solana/indexer/examples > Working ClickHouse SQL against the Supanode Solana Indexer: launch cohorts, creator migration rates, PumpSwap fee reconciliation, aggregator routing splits, and sub-slot timing. Queries you can paste, each written against the live column names in the [Table reference](https://supanode.xyz/docs/solana/indexer/tables). **Every example is bounded.** Each one filters on a partition column or a recent time window before it touches anything else. Copy that habit - the swap tables are large enough that an unbounded scan is expensive for you and slow for everyone. ## Transfer and funding activity, hour by hour `token_transfers` and `sol_top_ups` are deliberately separate tables. To see both rhythms side by side, union their hourly counts rather than joining individual rows. ```sql WITH toStartOfHour(now()) AS end_hour, end_hour - INTERVAL 24 HOUR AS start_hour SELECT hour, sum(token_transfers) AS token_transfers, sum(sol_top_ups) AS sol_top_ups FROM ( SELECT toStartOfHour(block_time) AS hour, count() AS token_transfers, 0 AS sol_top_ups FROM token_transfers PREWHERE block_time >= start_hour AND block_time < end_hour GROUP BY hour UNION ALL SELECT toStartOfHour(block_time) AS hour, 0 AS token_transfers, count() AS sol_top_ups FROM sol_top_ups PREWHERE block_time >= start_hour AND block_time < end_hour GROUP BY hour ) GROUP BY hour ORDER BY hour ``` Both tables keep 31 days, so anchor any longer study to an export. ## Most active Pump.fun creators in the last 24 hours `pumpfun_token_creation` stores `creator` and `mint` as `FixedString(48)`, so strip the null padding before grouping. ```sql SELECT replaceAll(toString(creator), '\0', '') AS creator, count() AS launches, sum(bundled_buys) / 1e9 AS bundled_buys_sol, max(bundle_size) AS biggest_bundle FROM pumpfun_token_creation WHERE block_time >= now() - INTERVAL 1 DAY GROUP BY creator HAVING launches >= 5 ORDER BY launches DESC LIMIT 25 ``` `bundled_buys` is in lamports, hence the `/ 1e9`. ## Creator migration rate How often does a creator's launch actually graduate to the PumpSwap AMM? Anchor the window to the newest data in the table rather than to the wall clock, so the result stays reproducible. ```sql WITH (SELECT max(block_time) FROM pumpfun_token_creation) AS data_end, data_end - INTERVAL 30 DAY AS data_start SELECT c.creator AS creator, count() AS tokens, countIf(m.mint != '') AS migrated, round(100 * countIf(m.mint != '') / count(), 2) AS migrated_pct, min(c.block_time) AS first_launch, max(c.block_time) AS last_launch FROM ( SELECT replaceAll(toString(creator), '\0', '') AS creator, replaceAll(toString(mint), '\0', '') AS mint, block_time FROM pumpfun_token_creation WHERE block_time >= data_start AND block_time <= data_end ) AS c LEFT JOIN ( SELECT DISTINCT mint FROM pfamm_migrations WHERE block_date_utc >= toDate(data_start) ) AS m ON c.mint = m.mint GROUP BY creator HAVING tokens >= 5 ORDER BY migrated_pct DESC, tokens DESC LIMIT 50 ``` ## PumpSwap fee and reserve reconciliation `pumpswap_all_swaps` exposes pool reserves before and after the swap alongside every fee component, so the accounting can be checked rather than assumed. ```sql SELECT signature, direction, base_token_amount, quote_token_amount, -- reserve movement should equal the traded amounts abs(toInt128(pool_base_token_reserves_after) - toInt128(pool_base_token_reserves_before)) = base_token_amount AS base_reserves_ok, abs(toInt128(pool_quote_token_reserves_after) - toInt128(pool_quote_token_reserves_before)) = quote_token_amount AS quote_reserves_ok, lp_fee, protocol_fee, coin_creator_fees, cash_back_fees, buy_back_fees, quote_token_amount_without_lp_fee, is_exact_quote FROM pumpswap_all_swaps PREWHERE block_date_utc = today() ORDER BY slot DESC, tx_idx DESC LIMIT 25 ``` The creator, cashback, buyback and virtual-reserve fields are populated from 23 July 2026 onward; before that date they hold zeros. ## Top wallets by PumpSwap SOL volume today ```sql SELECT signing_wallet, count() AS swaps, sum(quote_token_amount) / 1e9 AS volume_sol, countIf(direction = 'buy') AS buys, countIf(direction = 'sell') AS sells FROM pumpswap_all_swaps PREWHERE block_date_utc = today() WHERE quote_token = 'So11111111111111111111111111111111111111112' GROUP BY signing_wallet ORDER BY volume_sol DESC LIMIT 20 ``` ## Organic flow versus routed flow `parent_program` records the program that invoked the swap through CPI. An empty value means the DEX was called directly; anything else is an aggregator, bot, or router. ```sql SELECT if(parent_program = '', 'direct', parent_program) AS router, count() AS swaps, sum(quote_token_amount) / 1e9 AS volume_sol, round(100 * count() / sum(count()) OVER (), 2) AS share_pct FROM pumpswap_all_swaps PREWHERE block_date_utc = today() WHERE quote_token = 'So11111111111111111111111111111111111111112' GROUP BY router ORDER BY swaps DESC LIMIT 20 ``` ## Jito tip spend by wallet ```sql SELECT sender, count() AS tips, sum(amount)/1e9 AS tipped_sol, max(amount)/1e9 AS biggest_tip_sol FROM jito_tips PREWHERE block_date_utc >= today() - 6 GROUP BY sender ORDER BY tipped_sol DESC LIMIT 25 ``` `jito_tips` keeps 14 days, so a week is a safe window. ## Sub-slot timing `tx_timestamps` holds a high-precision entry timestamp per transaction. Join it on `(slot, tx_idx)` to place swaps inside a slot instead of at block granularity. ```sql SELECT s.slot AS slot, count() AS swaps, min(t.entry_timestamp) AS first_entry, max(t.entry_timestamp) AS last_entry, round((max(t.entry_timestamp) - min(t.entry_timestamp)) * 1000, 3) AS spread_ms FROM pumpfun_v2_swaps AS s INNER JOIN tx_timestamps AS t ON s.slot = t.slot AND s.tx_idx = t.tx_idx PREWHERE s.block_date_utc = today() GROUP BY slot HAVING swaps > 10 ORDER BY spread_ms DESC LIMIT 20 ``` **`tx_timestamps` keeps 14 days.** Any latency study reaching further back needs an export arranged in advance - see [Nanosecond timestamps](https://supanode.xyz/docs/solana/indexer/nanosecond-timestamp). ## Failed transactions on Pump.fun v2 `pumpfun_v2_swaps` is the only swap table that retains failed transactions, and `failed` is part of its partition key - so filtering on it is free. ```sql SELECT toStartOfHour(block_time) AS hour, countIf(failed = 1) AS failed_swaps, countIf(failed = 0) AS landed_swaps, round(100 * countIf(failed = 1) / count(), 2) AS fail_pct FROM pumpfun_v2_swaps PREWHERE block_date_utc >= today() - 1 GROUP BY hour ORDER BY hour ``` ## Need a query written for you? Recurring queries can be deployed as a stable REST endpoint, and heavier batch work as a scheduled Python ETL flow - both quoted per scope on top of the base plan. See [Access](https://supanode.xyz/docs/solana/indexer/access#custom-rest-api) or message [@supanode_tgs](https://telegram.me/supanode_tgs). ## See also Every column these queries use. Padding, units, partitions, retention. Connect from Node, Python, or Go. --- ## Nanosecond timestamps Source: https://supanode.xyz/docs/solana/indexer/nanosecond-timestamp > Sub-slot transaction timing via the tx_timestamps table: high-precision entry timestamps captured at our Amsterdam shred receiver, for MEV and microstructure analysis. Block-level data tells you which slot a transaction landed in. `tx_timestamps` tells you *when inside that slot* - captured the instant the transaction's shred reached our Amsterdam receiver. **When this matters:** MEV analysis, market-microstructure research, comparing on-chain execution against centralized-exchange fills, transaction-propagation studies. If you are working in milliseconds, block-level timing is too coarse. ## The problem with block-level timing Solana blocks reveal transaction sequence within a block through `tx_idx`, but not the timing behind it. Trading and MEV happen on millisecond timescales while blocks arrive roughly every 400 ms, so standard block data hides everything that matters about latency. ## Where the timing lives Timing is not a column on the swap tables - it is a separate table you join. | | | |---|---| | Table | `tx_timestamps` | | Rows | 2.74 billion (16 Aug 2026 snapshot) | | Join key | `(slot, tx_idx)`, or `signature` | | Timing column | `entry_timestamp` - `Float64`, high-precision Unix timestamp | | Partition key | `toYYYYMMDD(toDateTime(entry_timestamp))` | | Retention | **14 days** | **Fourteen days, then it is gone.** `tx_timestamps` is the shortest-retention table in the database. Any latency study reaching further back has to be exported while the window is still open - arrange it with [@supanode_tgs](https://telegram.me/supanode_tgs) before you start collecting. ## What the timestamp means `entry_timestamp` is the moment the transaction's shred **arrived at our receiver**, not the moment the transaction was created and not the moment the block was finalized. - **The reference point is Amsterdam.** If your application or exchange runs elsewhere, factor in the geographic offset. - **Nanosecond resolution, not nanosecond accuracy.** The clock has nanosecond precision, but real-world variance is at the microsecond level - still far finer than block-time granularity. - **Coverage follows the shred feed.** A transaction only appears here if its shred reached the receiver, so treat a missing join as "not observed", not as "did not happen". ## How it is captured A lock-free path on the Amsterdam shred receiver: The primary thread monitors Geyser entry streams and records timestamps with **zero contention** - no locks and no buffering between detecting a transaction and stamping it. A dedicated worker pool handles slot correlation and database writes concurrently in the background. Splitting the two keeps stamp accuracy at its maximum - nothing competes with the timestamp path - while persistence is decoupled from it. ## Joining it to a swap table ```sql SELECT s.signature, s.slot, s.tx_idx, s.direction, s.quote_token_amount / 1e9 AS sol_amount, t.entry_timestamp FROM pumpswap_all_swaps AS s INNER JOIN tx_timestamps AS t ON s.slot = t.slot AND s.tx_idx = t.tx_idx PREWHERE s.block_date_utc = today() ORDER BY t.entry_timestamp DESC LIMIT 50 ``` ## Arrival spread inside a slot Transactions that share a slot did not arrive together. This measures how far apart they actually were: ```sql SELECT s.slot AS slot, count() AS tx_count, min(t.entry_timestamp) AS first_entry, max(t.entry_timestamp) AS last_entry, round((max(t.entry_timestamp) - min(t.entry_timestamp)) * 1000, 3) AS spread_ms FROM pumpfun_v2_swaps AS s INNER JOIN tx_timestamps AS t ON s.slot = t.slot AND s.tx_idx = t.tx_idx PREWHERE s.block_date_utc = today() GROUP BY slot HAVING tx_count > 10 ORDER BY spread_ms DESC LIMIT 20 ``` ## Use cases Match arrival time to off-chain quote timestamps and compare on-chain execution with exchange fills. Distance between transaction creation in your logs and arrival at our receiver. Correlate `entry_timestamp` with `slot` and `tx_idx` to map how transactions spread. Build on real arrival timing instead of block-level approximations. ## See also `tx_timestamps` and every table you can join it to. More bounded SQL patterns. The same upstream feed, delivered raw over UDP. --- ## Raw Shreds Source: https://supanode.xyz/docs/solana/shreds/raw > Top-of-Turbine shred feed delivered to your host over UDP. Sub-second block data without RPC or gRPC overhead. Top-of-Turbine shred feed delivered to your host over UDP. Process block data the moment it propagates - no RPC, no gRPC. **B2B only.** Raw Shreds is sold to businesses and infrastructure teams. Reselling or redistributing the feed requires a separate B2B agreement - contact us first. ## What it is A direct UDP stream of Solana shreds from the Turbine network to your infrastructure. Shreds are the raw block fragments that validators distribute - by reading them at the source, you avoid the latency of RPC indexing or gRPC re-emission. ## Use cases | Application | Benefit | |---|---| | **Custom indexers** | Build your own data store with minimal delay | | **Trading systems** | Process block data the moment it propagates | | **Private clusters** | Feed shreds into your own validator infrastructure | | **Analytics pipelines** | Real-time block analysis without RPC overhead | ## How it works ``` Turbine network → Supanode validators → Shredstream → Your infrastructure │ └── high-stake validators on the Solana network ``` Supanode pulls from validators with significant stake on the Solana network. This keeps the feed reliable as shreds propagate. Your host receives raw shreds via UDP on the port you specify. ## Region and pricing Available in **Frankfurt (FRA)** at \$200/mo per IP. Additional regions on the roadmap. | Region | Code | Price | |---|---|---| | Frankfurt | FRA | \$200/mo | Rented per IP. **7 days minimum, 90 days maximum** per subscription. **One destination IP per subscription.** Shreds are sent to a single IP address. Unlike the Bundle products, a shred subscription cannot fan out to several receivers — each additional IP is a separate \$200/mo subscription. Tell us the exact IP and port when you provision. **Several receivers or enterprise terms?** Contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs) — we price additional IPs per subscription. ## Free trial **Up to 24-hour free trial** to validate the feed in your environment. Activate by contacting us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). For details, see [Free Trials](https://supanode.xyz/docs/solana/pricing/free-trials). ## Getting started Contact us on Telegram with the IP address that will receive shreds. Set up your infrastructure to receive UDP shred packets on the designated port. Verify shreds are arriving and being processed correctly. Confirm your subscription. Need shreds on more than one host? Each IP is its own subscription — ask us for terms. ## Reselling policy **Unauthorized reselling is prohibited.** Reselling Raw Shreds requires a B2B agreement signed in advance. Unauthorized reselling may result in subscription suspension without refund - resolution is via switching to a B2B agreement. ## Technical details - **Protocol:** raw UDP multicast - **Data format:** native Solana shred format, no filters - **Source:** validators with significant stake on the Solana network - **Latency:** 0.4ms p99 delivery from Supanode's shred receiver - **Region:** Frankfurt (FRA) - **Authentication:** none from your side - Supanode pushes only to the destination IP you register - **Destination:** exactly one IP per subscription - shreds are not fanned out to multiple hosts ## Where to next Same data decoded and exposed via Yellowstone gRPC. Coming in v1.1. Standard real-time streaming. Full blocks via gRPC. All trial windows in one place. ## Support Contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Decoded Shreds Source: https://supanode.xyz/docs/solana/shreds/decoded > Decoded raw shreds delivered via the standard Yellowstone gRPC interface. Coming in v1.1. **Status:** coming soon. Decoded Shreds is on the v1.1 roadmap and is not part of v1.0. Decoded Shreds (also known as **aRPC**) wraps raw Solana shreds in the standard Yellowstone gRPC protocol, so you get shred-level latency with familiar gRPC tooling. ## What it is Raw shreds give you Solana data faster than RPC or gRPC, but processing UDP packets directly is awkward. Decoded Shreds removes that friction: - Supanode receives shreds at the network edge (Shred Caster on XDP). - Supanode decodes them into transaction-level events. - Supanode exposes the events through the standard Yellowstone gRPC stream. You get the latency advantage of [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw) with the integration simplicity of [gRPC](https://supanode.xyz/docs/solana/grpc/overview). ## When should you use Decoded Shreds vs Raw Shreds vs gRPC? | You need... | Use this | |---|---| | Lowest possible latency, raw UDP, you handle decoding | [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw) | | Lower latency than gRPC, but standard gRPC integration | **Decoded Shreds** | | Standard real-time streams (most cases) | [gRPC](https://supanode.xyz/docs/solana/grpc/overview) | **Available today:** for shred-level latency right now, use [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw) (UDP, Frankfurt). For standard streaming with rich filters, use [gRPC](https://supanode.xyz/docs/solana/grpc/overview). ## Pricing Pricing is in finalization. Will land alongside the v1.1 release. ## Want early access? To get on the early-access list, contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). ## Where to next UDP shredstream, available now in Frankfurt. Standard real-time streaming. Full blocks via gRPC. Reach us on Telegram for early access. --- ## Dedicated Node Source: https://supanode.xyz/docs/solana/dedicated/node > Your own Solana RPC node with guaranteed resources. Custom quote — priced per deployment, on request. Your own Solana RPC node with guaranteed resources on dedicated hardware. The full node capacity is yours. Tailored per request. **The full node capacity is yours.** Whatever the hardware can do, you get - rate limits and capacity are set by your node alone. Priced by custom quote, configured per request - on request, sized to your hardware. ## At a glance | | | |---|---| | **Price** | custom quote — priced per deployment, on request | | **Billing** | monthly, pay in USDC, USDT, SOL, or ETH | | **Quote turnaround** | within 24 hours | | **Setup** | ~48 hours to deploy | | **Hardware** | bare-metal (not virtualized) | | **Region** | per request - tell us where you need it | | **Yellowstone gRPC** | available as add-on | | **Rate limits** | full node capacity is yours - bounded only by the hardware | | **Support** | 24/7 direct Telegram channel | ## What's included - **Full node capacity.** RPS, TPS, and connections run to whatever the hardware can do - the throughput ceiling is the box itself. - **Bare-metal hardware.** Not virtualized. Predictable performance under load. - **Region by request.** Shared infrastructure runs from Frankfurt; a dedicated node deploys in 10+ locations on request - tell us where you need it. - **Yellowstone gRPC add-on.** Stream blockchain data from your dedicated node directly. All gRPC programs and filter sizes are available, bounded by the hardware. - **24/7 support.** Direct Telegram channel with Supanode's engineering team. ## When should you use Dedicated vs shared plans? | Workload | Recommendation | |---|---| | Single trading bot, modest scale | [BUILD / GROW / PROFESSIONAL](https://supanode.xyz/docs/solana/pricing/plans) shared plan | | Subscription to Token / Token-2022 / System program via gRPC | **Dedicated Node** (these are blocked on shared) | | Replay (`from_slot`) on gRPC | **Dedicated Node** (not supported on shared) | | Heavy `getProgramAccounts` polling | **Dedicated Node** (or switch to gRPC subscriptions) | | Multiple bots / team / market making | **Dedicated Node** if PROFESSIONAL isn't enough | ## What Dedicated unlocks - **All gRPC programs.** Subscribe to Token, Token-2022, System, ComputeBudget, and ATA - the programs shared plans restrict are open here. - **All WebSocket subscriptions.** `blockSubscribe`, `voteSubscribe`, and `programSubscribe` without a filter all run on Dedicated. - **Filter sizes to the hardware ceiling.** Every gRPC filter size scales as far as the hardware allows. - **RPS / TPS to the hardware ceiling.** Throughput is bounded by your node alone. For details on what's restricted on shared, see [What's not allowed](https://supanode.xyz/docs/solana/pricing/restrictions). ## How much does a Dedicated Node cost? **Custom quote, no list price.** Pricing is per deployment, on request - custom hardware, multi-node setups, and higher SLA tiers all factor in, so Supanode quotes based on your needs. Supanode comes back with a quote within **24 hours**. Pay in USDC, USDT, SOL, or ETH. Monthly billing, no annual lock-in required. ## How to get one Reach out at [@supanode_tgs](https://telegram.me/supanode_tgs) to start the conversation. Region or geography, workload type (RPC-heavy, gRPC-heavy, or mixed), whether you need the Yellowstone gRPC add-on, and whether it's single or multi-node. Supanode comes back with a concrete proposal within **24 hours**. After agreement, deployment takes **~48 hours**. ## Is there a free trial? **Dedicated runs on a quote, not a trial.** Nodes are built per order — validate your workload on the shared products' up-to-24-hour trials first, then size the dedicated build when you reach out on Telegram. ## Where to next Fully custom hardware beyond a Solana RPC node. Shared-plan alternatives. What's blocked on shared but works on Dedicated. Reach us on Telegram for a quote. ## Support Contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Bare Metal Hosting Source: https://supanode.xyz/docs/solana/dedicated/bare-metal > Custom Solana infrastructure built to your specs. Hardware, region, and configuration on request. Custom Solana infrastructure built to your specs. Supanode provides bare-metal hardware, in your choice of region, configured for your workload. **Custom quote only.** Every order is configured per request - hardware spec, region, term, and SLA all factor in. Reach out on Telegram [@supanode_tgs](https://telegram.me/supanode_tgs) and Supanode will come back with pricing within 1-2 business days. ## What is Bare Metal Hosting? A managed bare-metal hosting service for serious Solana infrastructure needs. Supanode handles hardware procurement, datacenter placement, network setup, and ongoing operations - you specify what you need. ## When to use this | You need... | Bare Metal Hosting fits | |---|---| | Dedicated hardware for an internal RPC or validator | yes | | Specific CPU / RAM / NVMe profile not covered by [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) | yes | | Multiple servers in a region for a custom cluster | yes | | Geographically distributed nodes | yes | | Co-location near validator clusters | yes | ## How does it work? Hardware spec, region, networking requirements, growth plans. Pricing depends on hardware, region, term, and SLA. Supanode comes back with a concrete proposal within 1-2 business days. Provisioning takes up to 5 days from agreement - servers are delivered and configured per order, not held in stock. Full root access. Supanode handles hardware operations, you handle the software. ## What does Supanode provide? - Bare-metal hardware (not virtualized). - Choice of region - Supanode deploys dedicated hardware in 10+ locations on request. - Network setup, firewall rules, and bandwidth provisioning. - Hardware operations (replacement, upgrades, monitoring). - 24/7 support via direct Telegram channel. ## How does pricing work? Custom. Depends on: - **Hardware spec** - CPU model, RAM, storage configuration. - **Region** - some locations cost more. - **Term** - longer commitments unlock better rates. - **SLA** - bandwidth guarantees, replacement times. **Want a baseline?** Supanode's [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) is priced by custom quote (per deployment, on request). Bare-metal hosting is typically similar in scale or larger. ## How to inquire Reach out at [@supanode_tgs](https://telegram.me/supanode_tgs). Workload (RPC, validator, indexer, custom), region, hardware spec or performance target, number of servers, and term (monthly, quarterly, annual). Supanode comes back within **1-2 business days**. After agreement, provisioning takes **up to 5 days**. ## Where to next Turnkey Solana RPC node, fixed pricing. Decoded DEX data instead of raw infrastructure. Shared-plan alternatives. Reach us on Telegram for a quote. ## Support Contact us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Plans Source: https://supanode.xyz/docs/solana/pricing/plans > Five Bundle plans - STARTER, FOCUS, BUILD, GROW, PROFESSIONAL - from $40 to $459 per 30 days. Fixed pricing, no compute units, free trial on every plan. 5 fixed Bundle plans. Free trial on every one. **No credits, no compute units.** Pay for RPS, get unlimited usage in your plan. No CU balance, no surprise overages. Unlimited bandwidth on every tier. ## The 5 Bundle plans \$40 / 30 days. RPC + WebSocket. No gRPC. \$99 / 30 days. Adds gRPC (1 connection). Best $/req. \$159 / 30 days. gRPC 10 connections, 200 RPS. \$259 / 30 days. gRPC 20 connections, 300 RPS. UDP ShredStream included. \$459 / 30 days. gRPC 50 connections, 500 RPS. **Duration is flexible.** Prices are for a full 30-day period. You pick any duration from **1 hour to 30 days** - shorter periods are pro-rated. Test a plan for an hour before committing for a month. ## All plans at a glance | | **STARTER** | **FOCUS** | **BUILD** | **GROW** | **PROFESSIONAL** | |---|---|---|---|---|---| | **Price (30 days)** | \$40 | \$99 | \$159 | \$259 | \$459 | | **RPC** | yes | yes | yes | yes | yes | | **WebSocket** | yes (10) | yes (20) | yes (30) | yes (40) | yes (70) | | **gRPC** | no | yes (1 subscription) | yes (10 subscriptions) | yes (20 subscriptions) | yes (50 subscriptions) | | **gRPC max accounts watched** | — | up to 100 | up to 5,000 | up to 24,000 | up to 100,000 | | **gRPC unfiltered full blocks** | — | — | — | — | included | | **RPS** | 15 | 25 | 200 | 300 | 500 | | **TPS** | 5 | 10 | 30 | 50 | 100 | | **UDP ShredStream** | — | — | — | included (FRA) | FRA | | **Bandwidth** | unlimited | unlimited | unlimited | unlimited | unlimited | | **Location** | FRA | FRA | FRA | FRA | FRA | | **Support** | Community | Community | Telegram | Priority TG | Priority TG | FOCUS is the best $/request entry tier; GROW is Supanode's most popular pick (it is the first tier with UDP ShredStream). PROFESSIONAL is the maxed-out shared tier. ## Which plan should you choose? | Your situation | Plan | |---|---| | Browser app, dashboard, or any read-mostly workload that lives on WebSocket. No need for gRPC. | **STARTER** | | One trading bot, one strategy. You need gRPC at the best price per request. | **FOCUS** | | Production trading workload, multiple strategies, gRPC is your main interface. | **BUILD** | | Multiple bots or a small team. You want UDP ShredStream included. | **GROW** | | High-throughput operation - market maker, full-state indexer, MEV. | **PROFESSIONAL** | ## Specialized products (priced separately) These products are billed independently from the Bundle plans above. | Product | Price | |---|---| | [Unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming) | Included in the PROFESSIONAL Bundle (not a paid add-on) | | [Shreds UDP](https://supanode.xyz/docs/solana/shreds/raw) | \$200/mo, raw UDP multicast, Frankfurt | | [Indexer](https://supanode.xyz/docs/solana/indexer/overview) | \$300/mo | | [Sender](https://supanode.xyz/docs/solana/sender/overview) | pay-per-use, no monthly fee (minimum tip 0.001 SOL / 1,000,000 lamports) | | [Decoded Shreds](https://supanode.xyz/docs/solana/shreds/decoded) | TBD - coming soon | | [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) | custom quote — priced per deployment, on request | | [Bare Metal Hosting](https://supanode.xyz/docs/solana/dedicated/bare-metal) | custom quote | Specialized products use the same duration slider as Bundle (1 hour to 30 days) where applicable. Sender is pay-per-use with no subscription. Dedicated is not trial-eligible. ## Is there a free trial? Every Bundle plan has a free trial of up to 24 hours. Activate via Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). The Dedicated Node is not trial-eligible. For details, see [Free Trials](https://supanode.xyz/docs/solana/pricing/free-trials). ## Can I get a custom plan? **Nothing fits your case?** Supanode tailors custom plans on request - no upcharge for the conversation itself. Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). ## Next steps RPS, TPS, duration slider, upgrade math. Every limit on one page. Programs and methods blocked on shared. 24-hour trials on every plan. --- ## How pricing works Source: https://supanode.xyz/docs/solana/pricing/how-it-works > How Supanode billing works: 1-hour to 30-day duration slider, shared RPS budget, plan upgrade math, and the total WebSocket subscriptions cap. Plain-English explanation of how your bill is calculated. **No credits, no compute units.** You pay a flat monthly price equivalent and get unlimited usage within your RPS limit. No CU, no credit balance, no surprise overage charges. ## Duration: 1 hour to 30 days Bundle prices on [Plans](https://supanode.xyz/docs/solana/pricing/plans) are for a full 30-day period. You pick **any duration from 1 hour to 30 days** when provisioning a subscription over Telegram. The bill is pro-rated against that 30-day price. This means: - Try a plan for an hour to validate latency before committing. - Run high-traffic days at PROFESSIONAL, slow weeks at BUILD. - No annual commitment, no monthly minimum beyond 1 hour. For [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw) the slider is **7 days minimum, 90 days maximum** - that one is rented per IP and we need a meaningful window for setup. ## What do RPS and TPS mean? - **RPS** - requests per second. Counts every RPC call, WebSocket subscribe/unsubscribe, and gRPC `SubscribeRequest` update. - **TPS** - transactions per second. Counts `sendTransaction` calls separately. Method weights matter - some calls cost more than 1 RPS unit each. See [RPC Limits](https://supanode.xyz/docs/solana/rpc/limits) for the table. ### 10-second sliding window Your RPS limit is averaged, not a hard per-second wall. Supanode aggregates over a **10-second sliding window** so brief bursts stay within plan as long as your average does. This matters for trading workloads with uneven traffic. ## How does the total WS subs cap work? Three independent WebSocket numbers in your plan: 1. **Concurrent connections** - how many TCP sockets you can hold open. 2. **Subs per connection** - how many subscriptions you can make on each socket. 3. **Total subs per plan** - your overall subscription budget. **Total subs is a separate hard cap, not connections × subs/conn.** Whichever runs out first wins. Example on GROW (\$259 for 30 days): - 40 connections allowed × 500 subs per connection = 20,000 *theoretical* maximum. - But Total subs cap = **10,000**. - So you can't fill all 40 connections with 500 subs each. You need to distribute 10,000 subs across your connections. This is a deliberate anti-abuse design - it stops one user from claiming the entire WS capacity. ## Can you upgrade in the middle of a period? You can upgrade tiers mid-period (STARTER → FOCUS, BUILD → GROW, etc.) and pay only the **difference for the remaining days** at the new tier. ### Formula ``` days_remaining = (expires_at − now) in days total_days = (expires_at − period_start) in days paid_for_remaining = paid_amount × (days_remaining / total_days) new_price_for_remaining = new_tier_daily_price × days_remaining upgrade_price = new_price_for_remaining − paid_for_remaining ``` ### Worked example You're on BUILD (\$159 for 30 days). You bought 30 days, 18 have passed, 12 left. You want GROW (\$259 for 30 days). - You've already paid for the remaining 12 days at the BUILD rate: \$159 × (12/30) = **\$63.60**. - 12 days at GROW rate: \$259 × (12/30) = **\$103.60**. - You pay: \$103.60 − \$63.60 = **\$40**. Your subscription's `expires_at` doesn't change - the tier upgrades, the period stays the same. You can also upgrade between a no-gRPC tier (STARTER) and a gRPC tier (FOCUS+) the same way. ## Renewal Renewal is a repeat purchase of the same product. - **Subscription still active:** the new period **adds to the end** of the current one (5 days left + buy 30 = 35 total). - **Subscription already expired:** buying again reactivates it from now. ## When subscriptions expire **Hard cut at expiration.** A cron job runs every 5 minutes and removes access on expired subscriptions: - IP whitelist entries are removed. - Indexer x-token is deactivated. - Raw Shreds destination is removed from the push list. Access stops within ~5 minutes of `expires_at`. Buy again to reactivate. ## How does payment work? Payment is **crypto, prepaid** — arranged over Telegram when Supanode provisions your access. Provisioning runs through Telegram in v1. **Crypto only.** USDC, USDT, SOL, or ETH. No cards, no fiat. Message [@supanode_tgs](https://telegram.me/supanode_tgs) with the product and duration. Supanode sends a wallet address and the amount due. Send from your wallet. On confirmation Supanode issues your token, or sets up the destination for Shreds — you're live. ## What's included with every plan - **WebSocket** - included with RPC, no extra charge. - **All commitment levels** - processed, confirmed, finalized. - **All standard methods** that aren't on the [restrictions list](https://supanode.xyz/docs/solana/pricing/restrictions). ## What's priced separately - [Shreds UDP](https://supanode.xyz/docs/solana/shreds/raw) - \$200/mo, separate subscription. - [Indexer](https://supanode.xyz/docs/solana/indexer/overview) - \$300/mo, separate subscription. - [Sender](https://supanode.xyz/docs/solana/sender/overview) - pay-per-use (tip), no monthly fee. - [Decoded Shreds](https://supanode.xyz/docs/solana/shreds/decoded) - coming soon. - [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node) and [Bare Metal Hosting](https://supanode.xyz/docs/solana/dedicated/bare-metal) - custom quote. ## How do refunds work? **Refunds are manual.** Contact [@supanode_tgs](https://telegram.me/supanode_tgs) - Supanode reviews each one case by case. ## Next steps All 5 Bundle plans and add-ons. RPS, TPS, WS, gRPC numbers in one place. 24-hour trials on every plan. Token auth and per-product authorization. --- ## All limits at a glance Source: https://supanode.xyz/docs/solana/pricing/limits > RPS, TPS, WebSocket connections, and gRPC limits across STARTER, FOCUS, BUILD, GROW, PROFESSIONAL, and Dedicated, in one place. Every limit, organized per product. **What "limits" means here.** The numbers below are RPS (requests per second), TPS (transactions per second), connection caps, subscription caps, and filter caps. All RPS limits use a 10-second sliding window - brief spikes that average within plan won't be rate-limited. ## RPC | Limit | STARTER | FOCUS | BUILD | GROW | PROFESSIONAL | Dedicated | |---|---|---|---|---|---|---| | RPS | 15 | 25 | 200 | 300 | 500 | unlimited | | TPS | 5 | 10 | 30 | 50 | 100 | unlimited | RPS is shared between RPC, WebSocket subscribe/unsubscribe, and gRPC `SubscribeRequest` updates. See [RPC Limits](https://supanode.xyz/docs/solana/rpc/limits) for method weights (some calls cost more than 1 RPS unit). ## WebSocket | Limit | STARTER | FOCUS | BUILD | GROW | PROFESSIONAL | Dedicated | |---|---|---|---|---|---|---| | Concurrent WS connections | 10 | 20 | 30 | 40 | 70 | unlimited | | Subs per connection | 100 | 100 | 100 | 500 | 1,000 | unlimited | | Total subs per plan | 1,000 | 5,000 | 5,000 | 10,000 | 25,000 | unlimited | **Total subs is a hard cap, not connections × subs/conn.** Whichever runs out first wins. See [How pricing works](https://supanode.xyz/docs/solana/pricing/how-it-works#how-total-ws-subs-works). For details: [WebSocket Limits](https://supanode.xyz/docs/solana/websocket/limits). ## gRPC What scales by plan is how many subscriptions you can hold at once, how many addresses you can watch in total, and how many owner programs. Separately, the node caps every filter at 2 000 addresses and every subscription at 10 filters, on every tier - so a large address budget has to be spread across several subscriptions. Throughput is **unlimited and unmetered** on every gRPC tier. | Limit | FOCUS | BUILD | GROW | PROFESSIONAL | Dedicated | |---|---|---|---|---|---| | gRPC access | yes | yes | yes | yes | yes | | Concurrent gRPC subscriptions | 1 | 10 | 20 | 50 | unlimited | | Addresses per filter (node cap) | 2 000 | 2 000 | 2 000 | 2 000 | 2 000 | | Filters per subscription (node cap) | 10 | 10 | 10 | 10 | 10 | | Owner programs per stream (`owner_max`) | not available | 5 | 20 | 50 | unlimited | | Max accounts watched (across all streams) | up to 100 | up to 5,000 | up to 24,000 | up to 100,000 | unlimited | | Filter updates | 30 / min | 30 / min | 30 / min | 30 / min | unlimited | | Unfiltered full blocks | — | — | — | included | included | | Location | FRA | FRA | FRA | FRA | your region | | Throughput | unlimited | unlimited | unlimited | unlimited | unlimited | **The STARTER plan does not include gRPC.** FOCUS is the entry tier for gRPC. The two node caps are the same on every tier and set the shape of a request: one subscription holds at most 10 × 2 000 = 20 000 addresses. For the layout that spends each plan's budget, and for how to tell a plan error from a node error, see [gRPC Limits](https://supanode.xyz/docs/solana/grpc/limits). ## Sender | Limit | Value | |---|---| | TPS | 5 | | Minimum tip per transaction | 1,000,000 lamports (0.001 SOL) | See [Sender Tips](https://supanode.xyz/docs/solana/sender/tips) for tip addresses and code samples. ## Raw Shreds | Limit | Value | |---|---| | Region | Frankfurt only | | Destination IPs | 1 per subscription (no multi-IP fan-out) | | Minimum subscription | 7 days | | Maximum subscription | 90 days | See [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw). ## Indexer | Limit | Value | |---|---| | Tables / columns | 21 / 463 | | History coverage | deepest table from 17 January 2024 | | Retention | per table: 14 days to full history | | Validation latency | ~15 seconds | | Query volume | unlimited within reason | Retention differs per table - `tx_timestamps` and `jito_tips` hold 14 days, the Pump.fun core holds its full history. See [Schema conventions](https://supanode.xyz/docs/solana/indexer/database-schema#retention) for the full breakdown, or [Indexer](https://supanode.xyz/docs/solana/indexer/overview) for the product. ## What happens when you hit a limit? - **RPS / TPS exceeded:** standard `429` (HTTP) or `RESOURCE_EXHAUSTED` (gRPC). - **Connection cap exceeded:** new connection rejected. - **Subscription / filter cap exceeded:** that subscribe call rejected, existing subscriptions keep working. ## Per-product limits pages Method weights and per-method costs. Connection, sub, and total-cap detail. Per-stream filter caps and connections. ## Next steps All 5 Bundle plans. The 10-second window, upgrade math. Programs and methods blocked on shared. 24-hour trials on every plan. --- ## What's not allowed Source: https://supanode.xyz/docs/solana/pricing/restrictions > Programs, methods, and use cases blocked on shared plans, with workarounds. Honest, complete list of what shared plans don't support - and what to use instead. Restrictions are validated by Supanode engineering for v1, pending final sign-off before public launch. ## gRPC: blocked programs The programs below cannot be used in `accounts.owner` or `transactions.account_include` on shared plans (FOCUS, BUILD, GROW, PROFESSIONAL). They generate too much traffic to serve reliably on shared infrastructure. Available on [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node). | Program | Address | |---|---| | Token Program | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | | Token-2022 | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | | System Program | `11111111111111111111111111111111` | | Compute Budget | `ComputeBudget111111111111111111111111111111` | | Associated Token Account | `ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL` | For details and reasoning per program, see [gRPC Restrictions](https://supanode.xyz/docs/solana/grpc/restrictions). ## gRPC: other constraints - **Replay (`from_slot`)** - shared plans only stream forward. Historical replay needs Dedicated. - **Unfiltered block streaming** - `blocks` with empty `account_include` is included in the PROFESSIONAL tier. See [Unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming). ## WebSocket: blocked subscriptions | Subscription | Reason | |---|---| | `blockSubscribe` | Full block payloads - too heavy for shared infrastructure | | `voteSubscribe` | Validator vote firehose | | `slotsUpdatesSubscribe` | Sub-step slot updates | | `logsSubscribe("all")` and `logsSubscribe("allWithVotes")` | All logs of all transactions | | `programSubscribe` without `dataSize` or `memcmp` filter | Whole-program subscriptions are unconditionally blocked | For details, see [WebSocket Restrictions](https://supanode.xyz/docs/solana/websocket/restrictions). ## RPC: how it's restricted **No method blocklist for RPC.** Every method in the [Solana RPC spec](https://solana.com/docs/rpc/http) is supported. Heavy traffic is shaped by method weights, not bans. What controls heavy traffic is the **method weight system**. Calls that touch many accounts cost more RPS units per call - `getProgramAccounts` is 30 units, `getTransaction` is 10. See [RPC Limits](https://supanode.xyz/docs/solana/rpc/limits) for the table. The plan price reflects this implicit budget. A 100 RPS plan handles ~100 simple `getAccountInfo` calls per second, but only ~3 `getProgramAccounts` calls per second. ## Acceptable use **Don't use Supanode for:** - Public proxy services that resell our capacity to third parties. - Workloads that intentionally probe rate limits to map other tenants. - Anything illegal in the jurisdiction where you operate. Standard stuff. We won't run a 50-page legal document - we'll use reasonable judgment, and if something is borderline, we'll talk to you before action. ## What you can do instead Dedicated Node - shared restrictions don't apply. Unfiltered block streaming, included in PROFESSIONAL. gRPC with proper filters - same data, more efficient. Telegram [@supanode_tgs](https://telegram.me/supanode_tgs). ## Per-product restrictions pages What RPC blocks (none) and how weights work. Blocked WS subscriptions in detail. Per-program reasoning for shared plans. ## Next steps All 5 Bundle plans. 24-hour trials on every product. Shared-plan restrictions don't apply. Fully custom hardware. --- ## Free trials Source: https://supanode.xyz/docs/solana/pricing/free-trials > Free trials on Supanode shared products: up to 24 hours on RPC, gRPC, Shreds, Sender, and Indexer. No credit card. Dedicated nodes run on a quote instead of a trial. Test Supanode products before you commit. **No credit card.** Trials are activated by a manager via Telegram - typically within hours, not days. ## Trials by product **Up to 24 hours.** BUILD tier limits during trial. **Up to 24 hours.** FOCUS tier limits during trial. **Up to 24 hours.** Frankfurt region. **Up to 24 hours.** Same access as paid. **Up to 24 hours.** Activated over Telegram. **No trial — custom quote.** Validate on shared-product trials first. ## How to activate [@supanode_tgs](https://telegram.me/supanode_tgs) - one handle for all trials. Mention more than one if you want to compare. You get connection details - an access token for RPC / WebSocket / gRPC, database credentials for the Indexer, or a destination IP:Port for Shreds. ## FAQ **Can I try multiple products?** Yes, but each trial is activated separately. **Can I extend my trial?** Contact us - we'll see what we can do. **What happens after the trial expires?** Access is revoked. To continue, choose a paid plan on [Plans](https://supanode.xyz/docs/solana/pricing/plans) (or contact us for custom-priced products like [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node), [Bare Metal Hosting](https://supanode.xyz/docs/solana/dedicated/bare-metal), [Sender](https://supanode.xyz/docs/solana/sender/overview), or [Indexer](https://supanode.xyz/docs/solana/indexer/overview)). **Why manual activation through Telegram instead of self-service?** 1. **Quality conversation.** We want to understand your use case and recommend the right product or tier. 2. **Anti-abuse.** Manual activation prevents trial farming. ## Next steps All 5 Bundle plans. Pick the right product. First request in 5 minutes. --- ## Hyperliquid overview Source: https://supanode.xyz/docs/hyperliquid/overview > Stream live over WebSocket, query indexed history, or run a dedicated node on Hyperliquid (HyperBFT). Hyperliquid runs on **HyperBFT** — it is **not Solana-derived and not EVM**. Its native interface is **WebSocket pub/sub**; there is no chain-native gRPC. You consume Hyperliquid data over a WebSocket subscription, not by polling a JSON-RPC or gRPC endpoint. Supanode gives you three ways in: - **WebSocket Streaming** — live orderbook, trades, and account events over the native WebSocket pub/sub interface. One flat monthly tier. - **Indexer** — Hyperliquid history (markets, fills/trades, positions) parsed into a SQL-queryable warehouse for analytics, PnL, and backtesting. - **Dedicated** — a private node with its own WebSocket endpoint, custom region, and custom hardware, quoted per workload. Billing is crypto-only (USDC · SOL · ETH · USDT), monthly prepaid, with no per-message fees on streaming. Provisioning is handled via Telegram. ## Where to next Live orderbook, trades, and account events. $289 / mo. SQL-queryable Hyperliquid history. $300 / mo. Private node, custom region and hardware. Custom quote. All three products, billing, and the free trial. --- ## Hyperliquid WebSocket Source: https://supanode.xyz/docs/hyperliquid/websocket > Live Hyperliquid orderbook, trades, and account events over the native WebSocket pub/sub interface. One flat tier at $289 / mo. Hyperliquid's native interface is **WebSocket pub/sub**. Supanode exposes it as a single flat tier — **\$289 / mo** — covering the live orderbook, trades, and account events, with no per-message fees. ## What you stream - **Orderbook** — live order book updates. - **Trades** — executed trades as they happen. - **Account events** — account-level activity. Additional details: - **Direct Telegram support** — talk to us directly for setup and issues. ## Connecting The interface is standard **WebSocket pub/sub**. Your WebSocket endpoint is provisioned for you over Telegram when you subscribe — there is no public endpoint list. Once provisioned, you connect over WebSocket and subscribe to the streams you need (orderbook, trades, account events). **Free trial up to 24h.** No card required — activate it via Telegram by saying what you want to test. ## Get started DM us on Telegram to provision your endpoint or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Hyperliquid indexer Source: https://supanode.xyz/docs/hyperliquid/indexer > Every Hyperliquid perpetual fill in ClickHouse — 2.9 billion rows with nanosecond block timing, liquidation and TWAP context, builder codes, plus an order-level book archive for exact-moment reconstruction. Every Hyperliquid perpetual fill, queryable with plain SQL. 2.9 billion rows carrying nanosecond block timing, liquidation and TWAP context, builder codes, fees and position deltas. **Database name is `hyperliquid`.** Connection details are provisioned per customer over Telegram - see [Connection](#connection). ## What's indexed | Table | What it holds | |---|---| | `raw_node_fills_by_block` | One row per fill as read from the node: price, size, side, position before, realized PnL, fee, builder, TWAP and liquidation context, nanosecond block time | | `agg_fulfilled_order` | The same activity rolled up per order, on a 90-day window | | `view_perpetual_wallet` | Per-wallet aggregate: PnL, volume, win count, ROI quantiles, active days | | `view_wallet_position` | Latest position per wallet and market | Scale as of 16 August 2026: **2,939,686,977 fills, 211 GB**, across all perpetual markets, updated in real time. Full column lists are in the [Table reference](https://supanode.xyz/docs/hyperliquid/tables). **No funding-rate table.** Funding is not part of this dataset. The Indexer covers fills and everything hanging off a fill - liquidations, TWAP membership, builder codes, fees, priority gas, position deltas. For live funding, use the Hyperliquid API alongside it. ## What you get that a public API will not give you ### Nanosecond block timing `utc_block_dttm` is `DateTime64(9)` - nanosecond resolution on the block, alongside `block_id` and `block_tx_idx` for exact ordering inside it. That is what latency analysis, cross-venue arbitrage timing, and order-flow pattern detection need; millisecond fill time is not enough. ### Full position context Each fill carries `start_position` (size before the fill), `closed_pnl`, `order_crossed_spread_flg` for the maker/taker split, and the liquidation triple - `liquidation_user`, `liquidation_mark_px`, `liquidation_method`. ### Attribution `builder` and `builder_fee` show which front-end or API routed the order and what it earned. `client_order_id`, `twap_id` and `priority_gas` complete the picture of how the order was constructed. ## Order-book archive Fills tell you what traded. They do not tell you what the book looked like at the moment it traded. For that we keep an **order-level** archive of the Hyperliquid book, provisioned separately from the ClickHouse database. | Component | Format | |---|---| | Book checkpoints | MessagePack ABCI snapshots, order-level | | Book diffs | hourly zstd-compressed streams | | Order statuses | hourly zstd-compressed streams | | Fills | hourly zstd-compressed streams | ### Why order-level rather than price-level Aggregated price-level data cannot be replayed correctly. If three orders rest at the same price and one is cancelled or partially filled, a price-level feed only shows the level shrinking - it cannot tell you which order moved. Replaying by order ID keeps that correct. Each diff record does one of three things: A new order appears, with its order ID, side, price and size. An existing order's remaining size changes. The order ID leaves the book. Only after the replay are live orders aggregated into price levels. From there you can read best bid, best ask, spread, live order count, and depth within a chosen basis-point band around the midpoint - at any second inside the window, not just at candle boundaries. ### Reconstructing a moment Take the newest checkpoint at or before your target time. It carries the order-level state of the book plus the metadata you need - the historical numeric asset encoding and the size precision for that market. Pull every hourly diff file covering the span between the checkpoint and your target time. Skip diff blocks already represented in the checkpoint, then apply the rest in order. Aggregate into price levels only at the end. Walk the reconstructed book across your window and read bid, ask, midpoint, spread and depth at whatever interval your study needs. **This is how you do cross-venue work properly.** Replay the Hyperliquid book second by second across the exact window of an event on another venue, and you are comparing real books rather than coarse candles. Archive access is arranged per customer - message [@supanode_tgs](https://telegram.me/supanode_tgs) with the markets and date range you need. ## Connection The Indexer is exposed over ClickHouse. Connect with standard tooling and run your own SQL. Host, port and credentials are provisioned per customer via Telegram [@supanode_tgs](https://telegram.me/supanode_tgs). The database name is `hyperliquid`. Keep credentials in environment variables or a local `.env`, never in source. ### Python ```python import os import clickhouse_connect client = clickhouse_connect.get_client( host=os.environ['CH_HOST'], port=int(os.environ['CH_PORT']), username=os.environ['CH_USER'], password=os.environ['CH_PASSWORD'], database='hyperliquid', secure=True, ) df = client.query_df(""" SELECT utc_fill_dttm, wallet_address, coin, side, price, size, price * size AS notional, closed_pnl, fee FROM raw_node_fills_by_block PREWHERE utc_fill_dt = today() ORDER BY notional DESC LIMIT 100 """) print(df.head()) ``` ### DBeaver Create a **New Connection** and select the **ClickHouse** driver. Enter the host and port we provisioned for you. Set the database to `hyperliquid`. Enter your username and password, then test the connection. ## First query ```sql SELECT coin, count() AS fills, sum(price * size) AS notional_volume, uniq(wallet_address) AS traders FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() GROUP BY coin ORDER BY notional_volume DESC LIMIT 20 ``` **Always filter on `utc_fill_dt` in `PREWHERE`.** It is the partition key. Without it a query scans all 211 GB. ## Next steps Every column, type, and partition key. Leaderboards, liquidations, TWAP scoring, block timing. Tiers and what is included. Provision access or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Hyperliquid query examples Source: https://supanode.xyz/docs/hyperliquid/examples > Working ClickHouse SQL against the Supanode Hyperliquid Indexer: trader leaderboards, maker/taker split, liquidations, TWAP execution quality, builder-code flow, and nanosecond block timing. Queries you can paste, each written against the real columns in the [Table reference](https://supanode.xyz/docs/hyperliquid/tables). **Everything starts from `raw_node_fills_by_block`.** One row per fill, partitioned by `utc_fill_dt`. Filter on that date column in `PREWHERE` before anything else - the table is 2.9 billion rows and 211 GB. **Amounts are already in USD.** `closed_pnl`, `fee`, `builder_fee` and `priority_gas` are `Float64` in USD - no base-unit division. Notional is `price * size`. ## Check the enum values first `side` and `fill_type` are plain strings. Confirm what they actually contain before you hard-code a filter: ```sql SELECT side, fill_type, count() AS fills FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() GROUP BY side, fill_type ORDER BY fills DESC ``` ## Largest fills in the last 24 hours ```sql SELECT utc_fill_dttm, fill_id, wallet_address, coin, side, price, size, price * size AS notional, closed_pnl, fee, liquidation_user FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 1 ORDER BY notional DESC LIMIT 100 ``` ## Volume by market ```sql SELECT coin, count() AS fills, sum(price * size) AS notional_volume, uniq(wallet_address) AS unique_traders, avg(price * size) AS avg_fill_notional FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 1 GROUP BY coin ORDER BY notional_volume DESC LIMIT 50 ``` ## Maker versus taker flow `order_crossed_spread_flg` is the taker flag - it is set when the order crossed the spread rather than resting on the book. ```sql SELECT coin, countIf(order_crossed_spread_flg) AS taker_fills, countIf(NOT order_crossed_spread_flg) AS maker_fills, sumIf(price * size, order_crossed_spread_flg) AS taker_notional, sumIf(price * size, NOT order_crossed_spread_flg) AS maker_notional, round(100 * countIf(order_crossed_spread_flg) / count(), 2) AS taker_pct FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() GROUP BY coin ORDER BY taker_notional DESC LIMIT 25 ``` ## Trader PnL leaderboard ```sql SELECT wallet_address, count() AS fills, countIf(closed_pnl != 0) AS closing_fills, sum(closed_pnl) AS realized_pnl, sum(price * size) AS notional_volume, sum(fee) AS fees_paid, countIf(closed_pnl > 0) AS wins, countIf(closed_pnl < 0) AS losses, round(100 * countIf(closed_pnl > 0) / nullIf(countIf(closed_pnl != 0), 0), 2) AS win_rate_pct, uniq(coin) AS markets FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 30 GROUP BY wallet_address HAVING closing_fills >= 50 ORDER BY realized_pnl DESC LIMIT 100 ``` **The same leaderboard, precomputed.** `view_perpetual_wallet` already holds `total_pnl`, `total_volume`, `win_count`, `cnt_trade_days` and ROI quantiles per wallet - see the query further down. Use it when you want the answer, and the raw table when you want to define the window yourself. ## Liquidations A liquidation carries a non-null `liquidation_user`, together with the mark price and the method used. ```sql SELECT utc_fill_dttm, coin, liquidation_user, liquidation_method, liquidation_mark_px, side, price, size, price * size AS notional, closed_pnl FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 1 WHERE liquidation_user IS NOT NULL ORDER BY notional DESC LIMIT 100 ``` Rolled up by market over a week: ```sql SELECT coin, count() AS liquidation_fills, uniq(liquidation_user) AS wallets_liquidated, sum(price * size) AS liquidated_notional, sum(closed_pnl) AS realized_pnl FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 7 WHERE liquidation_user IS NOT NULL GROUP BY coin ORDER BY liquidated_notional DESC ``` ## TWAP execution quality Fills belonging to the same TWAP share a `twap_id`. Grouping on it reconstructs the whole execution. ```sql SELECT twap_id, wallet_address, coin, side, count() AS fills, sum(size) AS total_size, sum(price * size) / sum(size) AS vwap, min(utc_fill_dttm) AS started, max(utc_fill_dttm) AS ended, dateDiff('minute', min(utc_fill_dttm), max(utc_fill_dttm)) AS duration_min FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 1 WHERE twap_id IS NOT NULL GROUP BY twap_id, wallet_address, coin, side ORDER BY total_size DESC LIMIT 50 ``` Compare a TWAP's own VWAP against the market VWAP over the same window to score the execution: ```sql WITH twaps AS ( SELECT twap_id, coin, sum(price * size) / sum(size) AS twap_vwap, sum(size) AS twap_size, min(utc_fill_dttm) AS t0, max(utc_fill_dttm) AS t1 FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() WHERE twap_id IS NOT NULL GROUP BY twap_id, coin HAVING count() >= 5 ) SELECT t.twap_id, t.coin, t.twap_size, t.twap_vwap, m.market_vwap, round(1e4 * (t.twap_vwap - m.market_vwap) / m.market_vwap, 2) AS slippage_bps FROM twaps AS t INNER JOIN ( SELECT coin, sum(price * size) / sum(size) AS market_vwap FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() GROUP BY coin ) AS m ON t.coin = m.coin ORDER BY abs(slippage_bps) DESC LIMIT 50 ``` ## Builder-code flow `builder` identifies the front-end or API that routed the order, and `builder_fee` is what it earned. ```sql SELECT builder, count() AS fills, uniq(wallet_address) AS wallets, sum(price * size) AS routed_notional, sum(builder_fee) AS builder_revenue FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 7 WHERE builder IS NOT NULL GROUP BY builder ORDER BY routed_notional DESC LIMIT 25 ``` ## Priority gas spend ```sql SELECT wallet_address, count() AS fills, sum(priority_gas) AS priority_gas_usdc, max(priority_gas) AS biggest_single, sum(price * size) AS notional FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt >= today() - 7 WHERE priority_gas IS NOT NULL AND priority_gas > 0 GROUP BY wallet_address ORDER BY priority_gas_usdc DESC LIMIT 25 ``` ## Nanosecond block timing `utc_block_dttm` is `DateTime64(9)` - nanosecond resolution on the block, while `utc_fill_dttm` is millisecond resolution on the fill. Use the block timestamp with `block_tx_idx` for ordering work. ```sql SELECT block_id, utc_block_dttm, count() AS fills_in_block, uniq(coin) AS markets, min(block_tx_idx) AS first_tx_idx, max(block_tx_idx) AS last_tx_idx, sum(price * size) AS block_notional FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() GROUP BY block_id, utc_block_dttm ORDER BY fills_in_block DESC LIMIT 25 ``` Time between consecutive blocks, in milliseconds: ```sql SELECT block_id, utc_block_dttm, round((toUnixTimestamp64Nano(utc_block_dttm) - toUnixTimestamp64Nano(any(utc_block_dttm) OVER (ORDER BY block_id ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING))) / 1e6, 3) AS gap_ms FROM ( SELECT DISTINCT block_id, utc_block_dttm FROM hyperliquid.raw_node_fills_by_block PREWHERE utc_fill_dt = today() ORDER BY block_id LIMIT 5000 ) ORDER BY block_id ``` ## Precomputed wallet views ```sql SELECT wallet_address, total_pnl, total_volume, cnt_unique_orders, win_count, total_count, round(100 * win_count / nullIf(total_count, 0), 2) AS win_rate_pct, cnt_unique_coins, cnt_trade_days, last_utc_order_dt FROM hyperliquid.view_perpetual_wallet WHERE total_count > 100 ORDER BY total_pnl DESC LIMIT 100 ``` Open positions right now, by market: ```sql SELECT coin, countIf(last_position_size > 0) AS longs, countIf(last_position_size < 0) AS shorts, sumIf(last_position_size, last_position_size > 0) AS long_size, sumIf(last_position_size, last_position_size < 0) AS short_size FROM hyperliquid.view_wallet_position WHERE last_position_size != 0 GROUP BY coin ORDER BY long_size + abs(short_size) DESC ``` ## Orders instead of fills `agg_fulfilled_order` collapses every fill of an order into one row. Its aggregate columns must be read through `sum()`. ```sql SELECT wallet_address, coin, count() AS orders, sum(size) AS filled_size, sum(volume) AS filled_volume_usd, sum(closed_pnl) AS realized_pnl FROM hyperliquid.agg_fulfilled_order PREWHERE utc_first_fill_dt >= today() - 30 GROUP BY wallet_address, coin ORDER BY filled_volume_usd DESC LIMIT 50 ``` ## Performance notes - **Always filter `utc_fill_dt` in `PREWHERE`.** It is the partition key; everything else is a full scan. - **Add a `coin` filter** whenever the question is about one market - it cuts the scan by an order of magnitude. - **Aggregate before joining.** The two-step TWAP query above joins two aggregates, not two raw scans. - **`agg_fulfilled_order` keeps 90 days.** Longer studies run on `raw_node_fills_by_block`. Check the plan before a heavy scan: ```sql EXPLAIN indexes = 1 SELECT count() FROM hyperliquid.raw_node_fills_by_block WHERE utc_fill_dt = today() ``` ## Get started Provision access or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Hyperliquid table reference Source: https://supanode.xyz/docs/hyperliquid/tables > Full schema for the Supanode Hyperliquid Indexer — raw block fills plus order, wallet and position views, with every column, type and partition key. The `hyperliquid` database holds perpetual exchange activity: one row per fill, plus derived order and wallet rollups. This page documents every table, column, type, and description. For runnable patterns see [Query examples](https://supanode.xyz/docs/hyperliquid/examples); for connection details see [Indexer overview](https://supanode.xyz/docs/hyperliquid/indexer). **Schema snapshot: 16 August 2026.** Row counts grow continuously - `raw_node_fills_by_block` added roughly 760 million rows between the May and August snapshots. ## Summary | Table | Kind | Rows | Size | |---|---|---|---| | `raw_node_fills_by_block` | table | 2,939,686,977 | 211.11 GB | | `agg_fulfilled_order` | order rollup | not reported | not reported | | `view_perpetual_wallet` | view | not reported | not reported | | `view_wallet_position` | view | not reported | not reported | **Why three tables say "not reported".** The wallet and position surfaces are views - they hold no rows of their own and are computed from the fill data when you query them, so the catalog reports nothing for them. Query them directly and you get rows back. `agg_fulfilled_order` is an aggregating rollup on a 90-day window; ask us for its current depth before you build a pipeline on it. ## raw_node_fills_by_block Raw, per-fill records as read from the node, ordered by block. This is the table almost every query starts from. **Partition key:** `utc_fill_dt` **Rows:** 2,939,686,977 · **Size:** 211.11 GB | Column | Type | Description | |---|---|---| | `utc_fill_dttm` | DateTime64(3, 'UTC') | UTC datetime of the fill (millisecond precision) | | `utc_fill_dt` | Date | UTC date of the fill (for partitioning) | | `fill_id` | Int64 | Unique fill identifier | | `fill_hash` | String | Hash of the fill | | `fill_type` | String | Type of fill (trade, liquidation, etc.) | | `utc_block_dttm` | DateTime64(9, 'UTC') | UTC datetime of the block (nanosecond precision) | | `block_id` | Int64 | Hyperliquid block number | | `block_tx_idx` | UInt16 | Transaction index within the block | | `wallet_address` | String | Wallet address of the trader | | `coin` | String | Trading pair symbol (e.g. BTC, ETH) | | `price` | Float64 | Execution price | | `size` | Float64 | Fill size (in contracts) | | `side` | String | Trade side (Buy/Sell) | | `start_position` | Float64 | Position size before the fill | | `closed_pnl` | Float64 | Realized PnL from this fill, in USD | | `order_id` | Int64 | Order identifier | | `order_crossed_spread_flg` | Bool | Whether the order crossed the spread (taker) | | `fee` | Float64 | Trading fee | | `fee_token` | String | Token used for fee payment | | `client_order_id` | Nullable(String) | Client-provided order ID | | `builder_fee` | Nullable(Float64) | Builder / API fee | | `builder` | Nullable(String) | Builder / API identifier | | `liquidation_user` | Nullable(String) | User being liquidated (if a liquidation) | | `liquidation_mark_px` | Nullable(Float64) | Mark price at liquidation | | `liquidation_method` | Nullable(String) | Liquidation method used | | `twap_id` | Nullable(Int64) | TWAP order identifier | | `deployer_fee` | Nullable(Float64) | Deployer fee for spot tokens | | `priority_gas` | Nullable(Float64) | Priority gas paid for inclusion, in USDC | **`closed_pnl` and `fee` are already denominated in USD.** They are `Float64`, not integer base units - do not divide by `1e6` or `1e8`. Hyperliquid is the exception here; the Solana tables use raw base units. ## agg_fulfilled_order Fill-level activity aggregated up to the fulfilled order, so one row covers every fill that belonged to the same `order_id`. **Partition key:** `toYYYYMM(utc_first_fill_dt)` **Retention:** 90 days | Column | Type | Description | |---|---|---| | `utc_first_fill_dttm` | SimpleAggregateFunction(min, DateTime64(3, 'UTC')) | UTC datetime of the first fill for this order | | `utc_first_fill_dt` | Date | UTC date of the first fill (for partitioning) | | `order_id` | Int64 | Unique order identifier | | `wallet_address` | String | Wallet address of the trader | | `coin` | String | Trading pair symbol | | `side` | String | Trade side (Buy/Sell) | | `twap_id` | Nullable(Int64) | TWAP order identifier, if part of a TWAP | | `size` | SimpleAggregateFunction(sum, Float64) | Total filled size, in contracts | | `volume` | SimpleAggregateFunction(sum, Float64) | Total filled volume, in USD | | `closed_pnl` | SimpleAggregateFunction(sum, Float64) | Realized PnL from this order | **Aggregate columns need their combinator.** `size`, `volume` and `closed_pnl` are `SimpleAggregateFunction(sum, ...)` - read them through `sum()` in a `GROUP BY`, not as plain values. ## view_perpetual_wallet Per-wallet aggregate across all positions. Everything needed for a trader leaderboard without writing the aggregation yourself. | Column | Type | Description | |---|---|---| | `wallet_address` | String | Wallet address of the trader | | `total_pnl` | Float64 | Total realized profit and loss across all positions | | `total_volume` | Float64 | Total trading volume, in USD | | `cnt_unique_orders` | UInt64 | Count of unique orders placed | | `last_utc_order_dt` | SimpleAggregateFunction(max, Date) | UTC date of the most recent order | | `win_count` | UInt64 | Number of profitable trades | | `total_count` | UInt64 | Total number of completed trades | | `sum_order_roi` | Float64 | Sum of return on investment across all orders | | `sum_profitable_pnl` | Float64 | Sum of PnL from profitable trades | | `cnt_profitable_orders` | UInt64 | Count of profitable orders | | `sum_unprofitable_pnl` | Float64 | Sum of PnL from unprofitable trades (negative) | | `cnt_unprofitable_orders` | UInt64 | Count of unprofitable orders | | `cnt_unique_coins` | UInt64 | Number of unique trading pairs traded | | `cnt_trade_days` | UInt64 | Number of distinct days with trading activity | | `roi_quantiles` | Array(Float64) | ROI distribution quantiles for the wallet | ## view_wallet_position Latest position per wallet and market. | Column | Type | Description | |---|---|---| | `wallet_address` | String | Wallet address of the trader | | `coin` | String | Trading pair symbol | | `last_position_size` | Float64 | Current position size (positive = long, negative = short) | | `last_position_update_dttm` | DateTime64(3, 'UTC') | UTC datetime of the last position update | ## What is not in the database **There is no funding-rate or funding-payment table.** Funding is not part of this dataset - anything you read about funding history belongs to the Hyperliquid API, not to the Indexer. What the Indexer covers is fills, and everything hanging off a fill: liquidations, TWAP membership, builder codes, fees, priority gas, and position deltas. Order-book depth is a separate surface - see [Order-book archive](https://supanode.xyz/docs/hyperliquid/indexer#order-book-archive). ## Get started Provision access or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Hyperliquid dedicated Source: https://supanode.xyz/docs/hyperliquid/dedicated > A private Hyperliquid node with its own WebSocket endpoint, custom region, and custom hardware. Custom quote within 24h. Dedicated is a **private Hyperliquid node** built for your workload. You get your own WebSocket endpoint with no shared limits, a custom region, and custom hardware. Pricing is a **custom quote**, delivered within **24h** once you share your region and throughput. ## What you get - **Dedicated WebSocket endpoint** — your own, not shared. - **Private node** — no shared limits. - **Custom region and custom hardware** — provisioned to your requirements. - **Direct engineer in Telegram** — talk to the person who builds it. Dedicated is built per order, so it is **not trial-eligible**. The free trial applies to WebSocket Streaming only. For Dedicated, get a quote first. ## Talk to us DM us on Telegram with your region and throughput, and we'll quote within 24h: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Hyperliquid pricing Source: https://supanode.xyz/docs/hyperliquid/pricing > Hyperliquid pricing — WebSocket Streaming, Indexer, and Dedicated. Crypto-only, monthly prepaid. Three ways in: live WebSocket streaming, the SQL-queryable Indexer, or a Dedicated node. | Product | Price | |---|---| | [WebSocket Streaming](https://supanode.xyz/docs/hyperliquid/websocket) | $289 / mo | | [Indexer](https://supanode.xyz/docs/hyperliquid/indexer) | $300 / mo | | [Dedicated](https://supanode.xyz/docs/hyperliquid/dedicated) | Custom quote (within 24h) | ## Billing - **Crypto-only** — USDC · SOL · ETH · USDT. - **Monthly, prepaid.** - **No per-message fees** on streaming. - **Provisioning via Telegram.** ## Free trial - **Up to 24h** free on WebSocket Streaming — no card, activated via Telegram. - **Dedicated is not trial-eligible** — it is built per order. Get a quote first. ## Get started DM us on Telegram to provision a product or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Polymarket overview Source: https://supanode.xyz/docs/polymarket/overview > Polymarket prediction-market history indexed into ClickHouse: 1.82 billion fills since November 2022, joined to full market and event metadata. One product: Indexer. Polymarket is a **prediction market**, not a chain. Supanode indexes its on-chain fills and the metadata around them into a SQL-queryable warehouse - one product, the Indexer. **One product: Indexer.** The history is already collected and structured - 1.82 billion fills back to November 2022. You write SQL. ## What you get - **Fills:** every on-chain fill leg from the CTF Exchange, with wallet, outcome token, side, token and USDC amounts, fee, maker flag, and the full Polygon transaction envelope. - **Markets:** questions, outcomes, CLOB token ids, current pricing and liquidity, resolution status - 140 typed columns. - **Events:** titles, slugs, categories, dates, and volume aggregated across the markets an event contains. - **Executed probability:** USDC over tokens gives the traded probability directly, so the fill history is also the price history. - **Order-book depth:** available separately as a CLOB capture archive - snapshots plus price-level changes, replayable to any moment. See [Order-book archive](https://supanode.xyz/docs/polymarket/indexer#order-book-archive). Query it directly over ClickHouse SQL, or have us deploy custom REST endpoints for recurring queries. ## Where to next What is indexed, how the tables join, how to connect. All three tables, column by column. Probability series, calibration, trader PnL. Flat monthly tier, billing, and free trial. --- ## Polymarket indexer Source: https://supanode.xyz/docs/polymarket/indexer > 1.82 billion Polymarket fills back to November 2022, joined to full market and event metadata, in ClickHouse SQL. Plus a CLOB order-book capture archive. Flat $300 / mo. Every on-chain Polymarket fill since the exchange opened, joined to the market and event metadata that makes it readable. Already collected and structured in ClickHouse - you write SQL. **\$300 / mo flat.** ## What's indexed | Table | What it holds | Rows | Size | |---|---|---|---| | `polymarket_order_filled_v3` | One row per fill leg from the CTF Exchange: wallet, outcome token, side, token and USDC amounts, fee, maker flag, and the full Polygon transaction envelope | 1.82B | 299 GB | | `raw_market_meta` | Market metadata: question, outcome, CLOB token id, current pricing and liquidity, resolution status - 140 columns | 12.1M | 13.3 GB | | `raw_event_meta` | Event metadata: title, slug, category, dates, aggregate volume and liquidity - 92 columns | 2.48M | 10.8 GB | **History:** fills from **21 November 2022** to now, continuously refreshed. Full column lists are in the [Table reference](https://supanode.xyz/docs/polymarket/tables). **Metadata grew a lot this summer.** `raw_market_meta` went from 2.3M rows to 12.1M and `raw_event_meta` from 42K to 2.48M as Polymarket expanded into sports and recurring markets. Sports fields - teams, game status, spreads, totals - are typed columns now, not just `raw_json`. ## How the pieces fit | From | Column | To | Column | |---|---|---|---| | `polymarket_order_filled_v3` | `asset` | `raw_market_meta` | `clob_token_id` | | `polymarket_order_filled_v3` | `event_id` | `raw_event_meta` | `event_id` | `asset` is the outcome token - one market has one row per outcome, each with its own `clob_token_id`. That join turns a raw fill into "someone bought YES on this question at this probability". **Probability comes for free.** `amount_usdc` and `amount_token` both carry 6 decimals, so `amount_usdc / amount_token` is the executed probability on a 0 to 1 scale. No price feed needed - the fills are the price series. **Deduplicate the metadata before joining.** `raw_market_meta` and `raw_event_meta` are append-style snapshots with an `inserted_at` column and no partition key, so a market can appear more than once. Reduce with `argMax(..., inserted_at)` first, or the join multiplies your fill rows. There is a ready-made pattern in [Query examples](https://supanode.xyz/docs/polymarket/examples#deduplicating-the-metadata-tables). ## What this makes easy - **Executed price series** for any outcome, at any resolution, straight from fills. - **Calibration studies** - bucket outcomes by traded probability and check how often they actually resolved true. - **Trader analysis** - net position and cost basis per wallet per outcome, maker versus taker mix, fees paid. - **Event rollups** - volume and unique wallets across every market belonging to one event. - **Resolution edge** - what people paid versus how the market settled. - **Polygon transaction costs** - gas, base fee and priority fee travel with every fill. ## Order-book archive Fills tell you what traded. For what the book looked like, we keep a separate CLOB capture archive - full snapshots, price-level changes, and explicit best-bid / best-ask transitions per outcome token. | Component | Format | |---|---| | Captures | `.log` and `.log.zst` per market | | Line format | JSON, optionally prefixed with a capture timestamp and a tab | | Anchor record | a `book` event replacing both sides of the selected asset's book | | Update record | `price_change` entries setting a level to a size, or deleting it when the size is zero | Find the `book` event for the outcome token you want. It gives you both sides of the book at that instant. Walk the `price_change` records forward. Each sets a price level to the given size, or removes the level when the size is zero. At any point in the replay you have best bid, best ask, and level counts on both sides. **Five-minute Bitcoin Up/Down markets get their own captures.** Those markets move fastest right before resolution, which is exactly where aggregated data loses the detail. The dedicated files preserve it, and they join straight back to event and market metadata in ClickHouse. Archive access is arranged per customer - message [@supanode_tgs](https://telegram.me/supanode_tgs) with the markets and date range you need. ## Interfaces - **ClickHouse SQL** - connect with DBeaver, DataGrip, the Python client, or anything speaking the HTTP or native protocol. - **Custom REST endpoints** - a recurring query deployed as a stable URL, quoted per scope. ## Connection The database is named `polymarket`. Host, port and credentials are provisioned per customer via Telegram [@supanode_tgs](https://telegram.me/supanode_tgs). Keep them in environment variables or a local `.env`, never in source. ### Python ```python import os import clickhouse_connect client = clickhouse_connect.get_client( host=os.environ['CH_HOST'], port=int(os.environ['CH_PORT']), username=os.environ['CH_USER'], password=os.environ['CH_PASSWORD'], database='polymarket', secure=True, ) df = client.query_df(""" SELECT block_timestamp, wallet, asset, side, is_maker, amount_token / 1e6 AS shares, amount_usdc / 1e6 AS usdc, amount_usdc / nullIf(amount_token, 0) AS implied_probability FROM polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 1 HOUR ORDER BY amount_usdc DESC LIMIT 100 """) print(df.head()) ``` ### DBeaver Create a **New Connection** and select the **ClickHouse** driver. Enter the host and port we provisioned for you. Set the database to `polymarket`. Enter your username and password, then test the connection. **Always filter `block_timestamp` in `PREWHERE`.** It feeds the partition key `toYYYYMMDD(block_timestamp)`. Without it a query scans all 299 GB. ## Access Provisioning is manual, over Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). **Free trial up to 24 hours.** Activate it via Telegram before committing to a monthly tier. ## Next steps All three tables, column by column. Probability series, calibration, trader PnL. Flat monthly tier, billing, free trial. --- ## Polymarket query examples Source: https://supanode.xyz/docs/polymarket/examples > Working ClickHouse SQL against the Supanode Polymarket Indexer: executed probabilities, market and event rollups, trader PnL, maker/taker split, resolution outcomes, and gas costs. Queries you can paste, each written against the real columns in the [Table reference](https://supanode.xyz/docs/polymarket/tables). **Three tables, two join keys.** Fills live in `polymarket_order_filled_v3`; `asset` joins to `raw_market_meta.clob_token_id` for the question and outcome, and `event_id` joins to `raw_event_meta.event_id` for the event around it. **Always filter `block_timestamp` in `PREWHERE`.** It drives the partition key. The fills table is 1.8 billion rows and 299 GB. ## Amounts and probability `amount_usdc`, `amount_token` and `fee` are `UInt256` in base units with 6 decimals. Both sides share those decimals, so their ratio is the executed probability on a 0 to 1 scale. ```sql SELECT block_timestamp, transaction_hash, wallet, asset, side, is_maker, amount_token / 1e6 AS shares, amount_usdc / 1e6 AS usdc, fee / 1e6 AS fee_usdc, amount_usdc / nullIf(amount_token, 0) AS implied_probability FROM polymarket.polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 1 DAY ORDER BY amount_usdc DESC LIMIT 100 ``` ## Deduplicating the metadata tables `raw_market_meta` and `raw_event_meta` are append-style snapshots. Reduce them to the latest row per key before joining, or every duplicate snapshot multiplies your fill rows. ```sql CREATE VIEW IF NOT EXISTS latest_market AS SELECT clob_token_id, argMax(condition_id, inserted_at) AS condition_id, argMax(question, inserted_at) AS question, argMax(outcome, inserted_at) AS outcome, argMax(slug, inserted_at) AS slug, argMax(category, inserted_at) AS category, argMax(is_closed, inserted_at) AS is_closed, argMax(outcome_price, inserted_at) AS outcome_price, argMax(best_bid, inserted_at) AS best_bid, argMax(best_ask, inserted_at) AS best_ask, argMax(spread, inserted_at) AS spread FROM polymarket.raw_market_meta GROUP BY clob_token_id ``` If you cannot create objects with your credentials, inline the same block as a CTE - every example below works either way. ## Busiest markets in the last 24 hours ```sql WITH latest_market AS ( SELECT clob_token_id, argMax(question, inserted_at) AS question, argMax(outcome, inserted_at) AS outcome, argMax(category, inserted_at) AS category FROM polymarket.raw_market_meta GROUP BY clob_token_id ) SELECT m.question, m.outcome, m.category, count() AS fills, sum(f.amount_usdc) / 1e6 AS usdc_volume, uniq(f.wallet) AS wallets, sum(f.amount_usdc) / nullIf(sum(f.amount_token), 0) AS vwap_probability FROM polymarket.polymarket_order_filled_v3 AS f INNER JOIN latest_market AS m ON f.asset = m.clob_token_id PREWHERE f.block_timestamp >= now() - INTERVAL 1 DAY GROUP BY m.question, m.outcome, m.category ORDER BY usdc_volume DESC LIMIT 50 ``` ## Probability over time for one outcome Once you have the `clob_token_id` of the outcome you care about, this is the price series the market actually traded at - not a quoted mid, but executed volume-weighted probability. ```sql SELECT toStartOfFiveMinute(block_timestamp) AS bucket, sum(amount_usdc) / nullIf(sum(amount_token), 0) AS vwap_probability, min(amount_usdc / nullIf(amount_token, 0)) AS low, max(amount_usdc / nullIf(amount_token, 0)) AS high, sum(amount_usdc) / 1e6 AS usdc_volume, count() AS fills FROM polymarket.polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 7 DAY WHERE asset = 'YOUR_CLOB_TOKEN_ID' GROUP BY bucket ORDER BY bucket ``` ## Finding a market by its question ```sql SELECT clob_token_id, argMax(question, inserted_at) AS question, argMax(outcome, inserted_at) AS outcome, argMax(slug, inserted_at) AS slug, argMax(is_closed, inserted_at) AS is_closed, argMax(volume_num, inserted_at) AS volume, max(inserted_at) AS last_seen FROM polymarket.raw_market_meta WHERE positionCaseInsensitive(assumeNotNull(question), 'bitcoin') > 0 GROUP BY clob_token_id ORDER BY volume DESC LIMIT 50 ``` ## Event rollup ```sql WITH latest_event AS ( SELECT event_id, argMax(title, inserted_at) AS title, argMax(slug, inserted_at) AS slug, argMax(category, inserted_at) AS category, argMax(end_dttm, inserted_at) AS ends FROM polymarket.raw_event_meta GROUP BY event_id ) SELECT e.title, e.category, e.ends, count() AS fills, sum(f.amount_usdc) / 1e6 AS usdc_volume, uniq(f.wallet) AS wallets, uniq(f.asset) AS outcomes_traded FROM polymarket.polymarket_order_filled_v3 AS f INNER JOIN latest_event AS e ON f.event_id = e.event_id PREWHERE f.block_timestamp >= now() - INTERVAL 7 DAY GROUP BY e.title, e.category, e.ends ORDER BY usdc_volume DESC LIMIT 50 ``` ## Maker versus taker Each fill has two legs and `is_maker` separates them. Fees land on the taker side. ```sql SELECT toDate(block_timestamp) AS day, countIf(is_maker) AS maker_legs, countIf(NOT is_maker) AS taker_legs, sumIf(amount_usdc, is_maker) / 1e6 AS maker_usdc, sumIf(amount_usdc, NOT is_maker) / 1e6 AS taker_usdc, sum(fee) / 1e6 AS fees_usdc FROM polymarket.polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 30 DAY GROUP BY day ORDER BY day ``` ## Top wallets by volume ```sql SELECT wallet, count() AS fills, sum(amount_usdc) / 1e6 AS usdc_volume, sum(fee) / 1e6 AS fees_paid, uniq(asset) AS outcomes_traded, uniq(event_id) AS events_traded, countIf(is_maker) AS maker_legs, round(100 * countIf(is_maker) / count(), 2) AS maker_pct FROM polymarket.polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 30 DAY GROUP BY wallet ORDER BY usdc_volume DESC LIMIT 100 ``` ## Net position and cost basis per wallet `side` is `B` for buy and `S` for sell. Netting them gives shares held and average entry probability. ```sql SELECT wallet, asset, sumIf(amount_token, side = 'B') / 1e6 AS shares_bought, sumIf(amount_token, side = 'S') / 1e6 AS shares_sold, (sumIf(amount_token, side = 'B') - sumIf(amount_token, side = 'S')) / 1e6 AS net_shares, sumIf(amount_usdc, side = 'B') / nullIf(sumIf(amount_token, side = 'B'), 0) AS avg_buy_probability, sumIf(amount_usdc, side = 'S') / nullIf(sumIf(amount_token, side = 'S'), 0) AS avg_sell_probability, (sumIf(amount_usdc, side = 'S') - sumIf(amount_usdc, side = 'B')) / 1e6 AS realized_usdc FROM polymarket.polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 90 DAY WHERE wallet = 'YOUR_WALLET' GROUP BY wallet, asset HAVING abs(net_shares) > 0.000001 ORDER BY abs(net_shares) DESC LIMIT 100 ``` ## Who was right? Entry price versus resolution Closed markets carry their settled `outcome_price` - 1 for the outcome that happened, 0 for the one that did not. Compare it to what people paid. ```sql WITH latest_market AS ( SELECT clob_token_id, argMax(question, inserted_at) AS question, argMax(outcome, inserted_at) AS outcome, argMax(is_closed, inserted_at) AS is_closed, argMax(outcome_price, inserted_at) AS settled FROM polymarket.raw_market_meta GROUP BY clob_token_id ) SELECT m.question, m.outcome, m.settled, sum(f.amount_usdc) / nullIf(sum(f.amount_token), 0) AS avg_paid_probability, m.settled - sum(f.amount_usdc) / nullIf(sum(f.amount_token), 0) AS edge, sum(f.amount_usdc) / 1e6 AS usdc_volume FROM polymarket.polymarket_order_filled_v3 AS f INNER JOIN latest_market AS m ON f.asset = m.clob_token_id PREWHERE f.block_timestamp >= now() - INTERVAL 90 DAY WHERE m.is_closed AND m.settled IS NOT NULL GROUP BY m.question, m.outcome, m.settled HAVING usdc_volume > 10000 ORDER BY abs(edge) DESC LIMIT 50 ``` ## Longshot bias Bucket every closed outcome by the probability it traded at, then check how often it actually happened. A calibrated market sits on the diagonal. ```sql WITH latest_market AS ( SELECT clob_token_id, argMax(is_closed, inserted_at) AS is_closed, argMax(outcome_price, inserted_at) AS settled FROM polymarket.raw_market_meta GROUP BY clob_token_id ) SELECT floor(avg_prob * 10) / 10 AS probability_bucket, count() AS outcomes, avg(avg_prob) AS avg_traded_probability, avg(settled) AS actual_hit_rate, avg(settled) - avg(avg_prob) AS calibration_gap FROM ( SELECT f.asset AS asset, sum(f.amount_usdc) / nullIf(sum(f.amount_token), 0) AS avg_prob, any(m.settled) AS settled FROM polymarket.polymarket_order_filled_v3 AS f INNER JOIN latest_market AS m ON f.asset = m.clob_token_id PREWHERE f.block_timestamp >= now() - INTERVAL 180 DAY WHERE m.is_closed AND m.settled IS NOT NULL GROUP BY f.asset HAVING sum(f.amount_usdc) / 1e6 > 5000 ) GROUP BY probability_bucket ORDER BY probability_bucket ``` ## Polygon transaction costs The fills table carries the full EIP-1559 transaction envelope, so gas is queryable alongside the trade. ```sql SELECT toDate(block_timestamp) AS day, count() AS fills, avg(gas_used) AS avg_gas_used, avg(base_fee_per_gas / 1e9) AS avg_base_fee_gwei, avg(max_priority_fee_per_gas / 1e9) AS avg_priority_gwei, sum(gas_used * base_fee_per_gas) / 1e18 AS base_fee_pol FROM polymarket.polymarket_order_filled_v3 PREWHERE block_timestamp >= now() - INTERVAL 30 DAY GROUP BY day ORDER BY day ``` ## Performance notes - **`block_timestamp` in `PREWHERE`** - it feeds `toYYYYMMDD(block_timestamp)`, the partition key. - **Dedup metadata before joining**, never after. Joining raw `raw_market_meta` to fills multiplies rows by the number of snapshots. - **`asset` before `wallet`** - filtering to one outcome token cuts the scan far harder than filtering to one wallet. - **`raw_json` is the escape hatch** for any field Polymarket ships before it is typed. ```sql EXPLAIN indexes = 1 SELECT count() FROM polymarket.polymarket_order_filled_v3 WHERE block_timestamp >= now() - INTERVAL 1 DAY ``` ## Get started Provision access or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Polymarket table reference Source: https://supanode.xyz/docs/polymarket/tables > Full schema for the Supanode Polymarket Indexer - 1.82 billion on-chain fills plus 261 columns of event and market metadata, with types, partition key and join keys. The `polymarket` database pairs decoded Polygon fill events with the event and market metadata needed to make sense of them. This page documents every table, column, type, and description. For runnable patterns see [Query examples](https://supanode.xyz/docs/polymarket/examples); for connection details see [Indexer overview](https://supanode.xyz/docs/polymarket/indexer). **Schema snapshot: 16 August 2026.** Both metadata tables grew substantially over the summer - `raw_market_meta` went from 2.3M rows to 12.1M and `raw_event_meta` from 42K to 2.48M, as Polymarket expanded into sports and recurring markets. ## Summary | Table | Rows | Size | History | Partition key | |---|---|---|---|---| | [`polymarket_order_filled_v3`](#polymarketorderfilledv3) | 1,823,755,392 | 299.16 GB | 2022-11-21 → 2026-08-16 | `toYYYYMMDD(block_timestamp)` | | [`raw_market_meta`](#rawmarketmeta) | 12,097,579 | 13.27 GB | snapshots | none | | [`raw_event_meta`](#raweventmeta) | 2,484,405 | 10.83 GB | snapshots | none | ## How the three tables join | From | Column | To | Column | |---|---|---|---| | `polymarket_order_filled_v3` | `asset` | `raw_market_meta` | `clob_token_id` | | `polymarket_order_filled_v3` | `event_id` | `raw_event_meta` | `event_id` | | `raw_market_meta` | `condition_id` | - | groups the outcomes of one market | `asset` is the outcome token: one market has one row per outcome in `raw_market_meta`, each with its own `clob_token_id`. Joining on it is how a fill becomes "someone bought YES on this question". **The metadata tables are append-style snapshots.** They have no partition key and carry `inserted_at`, so a market or event can appear more than once as its state changes. Always reduce to the latest row per key with `argMax(..., inserted_at)` before joining - otherwise a join multiplies your fill rows. **Amounts are raw base units with 6 decimals.** `amount_usdc`, `amount_token` and `fee` are `UInt256`. Divide by `1e6` for a human number. Because both sides carry 6 decimals, `amount_usdc / amount_token` is the executed probability directly, on a 0 to 1 scale - no scaling needed. ## polymarket_order_filled_v3 On-chain order-fill events from the Polymarket CTF Exchange on Polygon, one row per fill leg. Maker and taker legs are separate rows, distinguished by `is_maker`. **Rows:** 1,823,755,392 · **Size:** 299.16 GB · **Columns:** 29 **Partition key:** `toYYYYMMDD(block_timestamp)` **History:** 2022-11-21 → 2026-08-16 | Column | Type | Description | |---|---|---| | `event_id` | String | Unique event identifier | | `order_hash` | String | Hash of the order | | `wallet` | String | Wallet address that placed the order | | `asset` | String | Outcome token (condition ID + outcome index) | | `amount_token` | UInt256 | Token amount filled | | `amount_usdc` | UInt256 | USDC amount filled | | `is_maker` | Bool | Whether this was the maker side | | `side` | FixedString(1) | Order side (B=buy, S=sell) | | `fee` | UInt256 | Fee amount in USDC | | `block_number` | UInt64 | Polygon block number | | `log_index` | UInt32 | Log index within the transaction | | `transaction_index` | UInt32 | Transaction index in block | | `contract_address` | String | CTF Exchange contract address | | `block_hash` | String | Block hash | | `block_timestamp` | DateTime | UTC timestamp of the block | | `gas_used` | UInt64 | Gas used by transaction | | `gas_limit` | UInt64 | Gas limit set for transaction | | `base_fee_per_gas` | UInt256 | Base fee per gas (EIP-1559) | | `transaction_hash` | String | Transaction hash | | `transaction_from` | String | Transaction sender | | `transaction_to` | String | Transaction recipient | | `transaction_value` | UInt256 | ETH value transferred | | `transaction_gas` | UInt64 | Gas provided for transaction | | `transaction_nonce` | UInt64 | Transaction nonce | | `max_fee_per_gas` | UInt256 | Maximum fee per gas (EIP-1559) | | `max_priority_fee_per_gas` | UInt256 | Maximum priority fee (EIP-1559) | | `inserted_at` | DateTime | Record insertion timestamp | | `builder` | String | Default: `''` | | `metadata` | String | Default: `''` | ## raw_market_meta Market-level metadata: the question, its outcomes and CLOB token ids, current pricing and liquidity, resolution status, and the sports and reward fields Polymarket added along the way. This is the table you join a fill to. **Rows:** 12,097,579 · **Size:** 13.27 GB · **Columns:** 140 **Partition key:** none - the table is small enough to scan, but filter on a key column anyway | Column | Type | Description | |---|---|---| | `market_id` | String | Unique market identifier | | `question` | Nullable(String) | Market question text | | `condition_id` | String | Gnosis conditional token condition ID | | `slug` | Nullable(String) | URL-friendly market slug | | `twitter_card_image` | Nullable(String) | Twitter card image URL | | `resolution_source` | Nullable(String) | Source for market resolution | | `market_end_dttm` | Nullable(DateTime64(3)) | Market end datetime | | `market_start_dttm` | Nullable(DateTime64(3)) | Market start datetime | | `category` | Nullable(String) | Market category | | `amm_type` | Nullable(String) | AMM type used | | `sponsor_name` | Nullable(String) | Market sponsor name | | `sponsor_image` | Nullable(String) | Sponsor image URL | | `x_axis_value` | Nullable(String) | X-axis label for charts | | `y_axis_value` | Nullable(String) | Y-axis label for charts | | `denomination_token` | Nullable(String) | Token used for denomination | | `fee` | Nullable(Float64) | Market fee percentage | | `lower_bound` | Nullable(String) | Lower bound for scalar markets | | `upper_bound` | Nullable(String) | Upper bound for scalar markets | | `description` | Nullable(String) | Market description | | `outcome` | Nullable(String) | Outcome name | | `outcome_price` | Nullable(Float64) | Current outcome price (0-1) | | `clob_token_id` | String | CLOB token identifier | | `volume` | Nullable(Float64) | Total trading volume | | `volume_num` | Nullable(Float64) | Numeric trading volume | | `is_active` | Nullable(Bool) | Whether market is active | | `market_type` | Nullable(String) | Type of market | | `format_type` | Nullable(String) | Display format type | | `lower_bound_dttm` | Nullable(String) | Lower bound datetime for time-based markets | | `upper_bound_dttm` | Nullable(String) | Upper bound datetime for time-based markets | | `is_closed` | Nullable(Bool) | Whether market is closed | | `market_maker_address` | Nullable(String) | Market maker address | | `created_by` | Nullable(Int64) | User ID who created the market | | `updated_by` | Nullable(Int64) | User ID who last updated the market | | `created_dttm` | Nullable(DateTime64(3)) | Market creation datetime | | `updated_dttm` | Nullable(DateTime64(3)) | Market last update datetime | | `closed_dttm` | Nullable(DateTime64(3)) | Market close datetime | | `is_wide_format` | Nullable(Bool) | Whether market uses wide display format | | `is_new` | Nullable(Bool) | Whether market is flagged as new | | `mailchimp_tag` | Nullable(String) | Mailchimp tag for notifications | | `is_featured` | Nullable(Bool) | Whether market is featured | | `is_archived` | Nullable(Bool) | Whether market is archived | | `resolved_by` | Nullable(String) | Resolution source or resolver | | `is_restricted` | Nullable(Bool) | Whether market has access restrictions | | `market_group` | Nullable(Int64) | Market group identifier | | `group_item_title` | Nullable(String) | Title within market group | | `group_item_threshold` | Nullable(String) | Threshold for group item | | `question_id` | Nullable(String) | Question identifier | | `uma_end_dttm` | Nullable(String) | UMA oracle end datetime | | `is_enable_order_book` | Nullable(Bool) | Whether order book is enabled | | `order_price_min_tick_size` | Nullable(Float64) | Minimum price tick size | | `order_min_size` | Nullable(Float64) | Minimum order size | | `uma_resolution_status` | Nullable(String) | UMA resolution status | | `curation_order` | Nullable(Int64) | Curation display order | | `liquidity_num` | Nullable(Float64) | Numeric liquidity value | | `end_date_iso_dt_str` | Nullable(String) | ISO format end date string | | `start_date_iso_dt_str` | Nullable(String) | ISO format start date string | | `uma_end_date_iso_dt_str` | Nullable(String) | UMA end date ISO string | | `is_having_reviewed_dates` | Nullable(Bool) | Whether dates have been reviewed | | `is_ready_for_cron` | Nullable(Bool) | Whether ready for cron processing | | `is_comments_enabled` | Nullable(Bool) | Whether comments are enabled | | `volume_24hr` | Nullable(Float64) | 24-hour trading volume | | `volume_1wk` | Nullable(Float64) | 7-day trading volume | | `volume_1mo` | Nullable(Float64) | 30-day trading volume | | `volume_1yr` | Nullable(Float64) | 1-year trading volume | | `game_start_time` | Nullable(String) | Game/event start time | | `seconds_delay` | Nullable(Int64) | Delay in seconds | | `disqus_thread` | Nullable(String) | Disqus comment thread ID | | `short_outcome` | Nullable(String) | Short outcome label | | `team_a_id` | Nullable(String) | Team A identifier (sports) | | `team_b_id` | Nullable(String) | Team B identifier (sports) | | `uma_bond` | Nullable(String) | UMA oracle bond amount | | `uma_reward` | Nullable(String) | UMA oracle reward amount | | `is_fpmm_live` | Nullable(Bool) | Whether FPMM is live | | `volume_24hr_amm` | Nullable(Float64) | 24-hour AMM volume | | `volume_1wk_amm` | Nullable(Float64) | 7-day AMM volume | | `volume_1mo_amm` | Nullable(Float64) | 30-day AMM volume | | `volume_1yr_amm` | Nullable(Float64) | 1-year AMM volume | | `volume_24hr_clob` | Nullable(Float64) | 24-hour CLOB volume | | `volume_1wk_clob` | Nullable(Float64) | 7-day CLOB volume | | `volume_1mo_clob` | Nullable(Float64) | 30-day CLOB volume | | `volume_1yr_clob` | Nullable(Float64) | 1-year CLOB volume | | `volume_amm` | Nullable(Float64) | Total AMM volume | | `volume_clob` | Nullable(Float64) | Total CLOB volume | | `liquidity` | Nullable(Float64) | Total liquidity | | `liquidity_amm` | Nullable(Float64) | AMM liquidity | | `liquidity_clob` | Nullable(Float64) | CLOB liquidity | | `maker_base_fee` | Nullable(Int64) | Maker base fee | | `taker_base_fee` | Nullable(Int64) | Taker base fee | | `custom_liveness` | Nullable(Int64) | Custom liveness period | | `is_accepting_orders` | Nullable(Bool) | Whether accepting orders | | `is_notifications_enabled` | Nullable(Bool) | Whether notifications enabled | | `score` | Nullable(Int64) | Market score/ranking | | `image_optimized` | Nullable(String) | Optimized image URL | | `icon_optimized` | Nullable(String) | Optimized icon URL | | `event` | Nullable(String) | Associated event | | `tag` | Nullable(String) | Market tag | | `category_meta` | Nullable(String) | Category metadata | | `creator` | Nullable(String) | Creator information | | `is_ready` | Nullable(Bool) | Whether market is ready | | `is_funded` | Nullable(Bool) | Whether market is funded | | `past_slugs` | Nullable(String) | Previous URL slugs | | `ready_timestamp` | Nullable(DateTime64(3)) | Ready status timestamp | | `funded_timestamp` | Nullable(DateTime64(3)) | Funded status timestamp | | `accepting_orders_timestamp` | Nullable(DateTime64(3)) | Orders acceptance timestamp | | `competitive` | Nullable(Float64) | Competitiveness score | | `rewards_min_size` | Nullable(Float64) | Minimum size for rewards | | `rewards_max_spread` | Nullable(Float64) | Maximum spread for rewards | | `spread` | Nullable(Float64) | Current bid-ask spread | | `is_automatically_resolved` | Nullable(Bool) | Whether auto-resolved | | `one_day_price_change` | Nullable(Float64) | 24-hour price change | | `one_hour_price_change` | Nullable(Float64) | 1-hour price change | | `one_week_price_change` | Nullable(Float64) | 7-day price change | | `one_month_price_change` | Nullable(Float64) | 30-day price change | | `one_year_price_change` | Nullable(Float64) | 1-year price change | | `last_trade_price` | Nullable(Float64) | Last trade price | | `best_bid` | Nullable(Float64) | Best bid price | | `best_ask` | Nullable(Float64) | Best ask price | | `is_automatically_active` | Nullable(Bool) | Whether auto-activated | | `is_clear_book_on_start` | Nullable(Bool) | Whether to clear order book on start | | `chart_color` | Nullable(String) | Chart display color | | `series_color` | Nullable(String) | Series display color | | `is_showing_gmp_series` | Nullable(Bool) | Whether showing GMP series | | `is_showing_gmp_outcome` | Nullable(Bool) | Whether showing GMP outcome | | `is_manual_activation` | Nullable(Bool) | Whether manual activation required | | `is_neg_risk_other` | Nullable(Bool) | Negative risk flag | | `game_id` | Nullable(String) | Game identifier | | `group_item_range` | Nullable(String) | Range for group item | | `sports_market_type` | Nullable(String) | Sports market type | | `line` | Nullable(Float64) | Betting line | | `uma_resolution_statuses` | Nullable(String) | UMA resolution statuses | | `is_pending_deployment` | Nullable(Bool) | Whether pending deployment | | `is_deploying` | Nullable(Bool) | Whether currently deploying | | `deploying_timestamp` | Nullable(DateTime64(3)) | Deployment timestamp | | `scheduled_deployment_timestamp` | Nullable(DateTime64(3)) | Scheduled deployment time | | `is_rfq_enabled` | Nullable(Bool) | Whether RFQ enabled | | `event_start_time` | Nullable(DateTime64(3)) | Event start datetime | | `image` | Nullable(String) | Market image URL | | `icon` | Nullable(String) | Market icon URL | | `raw_json` | String | Raw JSON response from API | | `inserted_at` | DateTime | Record insertion timestamp | ## raw_event_meta Event-level metadata: title, slug, category, dates, aggregate volume and liquidity across the event's markets. An event groups several markets - a game, an election, a recurring series. **Rows:** 2,484,405 · **Size:** 10.83 GB · **Columns:** 92 **Partition key:** none - the table is small enough to scan, but filter on a key column anyway | Column | Type | Description | |---|---|---| | `event_id` | String | Unique event identifier | | `ticker` | Nullable(String) | Event ticker symbol (URL-safe) | | `slug` | Nullable(String) | URL-friendly event slug | | `title` | Nullable(String) | Event title | | `subtitle` | Nullable(String) | Event subtitle | | `description` | Nullable(String) | Event description / resolution rules text | | `resolution_source` | Nullable(String) | Source URL/reference used for event resolution | | `start_dttm` | Nullable(DateTime64(3)) | Event start datetime | | `creation_dttm` | Nullable(DateTime64(3)) | Event creation datetime | | `end_dttm` | Nullable(DateTime64(3)) | Event end datetime | | `image` | Nullable(String) | Event image URL | | `icon` | Nullable(String) | Event icon URL | | `is_active` | Nullable(Bool) | Whether event is active | | `is_closed` | Nullable(Bool) | Whether event is closed | | `is_archived` | Nullable(Bool) | Whether event is archived | | `is_new` | Nullable(Bool) | Whether event is flagged as new | | `is_featured` | Nullable(Bool) | Whether event is featured | | `is_restricted` | Nullable(Bool) | Whether event has access restrictions (e.g., geo-blocked) | | `liquidity` | Nullable(Float64) | Total event liquidity (aggregated across markets) | | `volume` | Nullable(Float64) | Total event trading volume | | `open_interest` | Nullable(Float64) | Open interest for the event | | `sort_by` | Nullable(String) | Sort key used for event ordering | | `category` | Nullable(String) | Event category | | `subcategory` | Nullable(String) | Event subcategory | | `is_template` | Nullable(Bool) | Whether event is a template | | `template_variables` | Nullable(String) | Template variables for templated events (JSON) | | `published_at` | Nullable(String) | Publication timestamp | | `created_by` | Nullable(String) | User ID who created the event | | `updated_by` | Nullable(String) | User ID who last updated the event | | `created_dttm` | Nullable(DateTime64(3)) | Event record creation datetime | | `updated_dttm` | Nullable(DateTime64(3)) | Event record last update datetime | | `is_comments_enabled` | Nullable(Bool) | Whether comments are enabled | | `competitive` | Nullable(Float64) | Event competitiveness score | | `volume_24hr` | Nullable(Float64) | 24-hour event trading volume | | `volume_1wk` | Nullable(Float64) | 7-day event trading volume | | `volume_1mo` | Nullable(Float64) | 30-day event trading volume | | `volume_1yr` | Nullable(Float64) | 1-year event trading volume | | `featured_image` | Nullable(String) | Featured image URL | | `disqus_thread` | Nullable(String) | Disqus comment thread ID | | `parent_event` | Nullable(String) | Parent event identifier (for nested events) | | `is_enable_order_book` | Nullable(Bool) | Whether order book is enabled | | `liquidity_amm` | Nullable(Float64) | AMM liquidity for the event | | `liquidity_clob` | Nullable(Float64) | CLOB liquidity for the event | | `is_neg_risk` | Nullable(Bool) | Whether event uses negative risk markets | | `neg_risk_market_id` | Nullable(String) | Negative risk market identifier | | `neg_risk_fee_bips` | Nullable(Int64) | Negative risk fee in basis points | | `comment_count` | Nullable(Int64) | Number of comments on the event | | `image_optimized` | Nullable(String) | Optimized image URL | | `icon_optimized` | Nullable(String) | Optimized icon URL | | `featured_image_optimized` | Nullable(String) | Optimized featured image URL | | `sub_events` | Nullable(String) | JSON array of sub-events | | `markets` | Nullable(String) | JSON array of markets belonging to this event | | `series` | Nullable(String) | JSON array of series the event belongs to | | `categories` | Nullable(String) | JSON array of categories | | `collections` | Nullable(String) | JSON array of collections | | `tags` | Nullable(String) | JSON array of tags | | `is_cyom` | Nullable(Bool) | Whether event is 'create your own market' (CYOM) | | `closed_dttm` | Nullable(DateTime64(3)) | Event closing datetime | | `is_show_all_outcomes` | Nullable(Bool) | Whether to show all outcomes in UI | | `is_show_market_images` | Nullable(Bool) | Whether to show market images in UI | | `is_automatically_resolved` | Nullable(Bool) | Whether event is auto-resolved | | `is_enable_neg_risk` | Nullable(Bool) | Whether negative risk is enabled | | `is_automatically_active` | Nullable(Bool) | Whether event is auto-activated | | `event_date` | Nullable(String) | Event date string (display format) | | `start_time` | Nullable(DateTime64(3)) | Event start time | | `event_week` | Nullable(Int64) | Week number of event (for recurring events) | | `series_slug` | Nullable(String) | Slug of the series the event belongs to | | `score` | Nullable(String) | Event score (sports events) | | `elapsed` | Nullable(String) | Elapsed time string (sports events) | | `period` | Nullable(String) | Period indicator (sports events, e.g., Q1, H2) | | `is_live` | Nullable(Bool) | Whether event is currently live (sports events) | | `is_ended` | Nullable(Bool) | Whether event has ended (sports events) | | `finished_timestamp` | Nullable(DateTime64(3)) | Timestamp the event finished | | `gmp_chart_mode` | Nullable(String) | GMP chart display mode | | `event_creators` | Nullable(String) | Event creators metadata | | `tweet_count` | Nullable(Int64) | Number of associated tweets | | `chats` | Nullable(String) | Chat metadata | | `featured_order` | Nullable(Int64) | Display order when featured | | `is_estimate_value` | Nullable(Bool) | Whether value is estimated | | `is_cant_estimate` | Nullable(Bool) | Whether value cannot be estimated | | `estimated_value` | Nullable(String) | Estimated value (free-form string) | | `templates` | Nullable(String) | Templates associated with the event | | `spreads_main_line` | Nullable(Float64) | Main spread line (sports betting) | | `totals_main_line` | Nullable(Float64) | Main totals line (sports betting) | | `carousel_map` | Nullable(String) | Carousel display metadata | | `is_pending_deployment` | Nullable(Bool) | Whether event is pending deployment | | `is_deploying` | Nullable(Bool) | Whether event is currently deploying | | `deploying_timestamp` | Nullable(DateTime64(3)) | Deployment timestamp | | `scheduled_deployment_timestamp` | Nullable(DateTime64(3)) | Scheduled deployment time | | `game_status` | Nullable(String) | Game status (sports events) | | `raw_json` | String | Raw JSON response from Polymarket API | | `inserted_at` | DateTime | Record insertion timestamp | **`raw_json` is the escape hatch.** Both metadata tables keep the untouched API payload in `raw_json`. If Polymarket ships a field before we have typed it, `JSONExtract` it out of there rather than waiting on a schema change. ## What is not in the database Order-book depth is not in ClickHouse. Full book snapshots, price-level changes and best-bid/ask transitions live in a separate CLOB capture archive - see [Order-book archive](https://supanode.xyz/docs/polymarket/indexer#order-book-archive). ## Get started Provision access or start a trial: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Polymarket pricing Source: https://supanode.xyz/docs/polymarket/pricing > Polymarket Indexer pricing — flat $300/mo. Crypto-only, monthly prepaid, unlimited queries within tier limits. Trial up to 24h. One product, one flat tier. | Product | Price | | |---|---|---| | [Indexer](https://supanode.xyz/docs/polymarket/indexer) | **\$300 / mo** | indexed Polymarket history, queryable via SQL | ## Billing - **Crypto-only:** USDC · SOL · ETH · USDT. - **Monthly, prepaid.** - **Unlimited queries** within tier limits. - **Provisioning via Telegram** — manual. ## Free trial **Up to 24h.** Activate via Telegram before committing to a monthly tier. Ready to start? Reach out on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Monad overview Source: https://supanode.xyz/docs/monad/overview > Monad is a parallel-EVM chain with a gRPC feed. Two ways in: flat-rate gRPC streaming or a custom dedicated node. Monad is a parallel-EVM chain that exposes a **gRPC** feed — a real-time subscription stream of on-chain data, still uncommon among EVM networks. Supanode offers two ways to connect. ## Two products - **[gRPC Streaming](https://supanode.xyz/docs/monad/grpc)** — one flat monthly tier. Subscribe to the Monad gRPC feed and consume events with no per-request bills. Trial up to 24h. - **[Dedicated](https://supanode.xyz/docs/monad/dedicated)** — a private Monad node built to order: RPC + WS plus a gRPC endpoint, on your choice of region and hardware. Custom quote within 24h. ## Billing Crypto-only (USDC · SOL · ETH · USDT), monthly prepaid, no per-request fees on streaming. Provisioning is handled directly over Telegram. ## Next steps Flat $199/mo gRPC subscription. Private Monad node, custom quote in 24h. Full price and billing breakdown. --- ## gRPC Streaming Source: https://supanode.xyz/docs/monad/grpc > One flat tier at $199/mo for the Monad gRPC feed — full subscription stream, unlimited bandwidth, any region, direct Telegram support. One flat tier — **$199 / mo**. Monad gRPC with the full subscription stream, unlimited bandwidth, any region, and direct Telegram support. Trial up to 24h. ## What's included - **Monad gRPC** — the full real-time subscription feed. - **Full subscription stream** — subscribe and consume on-chain events in real time. - **Unlimited bandwidth** — no data caps on the stream. - **Any region** — tell us where you run. - **Direct Telegram support** — talk to the people who run the node. ## How it streams Monad exposes a gRPC feed. There is one flat monthly tier: you subscribe and consume the stream, with no per-request bills. Throughput is yours for the month — bandwidth is not metered. ## Connecting The gRPC endpoint is provisioned for you over Telegram when you subscribe. There is no public endpoint list — message [@supanode_tgs](https://telegram.me/supanode_tgs) and we set up your connection details. **Trial up to 24h, no card.** DM [@supanode_tgs](https://telegram.me/supanode_tgs), tell us what you want to test, and we'll activate a streaming trial. Ready to start? Message us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Monad dedicated Source: https://supanode.xyz/docs/monad/dedicated > A private Monad node built to order — RPC + WS, a gRPC endpoint, custom region and hardware, a direct engineer in Telegram. Custom quote within 24h. A private Monad node, built to order. Custom quote within 24h. ## What's included - **Private Monad RPC + WS** — your own endpoints, not shared. - **gRPC endpoint** — the same Monad feed, dedicated to you. - **Custom region + hardware** — provisioned where you need it, on hardware sized to your workload. - **Direct engineer in Telegram** — talk straight to the engineer who runs your node. ## How it works Dedicated configs vary by region and hardware, so there's no list price. Tell us what you need and we send an exact quote within 24h. Dedicated is built per order and is **not trial-eligible**. For a no-card trial, see [gRPC Streaming](https://supanode.xyz/docs/monad/grpc). Want a quote? Talk to us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Monad pricing Source: https://supanode.xyz/docs/monad/pricing > Monad pricing — gRPC Streaming at $199/mo flat, Dedicated by custom quote in 24h. Crypto-only, monthly prepaid, no per-request fees on streaming. | Product | Price | Notes | |---|---|---| | [gRPC Streaming](https://supanode.xyz/docs/monad/grpc) | **$199 / mo** | Flat monthly, Monad gRPC | | [Dedicated](https://supanode.xyz/docs/monad/dedicated) | **Custom quote** | Quote within 24h | ## Billing - **Crypto-only** — USDC · SOL · ETH · USDT. - **Monthly, prepaid.** - **No per-request fees on streaming** — bandwidth is not metered. - **Provisioning via Telegram** — setup is handled manually over [@supanode_tgs](https://telegram.me/supanode_tgs). ## Free trial - **gRPC Streaming:** up to 24h, no card. - **Dedicated:** built per order, **not trial-eligible**. Ready to start, or want a dedicated quote? Message us on Telegram: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## BNB Chain overview Source: https://supanode.xyz/docs/bnb/overview > Dedicated BNB Chain nodes on Supanode. EVM-compatible, private RPC + WebSocket, custom-quoted. BNB Chain is EVM-compatible, so your existing Ethereum tooling works without changes. On BNB, Supanode offers **dedicated nodes only** — there is no shared streaming or sending product here. A dedicated node gives you a private RPC and WebSocket endpoint with no rate limits, on hardware and in a region of your choice. Standard EVM stack throughout (web3.js, ethers, viem) — nothing exotic to learn. No shared streaming or sending on BNB. If you need your own private RPC, WebSocket and bandwidth, that's a dedicated node — quoted per request. ## What's here - **Dedicated nodes** — full or archive, private RPC + WS, custom region and hardware. - **Standard EVM tooling** — web3.js, ethers, viem work out of the box. - **Crypto-only billing** — monthly prepaid, no setup fees, provisioning via Telegram. ## Where to next Your own BNB node — full or archive, private RPC + WS, no rate limits. Custom quote within 24h. Crypto-only, monthly prepaid. --- ## BNB Chain dedicated Source: https://supanode.xyz/docs/bnb/dedicated > Your own BNB Chain node — full or archive, private RPC + WebSocket, no rate limits. Custom-quoted within 24h. A BNB Chain node that's only yours. Full node or archive node, private RPC and WebSocket, no rate limits — on hardware and in a region you pick. Standard EVM stack throughout. Custom-quoted, with a concrete quote within 24h. No shared neighbors, no rate limits. The full node capacity is yours. Pricing is custom — tell us your requirements and we come back with a quote within 24h. ## What you get - **Full node or archive node.** Pick what your workload needs. - **Private RPC + WS, no rate limits.** The endpoints are yours alone — no RPS or connection caps beyond what the hardware can do. - **Custom region.** Tell us where you need the node; we provision based on your geography. - **Custom hardware.** Sized to your load. - **Standard EVM stack.** web3.js, ethers, and viem work out of the box — nothing exotic. - **Direct engineer in Telegram.** Talk to the people who run your node. ## Connecting Endpoints are provisioned for you and delivered via Telegram. They speak standard EVM JSON-RPC and WebSocket, so you point your existing client at the URL we send and you're done. ```js import { JsonRpcProvider } from 'ethers'; const provider = new JsonRpcProvider('https://YOUR-ENDPOINT'); const block = await provider.getBlockNumber(); ``` ```js import { createPublicClient, http } from 'viem'; const client = createPublicClient({ transport: http('https://YOUR-ENDPOINT') }); const block = await client.getBlockNumber(); ``` ```js import Web3 from 'web3'; const web3 = new Web3('https://YOUR-ENDPOINT'); const block = await web3.eth.getBlockNumber(); ``` For streaming, point your WebSocket client at the `wss://` endpoint we provide and subscribe over standard EVM methods. ## How to get one Reach out at [@supanode_tgs](https://telegram.me/supanode_tgs) to start the conversation. Region, full vs archive, and your expected load. We come back with a concrete quote within **24h**. ## Talk to us Reach us on Telegram for a quote: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## BNB Chain pricing Source: https://supanode.xyz/docs/bnb/pricing > Dedicated BNB Chain nodes, custom-quoted within 24h. Crypto-only, monthly prepaid, no setup fees. On BNB Chain, Supanode offers dedicated nodes only — priced per request. Share your requirements and Supanode returns a concrete quote within 24h. | Product | Price | | |---|---|---| | [Dedicated Node](https://supanode.xyz/docs/bnb/dedicated) | custom quote · within 24h | full / archive · private RPC + WS · no rate limits | ## Billing - **Crypto-only** — USDC · SOL · ETH · USDT. - **Monthly, prepaid.** - **No setup fees.** - **Provisioning via Telegram** — endpoints delivered once payment is settled. There is no shared or streaming product on BNB Chain, so there is no free trial here — dedicated nodes only. ## Talk to us Reach us on Telegram for a quote: [@supanode_tgs](https://telegram.me/supanode_tgs). --- ## Glossary Source: https://supanode.xyz/docs/resources/glossary > Definitions of Solana and Supanode terms used across the documentation. Definitions for the terms that appear most often across Supanode documentation. Skim if a phrase is unfamiliar; click through for the page where the term is used in context. ## A **Allowlist.** A list of values explicitly permitted - other values are denied by default. On Supanode the term now applies mainly to [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw), where the stream is pushed only to the destination IP you register. **aRPC.** Older name for [Decoded Shreds](https://supanode.xyz/docs/solana/shreds/decoded) - decoded raw shreds delivered via Yellowstone gRPC. Same product. ## B **Bundle.** Supanode's base data-access plans (RPC + WebSocket + gRPC). Authorized by an access token. See [Plans](https://supanode.xyz/docs/solana/pricing/plans). **Bundle tiers.** Five tiers — STARTER (RPC + WebSocket, no gRPC), then FOCUS, BUILD, GROW, PROFESSIONAL (each adds more gRPC connections, WebSockets, and RPS). See [Plans](https://supanode.xyz/docs/solana/pricing/plans). ## C **ClickHouse.** The columnar database engine that powers Supanode's [Indexer](https://supanode.xyz/docs/solana/indexer/overview). Queryable via standard SQL over HTTPS. **Commitment level.** How confirmed a piece of Solana data is. From least to most reliable: `processed` → `confirmed` → `finalized`. Trade off latency vs revert risk. See [What's available (RPC)](https://supanode.xyz/docs/solana/rpc/whats-available#commitment-levels). **Compute Units (CU).** Solana's metric for transaction execution cost. Supanode mentions CU only to note it **does not bill on it**. **Credits.** Pre-paid units that some providers bill against. **Supanode doesn't use credits.** ## D **Dedicated Node.** Your own private Solana RPC node with no shared rate limits. Custom quote. See [Dedicated Node](https://supanode.xyz/docs/solana/dedicated/node). ## F **Fan-out.** When a single subscription matches a huge number of accounts or transactions, generating heavy traffic. The Solana System Program is the classic fan-out source. Supanode blocks high-fan-out programs on shared gRPC plans - see [Restrictions](https://supanode.xyz/docs/solana/grpc/restrictions). **Finalized.** Commitment level where the slot has been finalized by supermajority and cannot revert. ~13 seconds after `confirmed`. **Unfiltered block streaming.** The full gRPC `blocks` stream with no account filter - every transaction in every block. Included in the PROFESSIONAL tier. See [Unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming). ## G **Geyser.** The Solana validator plugin interface that streams account, transaction, and slot updates directly out of a validator. [Yellowstone](#y) is Triton's gRPC service built on the Geyser interface — the same "Yellowstone gRPC" Supanode exposes. **gRPC.** Google's high-performance RPC framework. Supanode exposes Solana data via the [Yellowstone](#y) gRPC interface. See [gRPC](https://supanode.xyz/docs/solana/grpc/overview). ## I **Indexer.** Supanode's decoded DEX-transaction database, queryable via SQL. $300/mo. See [Indexer](https://supanode.xyz/docs/solana/indexer/overview). **IP allowlist.** Authentication method where access is granted to specific IP addresses. Bundle plans no longer use it - they authenticate by [token](https://supanode.xyz/docs/solana/authentication). It still describes [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw), which are pushed only to a registered destination IP. ## J **Jito.** A Solana validator client and bundle-engine ecosystem that provides priority transaction landing for tipping users. Supanode's [Sender](https://supanode.xyz/docs/solana/sender/overview) routes through Jito's Bundle Engine in parallel with SWQoS. ## L **Leader.** The validator currently producing blocks. Solana's leader rotates every 4 slots. Sender forwards transactions to the **current leader** through SWQoS for fastest landing. ## M **MEV (Maximal Extractable Value).** Profit captured by reordering, inserting, or excluding transactions in a block. HFT and arbitrage workloads pursue MEV. Supanode's [unfiltered block streaming](https://supanode.xyz/docs/solana/grpc/full-block-streaming) and [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw) products are designed for MEV-class use cases. ## N **Nanosecond timestamp.** The arrival time of a transaction at Supanode's Amsterdam shred receiver, captured at nanosecond resolution and exposed through the Indexer's `tx_timestamps` table (`entry_timestamp`, joined on `slot` and `tx_idx`). Used for MEV and microstructure analysis. See [Nanosecond timestamps](https://supanode.xyz/docs/solana/indexer/nanosecond-timestamp). ## P **Processed.** Lowest commitment level - the slot has been seen but might revert. Fastest, least reliable. ## R **Raw Shreds.** Top-of-Turbine UDP shred stream, delivered to one destination IP per subscription. $200/mo per IP, Frankfurt. See [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw). **RPC.** Solana's standard JSON-RPC interface for on-demand queries. See [RPC](https://supanode.xyz/docs/solana/rpc/overview). **RPS.** Requests per second. The main Supanode rate-limit metric. Shared between RPC, WS subscribe/unsubscribe, and gRPC `SubscribeRequest` updates. ## S **Sender.** Supanode's TPU forwarding service. Pay-per-transaction via tip - no monthly subscription. See [Sender](https://supanode.xyz/docs/solana/sender/overview). **Shred.** A small fragment of a Solana block. Validators distribute shreds via the Turbine protocol. Reading shreds at the source gives the lowest possible latency for new block data. **Slot.** Solana's basic time unit. Roughly one slot every 400ms. Slots collect transactions into a block. **SOL.** The native Solana cryptocurrency. Used for transaction fees and Sender tips. **SPL token.** A fungible token on Solana issued via the Token Program. Most DeFi tokens are SPL tokens. **Stake-weighted.** A connection or routing decision where validators with more staked SOL get priority. SWQoS = Stake-Weighted Quality of Service - how Sender routes directly to the active leader. **SWQoS.** See **Stake-weighted**. ## T **Tip.** A System Program transfer from your transaction to a tip account. Required by Sender to route through Jito's bundle auction. Minimum is 1,000,000 lamports (0.001 SOL). See [Tips](https://supanode.xyz/docs/solana/sender/tips). **TPS.** Transactions per second. Counts `sendTransaction` calls separately from RPS. **TPU.** Transaction Processing Unit - the validator port that accepts transactions directly from clients. Sender forwards to the current leader's TPU through SWQoS. **Turbine.** Solana's block propagation protocol. Validators distribute shreds via Turbine; Supanode reads shreds from this layer for [Raw Shreds](https://supanode.xyz/docs/solana/shreds/raw). ## U **USDC / USDT.** Stablecoins Supanode accepts as payment. Billing is crypto-only — SOL and ETH are also accepted. ## W **WebSocket.** Persistent two-way connection over `ws://` or `wss://`. On Solana, WebSocket is used for subscription notifications (account changes, slot updates, etc.). See [WebSocket](https://supanode.xyz/docs/solana/websocket/overview). ## X **x-token.** HTTP header used to authenticate API requests. Bundle products (RPC, WebSocket, gRPC) and the [Indexer](https://supanode.xyz/docs/solana/indexer/overview) both use it; on Bundle, `Authorization: Bearer` is accepted as an equivalent. [Sender](https://supanode.xyz/docs/solana/sender/overview) uses no token; the tip on the transaction is the gate. ## Y **Yellowstone gRPC.** The open-source gRPC streaming standard for Solana, maintained by Triton One. Supanode's gRPC product implements this spec exactly. See the [official Yellowstone repo](https://github.com/rpcpool/yellowstone-grpc). --- # Supanode — site pages (agent briefs) > The marketing pages as concise, answer-first briefs. Per-page markdown is also > available by appending `.md` to any URL (the homepage is at /index.md). # Supanode > High-performance multi-chain RPC and data infrastructure for Solana, Hyperliquid, Polymarket, Monad, and BNB: JSON-RPC, Yellowstone gRPC streaming, ShredStream (UDP shreds), WebSocket feeds, stake-weighted TPU transaction landing, ClickHouse indexers, and dedicated nodes — Solana is the deepest ecosystem. A brand of Hightower LLC; provisioning is manual via Telegram, and Solana RPC/gRPC/WebSocket authenticate with an access token. ## Products - [Data Streaming](https://supanode.xyz/data-streaming) — Yellowstone-compatible gRPC + ShredStream UDP, flat-monthly Bundle plans - [Transaction Landing — TPU Sender](https://supanode.xyz/fast-transaction-sending) — stake-weighted, dual-path routing, pay-per-use via tips - [Data Analytics — Indexer](https://supanode.xyz/data-analytics) — ClickHouse SQL + REST over Solana DEX data - [Dedicated nodes](https://supanode.xyz/solutions/dedicated-rpc) — single-tenant, multi-chain, custom quote ## Ecosystems - [Solana](https://supanode.xyz/services/solana) - [Hyperliquid](https://supanode.xyz/services/hyperliquid) - [Polymarket](https://supanode.xyz/services/polymarket) - [Monad](https://supanode.xyz/services/monad) - [BNB Chain](https://supanode.xyz/services/bnb) ## FAQ **What is Supanode?** High-performance RPC and data infrastructure for Solana, Hyperliquid, Polymarket, Monad, and BNB — shared and dedicated nodes, real-time streaming, indexers, and transaction landing. A brand operated by Hightower LLC, Bishkek, Kyrgyz Republic. **What services do you offer?** Shared and dedicated RPC, gRPC streaming (Yellowstone-compatible), ShredStream, WebSocket feeds, TPU transaction landing, and ClickHouse indexers — across five ecosystems. See /services for the full catalog with limits and pricing. **Which ecosystems do you support?** Solana is the primary one. We also cover Hyperliquid, Polymarket, Monad, and BNB — coverage varies per ecosystem. Dedicated nodes for additional chains are available on request, in your region and on your hardware. See /services for the breakdown. **Why choose Supanode over other providers?** We build and trade on this infrastructure ourselves, so we know the difference between advertised and real performance. Nodes run in top-tier datacenters next to major validator clusters, plans state their limits openly, and you talk to engineers directly in Telegram. **What latency can I expect?** Nodes sit in top-tier datacenters next to major validator clusters, so in-region reads and streams arrive within single-digit milliseconds. Exact figures depend on the product and your location — each service page lists its numbers. **Do you have rate limits?** Shared plans publish their caps openly — connections and concurrent streams per plan, so the hardware is never oversold. Dedicated nodes have no rate limits: the capacity is yours alone. **Is there a free trial?** Yes — up to 24 hours on most products (Bundles, Shreds UDP, TPU, Indexer), no card required. Not available on Dedicated. Activate via Telegram. **Are there hidden fees?** No. Flat monthly subscriptions or pay-per-use tips, all listed on /pricing. Crypto-only billing, no per-request metering, no overage surprises — the price you see is the price you pay. **How do I get started?** Provisioning is manual via Telegram — message us and we match the right setup to your workload. There is no self-serve dashboard yet. **How is support handled?** Directly via Telegram, with real engineers. No ticketing system. ## Related - [Services by ecosystem](https://supanode.xyz/services) - [Pricing](https://supanode.xyz/pricing) - [Documentation](https://supanode.xyz/docs) --- Source: https://supanode.xyz/ · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Data Streaming — Supanode > Real-time Solana data: Yellowstone-compatible gRPC (a drop-in for Triton clients) and ShredStream (raw UDP shreds), packaged into flat-monthly Bundle plans. ## Key facts - **gRPC:** Yellowstone-compatible (Triton-client drop-in), unmetered bandwidth - **Shreds:** raw native shreds over UDP from the Frankfurt receiver - **Region:** Frankfurt edge - **Billing:** flat monthly, no per-request fees ## Pricing Bundle plans — see [Solana pricing](https://supanode.xyz/pricing/solana). ## Related - [Solana gRPC service](https://supanode.xyz/services/solana/grpc) - [Solana ShredStream service](https://supanode.xyz/services/solana/shredstream) - [Solana pricing](https://supanode.xyz/pricing/solana) - Docs — [gRPC docs](https://supanode.xyz/docs/solana/grpc/overview) --- Source: https://supanode.xyz/data-streaming · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Transaction Landing — TPU Sender — Supanode > A drop-in endpoint that fans each transaction over two paths at once — SWQoS direct to the upcoming leader and the Jito Block Engine — skipping the public mempool. First to land wins. Pay-per-use via tips (minimum 0.001 SOL). ## Key facts - **Routing:** dual-path: SWQoS direct + Jito Block Engine fan-out - **Integration:** drop-in — swap your RPC URL, send as before - **Billing:** pay-per-use via tips, minimum tip 0.001 SOL - **Regions:** Frankfurt (FRA), Amsterdam (AMS), Tokyo (TYO) ## Pricing Pay-per-use — see [Solana pricing](https://supanode.xyz/pricing/solana). ## Related - [Solana TPU Sender service](https://supanode.xyz/services/solana/tpu-sender) - [Solana pricing](https://supanode.xyz/pricing/solana) - Docs — [Transaction sending docs](https://supanode.xyz/docs/solana/sender/overview) --- Source: https://supanode.xyz/fast-transaction-sending · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Data Analytics — Indexer — Supanode > A ClickHouse indexer over Solana DEX activity — query wSOL flows, fills, and trader stats with ClickHouse SQL or REST. Historical data since 2024-01-17, roughly 15-second freshness, flat monthly. ## Key facts - **Interface:** ClickHouse SQL or REST - **Coverage:** Solana DEXs — Raydium, Meteora, Pump.fun, PumpSwap, LaunchLab, Letsbonk.fun - **History:** since 2024-01-17 - **Freshness:** ~15 seconds - **Auth:** user/password + x-token ## Pricing Flat monthly — see [Solana pricing](https://supanode.xyz/pricing/solana). ## Related - [Solana Indexer service](https://supanode.xyz/services/solana/indexer) - [Solana pricing](https://supanode.xyz/pricing/solana) - Docs — [Indexer docs](https://supanode.xyz/docs/solana/indexer/overview) --- Source: https://supanode.xyz/data-analytics · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # About Supanode > Supanode is a Solana-native, multi-chain RPC and data infrastructure brand operated by Hightower LLC (Bishkek, Kyrgyz Republic). Access is provisioned manually via Telegram. ## Key facts - **Operating entity:** Hightower LLC, Bishkek, Kyrgyz Republic - **Access model:** manual provisioning via Telegram + access token - **Support:** direct Telegram channel with engineers, no ticketing - **Billing:** crypto-only ## Related - [Services by ecosystem](https://supanode.xyz/services) - [Operating entity](https://supanode.xyz/operating-entity) - [Pricing](https://supanode.xyz/pricing) --- Source: https://supanode.xyz/about · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Services by ecosystem — Supanode > Supanode infrastructure across ecosystems: Solana (full stack), Hyperliquid (WebSocket + Indexer + dedicated), Monad (gRPC + dedicated), BNB Chain (dedicated), Polymarket (Indexer). Dedicated nodes for additional EVM/SVM chains on request. ## Ecosystems - [Solana](https://supanode.xyz/services/solana) — Full Solana stack from a Frankfurt edge: RPC, Yellowstone gRPC, UDP shreds, TPU landing, a ClickHouse indexer, and dedicated nodes. - [Hyperliquid](https://supanode.xyz/services/hyperliquid) — Hyperliquid from Supanode: live WebSocket streaming, a SQL trading-history indexer, and dedicated nodes. - [Polymarket](https://supanode.xyz/services/polymarket) — Polymarket from Supanode: one product — a ClickHouse SQL indexer over the full prediction-market history. Order fills, market and event metadata. - [Monad](https://supanode.xyz/services/monad) — Monad from Supanode: the native gRPC streaming feed at one flat tier, plus dedicated single-tenant nodes in any region. - [BNB Chain](https://supanode.xyz/services/bnb) — BNB Chain from Supanode: dedicated, single-tenant nodes with private RPC and WebSocket, standard EVM tooling, your region and config. ## FAQ **Do you provide dedicated nodes or only shared endpoints?** Both. Shared plans with published caps cover Solana, Hyperliquid, Monad, and Polymarket data; BNB runs dedicated-only. Dedicated nodes are built to order for any of these chains — and for additional networks on request — with a custom quote. **What uptime do you offer?** Shared infrastructure runs at 99.9% uptime over a trailing 30 days. Dedicated nodes are monitored continuously and sized to your workload, with terms agreed per setup. **Why are your nodes better than free public endpoints?** Public endpoints throttle aggressively and queue you with everyone else. Our shared plans state their caps openly, run on hardware that is never oversold, and sit in datacenters next to major validator clusters — with engineers in Telegram when something looks off. **Do you offer staked RPC endpoints with SWQoS on Solana?** Yes. Solana Staked RPC and the TPU Sender ride stake-weighted QoS with a Jito path for landing transactions — see the Solana section above for both services. **Do you build custom indexers for specific use-cases?** The ClickHouse indexers ship with ready tables for Solana DEX activity, Hyperliquid, and Polymarket. Custom tables and additional markets are scoped on request — describe the dataset in Telegram and we quote it. **Do you offer discounts for large or multi-product setups?** Sizable workloads are quoted individually — bundles already package gRPC and Shreds together, and multi-product or dedicated setups get custom terms in Telegram. ## Related - [Pricing](https://supanode.xyz/pricing) - [Documentation](https://supanode.xyz/docs) --- Source: https://supanode.xyz/services · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Pricing — Supanode > Infrastructure pricing per ecosystem — pick a network. Flat monthly with no per-request fees; TPU Sender is pay-per-use via tips; dedicated nodes are custom-quoted. ## By network - [solana pricing](https://supanode.xyz/pricing/solana) - [hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid) - [polymarket pricing](https://supanode.xyz/pricing/polymarket) - [monad pricing](https://supanode.xyz/pricing/monad) - [bnb pricing](https://supanode.xyz/pricing/bnb) ## Related - [Services by ecosystem](https://supanode.xyz/services) --- Source: https://supanode.xyz/pricing · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # FAQ — Supanode > Common questions about Supanode — ecosystems, products, billing, free trial, access, and support. ## FAQ **What is Supanode?** High-performance RPC and data infrastructure for Solana, Hyperliquid, Polymarket, Monad, and BNB — shared and dedicated nodes, real-time streaming, indexers, and transaction landing. A brand operated by Hightower LLC, Bishkek, Kyrgyz Republic. **What services do you offer?** Shared and dedicated RPC, gRPC streaming (Yellowstone-compatible), ShredStream, WebSocket feeds, TPU transaction landing, and ClickHouse indexers — across five ecosystems. See /services for the full catalog with limits and pricing. **Why choose Supanode over other providers?** We build and trade on this infrastructure ourselves, so we know the difference between advertised and real performance. Nodes run in top-tier datacenters next to major validator clusters, plans state their limits openly, and you talk to engineers directly in Telegram. **Which ecosystems do you support?** Solana is the primary one. We also cover Hyperliquid, Polymarket, Monad, and BNB — coverage varies per ecosystem. Dedicated nodes for additional chains are available on request, in your region and on your hardware. See /services for the breakdown. **How do I get started?** Provisioning is manual via Telegram — message us and we match the right setup to your workload. There is no self-serve dashboard yet. **What is Data Streaming?** gRPC (yellowstone-compatible, drop-in for Triton clients), Shreds (UDP live + Decoded coming soon), packaged into bundles. Flat monthly pricing. **What is Transaction Landing (TPU Sender)?** Sends transactions directly to upcoming leaders, skipping the public mempool. Pay-per-use via tips (minimum tip 0.001 SOL). Dual-path SWQoS + Jito. Regions: FRA, AMS, TYO. **What is Data Analytics?** An indexer over 6 Solana DEXs — Raydium, Meteora, Pump.fun, PumpSwap, LaunchLab, and Letsbonk.fun — tracking wSOL flows. Query via ClickHouse SQL or REST. Historical data since 2024-01-17, approximately 15-second freshness. Flat monthly pricing. **What is Dedicated?** Custom dedicated nodes built on demand — Solana validators plus additional EVM and SVM chains on request. Custom quote, your region and your hardware. **Do you have rate limits?** Shared plans publish their caps openly — connections and concurrent streams per plan, so the hardware is never oversold. Dedicated nodes have no rate limits: the capacity is yours alone. **What latency can I expect?** Nodes sit in top-tier datacenters next to major validator clusters, so in-region reads and streams arrive within single-digit milliseconds. Exact figures depend on the product and your location — each service page lists its numbers. **Is there a free trial?** Yes — up to 24 hours on most products (Bundles, Shreds UDP, TPU, Indexer), no card required. Not available on Dedicated. Activate via Telegram. **How does billing work?** Flat monthly subscriptions for streaming and indexer products. Pay-per-use tips for TPU transaction landing. Crypto-only. No per-request bills. **Do you charge per request?** No. Subscription products are flat monthly — no per-request or per-query metering. **Are there hidden fees?** No. Flat monthly subscriptions or pay-per-use tips, all listed on /pricing. Crypto-only billing, no per-request metering, no overage surprises — the price you see is the price you pay. **How is support handled?** Directly via Telegram, with real engineers. No ticketing system. ## Related - [Services by ecosystem](https://supanode.xyz/services) - [Pricing](https://supanode.xyz/pricing) - [Documentation](https://supanode.xyz/docs) --- Source: https://supanode.xyz/faq · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Blog — Supanode > The Supanode blog — infrastructure guides, case studies, and market insights on Solana RPC, gRPC streaming, transaction landing, indexing, and multi-chain data. ## Related - [Services by ecosystem](https://supanode.xyz/services) - [Documentation](https://supanode.xyz/docs) --- Source: https://supanode.xyz/blog · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Legal — Supanode > Legal information for Supanode, a brand of Hightower LLC — operating entity, privacy policy, and terms of service. ## Legal pages - [Operating Entity](https://supanode.xyz/operating-entity) — Hightower LLC, Bishkek, Kyrgyz Republic - [Privacy Policy](https://supanode.xyz/privacy-policy) — data privacy & non-correlation mandate ## Related - [About](https://supanode.xyz/about) --- Source: https://supanode.xyz/legal · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Privacy Policy — Supanode > Supanode privacy stance — a data-privacy and non-correlation mandate. Billing is crypto-only; access is provisioned manually over Telegram. Material changes are reflected by an updated effective date at the top of the page. ## Key facts - **Operator:** Hightower LLC - **Billing:** crypto-only - **Access:** manual provisioning via Telegram + access token ## Related - [Legal](https://supanode.xyz/legal) - [Operating entity](https://supanode.xyz/operating-entity) --- Source: https://supanode.xyz/privacy-policy · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Operating Entity — Supanode > Supanode is operated by Hightower LLC, registered in Bishkek, Kyrgyz Republic. This page is the formal operating-entity disclosure for the Supanode brand. ## Key facts - **Legal entity:** Hightower LLC - **Registered office:** Bishkek, Kyrgyz Republic - **Brand:** Supanode — operated by Hightower LLC - **Access model:** manual provisioning via Telegram + access token ## Related - [About](https://supanode.xyz/about) - [Legal](https://supanode.xyz/legal) - [Privacy Policy](https://supanode.xyz/privacy-policy) --- Source: https://supanode.xyz/operating-entity · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana infrastructure — Supanode > Full Solana stack from a Frankfurt edge: RPC, Yellowstone gRPC, UDP shreds, TPU landing, a ClickHouse indexer, and dedicated nodes. ## Network at a glance - **Slot time:** ~400 ms — New block roughly every 0.4 seconds. - **Finality:** ~12.8 s — Full economic finality, 32 slots. - **Validators:** ~795 — Independent nodes securing the network. ## Services - [Solana JSON-RPC](https://supanode.xyz/services/solana/rpc) — On-demand reads + tx submit. - [Solana Yellowstone gRPC](https://supanode.xyz/services/solana/grpc) — Live state over Yellowstone gRPC. - [Solana Dedicated Node](https://supanode.xyz/services/solana/dedicated-rpc) — Single-tenant node, your spec. - [Solana Stake-Weighted Access](https://supanode.xyz/services/solana/staked-rpc) — SWQoS straight to the leader. - [Solana Indexer](https://supanode.xyz/services/solana/indexer) — DEX activity as ClickHouse SQL. - [Solana ShredStream (UDP)](https://supanode.xyz/services/solana/shredstream) — Raw shreds over UDP, fastest path. - [Solana TPU Sender](https://supanode.xyz/services/solana/tpu-sender) — Drop-in endpoint, txns land. ## Pricing See [Solana pricing](https://supanode.xyz/pricing/solana). ## FAQ **What can I run on Solana with Supanode?** Supanode runs the full Solana stack: JSON-RPC, Yellowstone gRPC streaming, raw UDP ShredStream, a stake-weighted TPU Sender for transaction landing, a ClickHouse DEX indexer, and dedicated single-tenant nodes. Reads, live streaming, transaction sending, and analytics are all covered from a Frankfurt edge. **How do I get access to Solana on Supanode?** Provisioning is hands-on over Telegram. You message Supanode, describe your workload, and an engineer sets up your endpoint and issues your token. Solana RPC, gRPC, and WebSocket authenticate by that token; ShredStream is a UDP push to a destination IP:Port you give us; the indexer uses ClickHouse credentials plus an x-token. **Which Solana plan should I start with?** Bundle plans run from STARTER to PROFESSIONAL, with RPS from 15 to 500 and TPS from 5 to 100; gRPC connections scale from 1 to 50. The indexer and ShredStream are flat-rate monthly products. For unlimited, single-tenant capacity, a dedicated node is priced by quote within 24 hours. **Does Supanode support stake-weighted transaction landing on Solana?** Yes. The Supanode TPU Sender routes transactions over stake-weighted QoS direct to the slot leader and fans out to the Jito Bundle Engine in parallel, landing whichever path arrives first. It is a drop-in endpoint priced per transaction via the tip. **Does Solana have a mempool like Ethereum?** No — Gulf Stream forwards transactions straight to the current and upcoming slot leaders instead of holding them in a public pool. Under load, inbound bandwidth at the leader is allocated by validator stake (SWQoS), and unstaked submissions are shed first. That is why Supanode lands transactions over the stake-weighted Sender path. **What is the fastest way to receive real-time Solana data?** ShredStream — raw block fragments over UDP at 0.4 ms p99 delivery, before downstream re-emission. Most teams are better served by Yellowstone gRPC at p99 ~3.8 ms from Frankfurt: server-side filters and standard protobuf tooling, while raw shreds require decoding Turbine data yourself. **Is there a free trial on Solana products?** Yes — up to 24 hours, no card, on most products: Bundles (RPC, WebSocket, gRPC), ShredStream, and the Indexer. Dedicated nodes are built per order, so they run on a quote instead of a trial. Message Supanode on Telegram to activate one. ## Related - [All ecosystems](https://supanode.xyz/services) - [Solana pricing](https://supanode.xyz/pricing/solana) --- Source: https://supanode.xyz/services/solana · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Hyperliquid infrastructure — Supanode > Hyperliquid from Supanode: live WebSocket streaming, a SQL trading-history indexer, and dedicated nodes. ## Network at a glance - **Throughput:** ~200k/s — Orders per second on HyperCore. - **Latency:** 0.2 s — Median end-to-end; 0.9 s at p99. - **Validators:** ~24–27 — HyperBFT validator set. ## Services - [Hyperliquid WebSocket Streaming](https://supanode.xyz/services/hyperliquid/websocket) — Live orderbook over WebSocket. - [Hyperliquid Indexer](https://supanode.xyz/services/hyperliquid/indexer) — Full perp history as SQL. - [Hyperliquid Dedicated Node](https://supanode.xyz/services/hyperliquid/dedicated-rpc) — Private node, your own WS endpoint. ## Pricing See [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid). ## FAQ **What can I run on Hyperliquid with Supanode?** Supanode runs live WebSocket pub/sub streaming for the orderbook, trades, and account events; a SQL-queryable ClickHouse indexer over the full perpetual trading history; and dedicated single-tenant Hyperliquid nodes. Real-time data, historical analytics, and private capacity are all covered. **How do I get access to Hyperliquid on Supanode?** Provisioning is hands-on over Telegram. Message Supanode, say what you want to test or run, and an engineer provisions your WebSocket endpoint or indexer credentials. A free trial of up to 24 hours, no card, is available on the streaming tier. **How much does Hyperliquid infrastructure cost on Supanode?** WebSocket Streaming and the Indexer are flat monthly tiers with no per-message fees. Dedicated nodes are priced by custom quote, returned within 24 hours. **What does the Supanode Hyperliquid indexer contain?** Complete perpetual trading data: every fill, liquidation, and TWAP execution across all perpetual markets, each with nanosecond block timing, queryable directly with ClickHouse SQL or a custom REST endpoint on request. **Which Hyperliquid product should I start with?** For live market data — orderbook, trades, account events — start with WebSocket Streaming: one flat tier with a 24-hour trial. For historical analysis and backtesting, the Indexer serves the full perp history over SQL. Teams that need private capacity with no shared limits go dedicated. **What tools and languages work with Supanode Hyperliquid services?** Streaming uses Hyperliquid's native WebSocket pub/sub, so any standard WebSocket client works — Python, Node.js, Rust, Go. The Indexer speaks ClickHouse SQL and connects from DBeaver, DataGrip, psql, or the ClickHouse Python client. ## Related - [All ecosystems](https://supanode.xyz/services) - [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid) --- Source: https://supanode.xyz/services/hyperliquid · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Polymarket infrastructure — Supanode > Polymarket from Supanode: one product — a ClickHouse SQL indexer over the full prediction-market history. Order fills, market and event metadata. ## Network at a glance - **Settlement:** Polygon PoS — Markets settle on Polygon. - **Collateral:** USDC — Collateral & settlement asset. - **Resolution:** UMA oracle — Optimistic oracle resolution. ## Services - [Polymarket Indexer](https://supanode.xyz/services/polymarket/indexer) — Prediction-market data as SQL. ## Pricing See [Polymarket pricing](https://supanode.xyz/pricing/polymarket). ## FAQ **What can I run on Polymarket with Supanode?** One product: a ClickHouse SQL indexer over the full Polymarket prediction-market history — order fills, market metadata, and event metadata. Polymarket is a prediction market rather than a chain, so there is no RPC, gRPC, WebSocket streaming, or dedicated node here; the right tool is the indexer. **How do I get access to Polymarket data on Supanode?** Provisioning is hands-on over Telegram. Message Supanode, and an engineer provisions your ClickHouse credentials — host, port, username, password — for the `polymarket` database. A free trial of up to 24 hours, no card, is available before committing to the monthly tier. **How much does the Polymarket indexer cost on Supanode?** A flat monthly subscription, crypto-only and prepaid, with unlimited queries within tier limits. Custom REST endpoints around recurring queries are quoted per scope. **What is indexed for Polymarket?** Three core tables: polymarket_order_filled_v3 (~1.82B on-chain order-fill events), raw_market_meta (12.1M rows of market metadata), and raw_event_meta (2.48M rows of event metadata). Join fills to markets on asset = clob_token_id and to events on event_id to get questions, outcomes, resolution status, prices, liquidity, volume, and the executed price series. **How fresh is the Polymarket data?** The dataset refreshes continuously — new order fills and market updates flow into ClickHouse as they are indexed, while the full history stays queryable alongside the live tail. One database serves both monitoring queries and deep research. **What can I build with Polymarket data?** Odds and market-research dashboards, trader and leaderboard analytics, liquidity and volume studies, and event-driven signals — anything that joins ~1.82B order fills with market questions, outcomes, and resolution data. Because it is plain SQL, the same warehouse backs notebooks, BI tools, and production services. ## Related - [All ecosystems](https://supanode.xyz/services) - [Polymarket pricing](https://supanode.xyz/pricing/polymarket) --- Source: https://supanode.xyz/services/polymarket · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Monad infrastructure — Supanode > Monad from Supanode: the native gRPC streaming feed at one flat tier, plus dedicated single-tenant nodes in any region. ## Network at a glance - **Block time:** 400 ms — Pipelined MonadBFT blocks. - **Finality:** 800 ms — Two-block finality. - **Throughput:** 10k TPS — Target on mainnet. ## Services - [Monad gRPC Streaming](https://supanode.xyz/services/monad/grpc) — Native gRPC feed, flat tier. - [Monad Dedicated Node](https://supanode.xyz/services/monad/dedicated-rpc) — Private RPC · WS · gRPC, yours alone. ## Pricing See [Monad pricing](https://supanode.xyz/pricing/monad). ## FAQ **What can I run on Monad with Supanode?** Supanode runs Monad's native gRPC streaming feed as one flat tier, plus dedicated single-tenant nodes that include private RPC, WebSocket, and gRPC endpoints. Real-time event subscription and private node capacity are both covered. **How do I get access to Monad on Supanode?** Provisioning is hands-on over Telegram. Message Supanode, tell us your region, and an engineer provisions your gRPC endpoint. A free trial of up to 24 hours, no card, is available on the streaming tier. **How much does Monad infrastructure cost on Supanode?** Monad gRPC Streaming is a flat monthly tier with unlimited bandwidth and the full real-time subscription stream, in any region. Dedicated nodes are priced by custom quote, returned within 24 hours. **Does my Ethereum tooling work with Monad on Supanode?** Yes. Monad is EVM-compatible at the bytecode level and exposes Ethereum-compatible RPC, so web3.js, ethers, and viem work against a Supanode Monad endpoint without changes. **What is Monad and how is it different from other EVM chains?** Monad is a Layer 1 that keeps full EVM bytecode compatibility while executing transactions in parallel. The result is 400 ms blocks, 800 ms two-block finality, and a 10,000 TPS target — live on mainnet since November 2025. **What can I build with the Monad gRPC feed?** Anything that reacts to on-chain events as they happen: trading bots watching DEX activity, liquidation and risk monitors, custom indexers, and alerting pipelines. With 400 ms blocks, polling falls behind quickly — a push-based subscription stream keeps you on pace with the chain. ## Related - [All ecosystems](https://supanode.xyz/services) - [Monad pricing](https://supanode.xyz/pricing/monad) --- Source: https://supanode.xyz/services/monad · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # BNB Chain infrastructure — Supanode > BNB Chain from Supanode: dedicated, single-tenant nodes with private RPC and WebSocket, standard EVM tooling, your region and config. ## Network at a glance - **Block time:** ~0.45 s — After the Fermi upgrade. - **Finality:** ~1.125 s — Fast finality. - **Validators:** 45 — 21 Cabinet + 24 Candidate. ## Services - [BNB Chain Dedicated Node](https://supanode.xyz/services/bnb/dedicated-rpc) — Full or archive, no rate limits. ## Pricing See [BNB Chain pricing](https://supanode.xyz/pricing/bnb). ## FAQ **What can I run on BNB Chain with Supanode?** Supanode runs dedicated, single-tenant BNB Smart Chain nodes — full or archive — with private RPC and WebSocket endpoints and no rate limits beyond the hardware, in the region and configuration you choose. **How do I get access to BNB Chain on Supanode?** Provisioning is hands-on over Telegram. Tell Supanode your region, full vs archive, and expected load, and an engineer builds the node and hands over the endpoint. A concrete quote comes back within 24 hours. **Does my existing Ethereum tooling work on BNB Chain with Supanode?** Yes. BNB Smart Chain is 100% EVM-compatible, so web3.js, ethers, and viem work without changes. Supanode endpoints speak standard EVM JSON-RPC and WebSocket — point your existing client at the provisioned URL. **How is a BNB Chain dedicated node priced on Supanode?** By custom quote, per deployment, returned within 24 hours. Billing is crypto-only, monthly prepaid, with no setup fees. **When do I need a dedicated BNB Chain node instead of public endpoints?** When your workload outgrows shared infrastructure. Public endpoints throttle and shed load exactly when the chain gets busy — the worst moment for a trading system or production dApp. A dedicated node is single-tenant, with private RPC and WebSocket endpoints in your region and no limits beyond the hardware. **Is there a free trial for BNB Chain?** BNB Chain on Supanode is dedicated-only, and dedicated nodes are built per order, so they run on a custom quote rather than a trial. The quote comes back within 24 hours over Telegram, sized to your region, node type, and load. ## Related - [All ecosystems](https://supanode.xyz/services) - [BNB Chain pricing](https://supanode.xyz/pricing/bnb) --- Source: https://supanode.xyz/services/bnb · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana JSON-RPC — Supanode > Standard Solana JSON-RPC for reads and signed transactions, served from Frankfurt and included in every Bundle. ## What's included - All standard JSON-RPC methods - Commitment: processed · confirmed · finalized - Token auth: x-token or Bearer header - RPS shared with gRPC, 10s window - In every tier, STARTER → PROFESSIONAL ## Key facts - **Endpoint:** fra.sol.supanode.xyz:8899 (Frankfurt) - **RPS — STARTER / FOCUS:** 15 / 25 - **RPS — BUILD / GROW / PROFESSIONAL:** 200 / 300 / 500 - **TPS by tier:** 5 → 100 - **Aggregation window:** 10-second sliding window - **Heaviest method weight:** getProgramAccounts — 30 RPS units - **Auth:** token — x-token or Authorization: Bearer ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#bundles). ## FAQ **How is Supanode Solana RPC authenticated?** By token. You get one key when the subscription is provisioned and send it as an x-token header, or as Authorization: Bearer — both are accepted, as are x-api-key and the api-key query parameter for clients that cannot set headers. A request without a valid token is rejected with 401. **What are the RPC rate limits?** RPS scales by tier: STARTER 15, FOCUS 25, BUILD 200, GROW 300, PROFESSIONAL 500, Dedicated unlimited. TPS scales from 5 to 100. RPS is shared between RPC HTTP calls and gRPC subscribe updates, measured over a 10-second sliding window. **Do all methods cost the same against my limit?** Most methods cost 1 RPS unit. Some cost more — getProgramAccounts is 30, getTransaction and getTokenAccountsByOwner are 10. Weights are identical on every plan; only the RPS budget changes. **What is a Solana RPC endpoint?** The HTTP gateway your application uses to talk to Solana: read balances and account state, fetch transactions and blocks, simulate calls, and submit signed transactions. Supanode serves the standard JSON-RPC API from Frankfurt, so existing Solana SDKs work after swapping the URL. **Does the Bundle include WebSocket subscriptions?** Yes. Every Bundle pairs HTTP RPC with standard Solana WebSocket subscriptions, scaling from 10 concurrent connections on STARTER to 70 on PROFESSIONAL. Subscribe and unsubscribe calls count against the same RPS budget as RPC requests. **Can I query historical Solana data over RPC?** Recent history, yes — getSignaturesForAddress plus getTransaction cover lookbacks within what the network retains; there is no separate archival tier. For deep DEX history, the Supanode Indexer holds normalized swap data since 2024-01-17, queryable with ClickHouse SQL. **What happens when I hit my rate limit?** Requests over budget return HTTP 429 — nothing is queued or extra-billed. Limits are measured over a 10-second sliding window, so short bursts above the per-second average are absorbed. Regular 429s are the signal to move up a tier or to a dedicated node. **How much does Solana RPC cost?** RPC ships inside the five flat Bundle plans, STARTER through PROFESSIONAL, billed per 30 days — every tier includes WebSocket, and gRPC joins from FOCUS up. Billing is crypto-only and prepaid, each tier carries an up-to-24-hour free trial, and exact rates live on the Solana pricing page. **When should I move from shared RPC to a dedicated node?** Shared tiers cover most workloads up to 500 RPS. Move to dedicated when you need unlimited RPS and TPS, single-tenant hardware, or a region other than Frankfurt — it is quoted per deployment within 24 hours. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#bundles) - Docs — [Solana JSON-RPC docs](https://supanode.xyz/docs/solana/rpc/overview) --- Source: https://supanode.xyz/services/solana/rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana Yellowstone gRPC — Supanode > Live Solana state — accounts, txns, slots, blocks — over Triton-compatible Yellowstone gRPC. p99 ~3.8 ms from Frankfurt. ## What's included - Triton/Yellowstone-compatible (same protobuf + subscribe API) - Accounts · txns · slots · blocks, server-side filters - Unlimited, unmetered throughput - Owner-program filters scale with tier - Unfiltered block streaming (PROFESSIONAL tier) ## Key facts - **gRPC p99 latency:** 3.8 ms (60-min, Frankfurt) - **Region:** Frankfurt (FRA) only — NTT FRA2 on DE-CIX - **Concurrent subscriptions by tier:** FOCUS 1 → PROFESSIONAL 50 - **Node caps (all tiers):** 2,000 addresses per filter · 10 filters per subscription - **Throughput:** unlimited, unmetered - **Filter updates:** 30 / min on every tier - **Unfiltered block streaming:** included in PROFESSIONAL ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#bundles). ## FAQ **Is Supanode gRPC compatible with existing Yellowstone clients?** Yes. It is a drop-in replacement for Triton clients — same protobuf schemas, same subscribe API. Point your existing SDK at our endpoint and keep your code. **How is gRPC throughput billed?** Throughput is unlimited and unmetered — there is no per-MB or per-credit billing. The bundle tier sets your concurrent connections and total addresses watched; data volume on top of that is not metered. **How many gRPC subscriptions can I run at once?** Concurrent subscriptions scale by tier: FOCUS 1, BUILD 10, GROW 20, PROFESSIONAL 50, Dedicated unlimited. The quota counts Subscribe streams, not TCP connections — one connection can carry all of them. The STARTER plan does not include gRPC. **What is Yellowstone gRPC?** The streaming interface for Solana built on the Geyser plugin: instead of polling RPC, you open a stream and the node pushes account updates, transactions, slots, and blocks to you as protobuf messages over HTTP/2. It is the standard way to consume live Solana state at production volume. **When should I use gRPC instead of JSON-RPC?** Use gRPC when you watch state continuously — prices, pools, wallets, programs — because the node pushes every matching update with no polling gap. JSON-RPC stays the right tool for on-demand reads and transaction submission; most trading systems run both side by side. **What can I subscribe to, and how do filters work?** Streams cover accounts, transactions, slots, blocks, block metadata, and entries. Every stream carries a server-side filter (the unfiltered full-block firehose is a PROFESSIONAL-tier feature), and a new SubscribeRequest fully replaces the old one, so you can rewrite a live subscription on the fly, up to 30 filter updates per minute on every tier. **How many accounts can I watch at once?** Your plan sets a total ceiling across all streams: 100 on FOCUS, 5,000 on BUILD, 24,000 on GROW, 100,000 on PROFESSIONAL. There is no separate per-stream address cap, so you can spread those addresses across your streams however you like; Dedicated removes the ceiling entirely. **Can I use gRPC and JSON-RPC at the same time?** Yes — every Bundle from FOCUS up includes both, and most clients run them together: gRPC for the live feed, RPC for lookups and transaction submission. Both draw from the same RPS budget, measured over a 10-second sliding window. **What is unfiltered block streaming?** The full blocks stream with an empty account_include filter — every transaction in every block, instead of filtered slices. Included in the PROFESSIONAL tier (not a paid add-on); lower tiers use regular filtered gRPC, which stays unlimited and unmetered. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#bundles) - [Product overview](https://supanode.xyz/data-streaming) - Docs — [Solana Yellowstone gRPC docs](https://supanode.xyz/docs/solana/grpc/overview) --- Source: https://supanode.xyz/services/solana/grpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana Dedicated Node — Supanode > Single-tenant, validator-grade Solana node built to your spec — your region, hardware, integrations. Live in ~48 h, priced per deployment. ## What's included - Single-tenant bare-metal or VM - Validator-grade: gRPC · Shreds · TPU - Custom integrations + validator plugins - Your region — 10+ on request - Direct Telegram to your engineer ## Key facts - **Pricing:** custom quote, per deployment - **Quote turnaround:** within 24 hours - **Lead time:** ~48 hours from talk to deployed - **Regions on request:** 10+ locations globally - **RPS / TPS:** unlimited - **SLA:** custom ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#dedicated). ## FAQ **Why is there no list price for a dedicated Solana node?** Dedicated configs change per region, and CPU, RAM, and bandwidth availability shift weekly. Pricing is per deployment, sized to your hardware, region, and SLA, with an exact quote in 24 hours. **How long does deployment take?** Roughly 48 hours from the first Telegram message to a live, burn-in-tested endpoint. You receive the endpoint URL, a token, and a Grafana dashboard at handover. **What can run on a dedicated node?** A validator-grade Solana node with gRPC, Shreds, and TPU on infrastructure reserved entirely for your traffic, plus any custom integrations you need built as part of the setup. **Which regions are available for a dedicated Solana node?** Deployments are available in 10+ locations globally — tell Supanode the geography you need on Telegram and it is built into the 24-hour quote. Shared infrastructure runs from Frankfurt; a dedicated node is how you get Solana served from a region of your choice. **What happens to a dedicated node during network congestion?** The hardware serves only your traffic, so there are no shared rate limits and no noisy neighbors competing for capacity during mint storms or liquidation cascades. Sizing is part of the spec, and each deployment carries a custom SLA. **Who manages the node after handover?** Supanode runs it as a managed deployment — monitoring and upkeep stay on our side, with a direct Telegram line to the engineer who built it. You receive the endpoint, a token, and a Grafana dashboard, so you can watch the node yourself as well. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#dedicated) - Docs — [Solana Dedicated Node docs](https://supanode.xyz/docs/solana/dedicated/node) --- Source: https://supanode.xyz/services/solana/dedicated-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana Stake-Weighted Access — Supanode > Transactions reach slot leaders over stake-weighted QoS (SWQoS) on the Sender / TPU path, not the public mempool — how Supanode lands txns under congestion. ## What's included - SWQoS routing direct to the slot leader - Dual-path: SWQoS + Jito, first to land wins - Leader schedule tracked in real time - Pay-per-tx via tip, no subscription - Open at 5 TPS per client ## Key facts - **Routing:** stake-weighted QoS to slot leader - **Delivery paths:** SWQoS + Jito Bundle Engine (parallel) - **Landed rate:** 98.7% (24h rolling) - **Submit-to-leader p50:** 1.2 ms - **Rate limit:** 5 TPS per client - **Minimum tip:** 1,000,000 lamports (0.001 SOL) ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#tpu). ## FAQ **Is stake-weighted access a separate product?** No — stake-weighted access is how Supanode lands transactions: SWQoS routing direct to the slot leader, delivered through the Sender / TPU path. There is no separate "staked RPC" subscription. Standard reads run on JSON-RPC; transaction landing runs over the stake-weighted Sender path. **How does stake-weighted routing improve landing?** Public RPC drops transactions under load. SWQoS sends your transaction directly to the current slot leader over a stake-weighted channel, bypassing the crowded mempool. Supanode also fans out to the Jito Bundle Engine in parallel and keeps whichever path lands first. **How is it priced?** Pay-per-transaction via the tip itself — no subscription. The minimum tip is 1,000,000 lamports (0.001 SOL) per transaction. Access is open at 5 TPS per client. **What is stake-weighted QoS (SWQoS)?** A Solana mechanism that allocates inbound transaction bandwidth at the slot leader in proportion to validator stake. Connections backed by high stake keep landing under congestion while unstaked traffic is shed first. Supanode submits over stake-weighted channels, so your transactions take the prioritized lane. **Do I need to change my code to use stake-weighted access?** No. Stake-weighted access is delivered through the Sender, a drop-in endpoint: swap your RPC URL, keep your sendTransaction calls, and web3.js, Rust, Python, and Go work unchanged. Reads stay on your regular JSON-RPC endpoint; the stake-weighted path handles submission. **Which regions does the stake-weighted path run in?** Sender endpoints run in Frankfurt, Amsterdam, and Tokyo — submit to the one closest to your servers. From there Supanode tracks the leader schedule in real time and forwards over SWQoS and Jito in parallel, so you never need to chase the slot leader across regions yourself. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#tpu) - [Product overview](https://supanode.xyz/fast-transaction-sending) - Docs — [Solana Stake-Weighted Access docs](https://supanode.xyz/docs/solana/sender/overview) --- Source: https://supanode.xyz/services/solana/staked-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana Indexer — Supanode > Query indexed Solana DEX activity like a database — ClickHouse SQL or custom REST over swaps, token flows, and holders across 6 DEX, ~15s fresh. ## What's included - Direct ClickHouse SQL: joins · CTEs · window fns - DEX swaps normalized across 6 platforms - Token data: holders · mints · burns · top-N - Wallet flows: PnL · whale · smart-money - Custom REST endpoints on request ## Key facts - **Freshness:** ~15s from chain (p50 14s) - **Query p99:** 82 ms - **DEX platforms indexed:** 6 - **Tables / columns:** 21 / 463 - **Historical since:** 2024-01-17 - **Interfaces:** ClickHouse SQL + custom REST ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#analytics). ## FAQ **How do I query the Supanode Solana indexer?** Through direct ClickHouse SQL — joins, CTEs, and window functions over normalized tables — using clients like DBeaver, DataGrip, or psql. Supanode can also build a custom REST endpoint around a specific query if SQL is too low-level for your team. **Which DEX platforms are indexed?** Six: Raydium, Meteora, Pump.fun, PumpSwap, LaunchLab, and Letsbonk.fun. Swap events are normalized to one schema so you can query across DEXs in a single statement. **How fresh is the data?** About 15 seconds from chain (p50 14s), with historical coverage since 2024-01-17. That is real-time enough for analytics and bot decisioning; for execution-grade latency use streaming instead. **Can Supanode build custom endpoints or transforms?** Yes. Custom REST endpoints wrap a recurring query so your team calls an API instead of writing SQL, and Python ETL flows compute batch transformations or proprietary indicators stored as new tables. Both are quoted per scope on top of the base subscription. **Why is the indexer built on ClickHouse?** ClickHouse is a columnar database built for analytical scans over billions of rows: it reads only the columns a query touches, compresses aggressively, and parallelizes aggregations. That is what keeps query p99 at 82 ms over DEX history reaching back to January 2024. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#analytics) - [Product overview](https://supanode.xyz/data-analytics) - Docs — [Solana Indexer docs](https://supanode.xyz/docs/solana/indexer/overview) --- Source: https://supanode.xyz/services/solana/indexer · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana ShredStream (UDP) — Supanode > Raw Solana shreds — the block fragments validators send over Turbine — straight to your host over UDP. 0.4 ms p99 from the Frankfurt receiver. ## What's included - Raw UDP multicast of native shreds, no filters - Sourced from high-stake validators - Frankfurt (FRA) delivery - Delivered to a single destination IP - You give us the destination IP:Port - Decoded JSON on the roadmap ## Key facts - **Delivery latency:** 0.4 ms p99 - **Region:** Frankfurt (FRA) - **Protocol:** raw UDP multicast - **Subscription window:** 7 days minimum, 90 days maximum - **Destination IPs:** 1 per subscription - **Auth:** destination IP:Port, no token ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#shreds). ## FAQ **What is ShredStream?** A direct UDP stream of Solana shreds — the raw block fragments validators distribute over Turbine — sent to your infrastructure. Reading shreds at the source avoids the latency of RPC indexing or gRPC re-emission. **How fast is shred delivery?** 0.4 ms p99 delivery from the Supanode shred receiver in Frankfurt. The feed is native Solana shred format over raw UDP multicast, with no filters. **How is ShredStream priced and provisioned?** Rented per IP in Frankfurt, with a 7-day minimum and 90-day maximum per subscription — see pricing for the rate. It is a B2B feed; reselling requires a separate agreement. An up-to-24-hour trial is available to validate the feed. **Who should use ShredStream instead of gRPC?** Teams for whom the last milliseconds decide the trade — market makers, MEV infrastructure, latency-critical arbitrage — and who can decode raw shreds in-house. If you want filtered, structured events with standard tooling, Yellowstone gRPC at ~3.8 ms p99 is the better starting point. **What does it take to process raw shreds?** Your receiver gets native Solana shred format over UDP: you reassemble fragments into entries and transactions, including the erasure-coding recovery, typically in Rust or C++. It is advanced infrastructure work — decoded JSON is on the roadmap for teams that want shred-level latency without building the decoding layer. **Can I filter the shred feed?** No — the stream is the raw multicast of everything the receiver hears; filtering happens in your decoder after reassembly. If you only need a subset of accounts or programs, gRPC with server-side filters is usually the more practical feed. **Which regions does ShredStream cover?** Frankfurt today, with additional regions on the roadmap. The feed is rented per receiving IP, so place your host in or near Frankfurt to capture the full latency benefit. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#shreds) - [Product overview](https://supanode.xyz/data-streaming) - Docs — [Solana ShredStream (UDP) docs](https://supanode.xyz/docs/solana/shreds/raw) --- Source: https://supanode.xyz/services/solana/shredstream · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana TPU Sender — Supanode > Routes your txns straight to upcoming slot leaders over stake-weighted TPU. Lands 98.7% at 1.2 ms submit p50 — just swap your RPC URL. ## What's included - Dual-path: SWQoS direct + Jito in parallel - Drop-in — keep your sendTransaction calls - Real-time leader-schedule tracking - Pay-per-use via tips, no monthly fee - web3.js · Rust · Python · Go ## Key facts - **Landed rate:** 98.7% (24h rolling) - **Submit-to-leader p50:** 1.2 ms - **Delivery paths:** SWQoS + Jito Bundle Engine - **Regions:** FRA · AMS · TYO - **Minimum tip:** 1,000,000 lamports (0.001 SOL) - **Rate limit:** 5 TPS per client ## Pricing Flat monthly, no per-request fees — see [Solana pricing](https://supanode.xyz/pricing/solana#tpu). ## FAQ **How does the TPU Sender land transactions?** Every transaction is fanned out over two paths in parallel: stake-weighted QoS direct to the current slot leader, and the Jito Bundle Engine. Whichever lands first wins; the other is dropped. Supanode tracks the leader schedule in real time so the SWQoS path always points at the correct validator. **Do I need to change my code?** No — it is a drop-in endpoint. Swap your RPC URL for the Sender URL and keep your sendTransaction calls as they are. It works with web3.js, Rust, Python, and Go. **How is the TPU Sender priced?** Pay-per-transaction via the tip itself, with no monthly fee. The minimum tip is 1,000,000 lamports (0.001 SOL) per transaction; a higher tip buys higher priority under congestion. Access is open at 5 TPS per client. **What submission methods are supported?** Three: JSON-RPC (standard sendTransaction, the easiest drop-in), HTTP Plaintext (base64 transaction without the JSON-RPC wrapper), and HTTP Binary (raw bincode bytes up to 1,232 bytes, the lowest overhead). Pick by how much you care about latency versus simplicity. **Which region should I send to?** The one closest to your servers — Frankfurt, Amsterdam, or Tokyo. The Sender already fans out to the leader over SWQoS and Jito in parallel, so duplicating sends across regions does not improve landing; it just multiplies network load and tip risk. ## Related - [Solana services](https://supanode.xyz/services/solana) - [Solana pricing](https://supanode.xyz/pricing/solana#tpu) - [Product overview](https://supanode.xyz/fast-transaction-sending) - Docs — [Solana TPU Sender docs](https://supanode.xyz/docs/solana/sender/overview) --- Source: https://supanode.xyz/services/solana/tpu-sender · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Hyperliquid WebSocket Streaming — Supanode > Live orderbook, trades, and account events over Hyperliquid's native WebSocket pub/sub. One flat tier. ## What's included - Live orderbook over WebSocket pub/sub - Executed trades as they happen - Account-level events - Direct Telegram support ## Key facts - **Interface:** native WebSocket pub/sub - **Streams:** orderbook · trades · account events - **Free trial:** up to 24h, no card - **Auth:** endpoint provisioned via Telegram ## Pricing Flat monthly, no per-request fees — see [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid). ## FAQ **How does Supanode stream Hyperliquid data?** Hyperliquid runs on HyperBFT, and its native interface is WebSocket pub/sub. Supanode exposes it as one flat tier covering the live orderbook, trades, and account events, billed flat monthly with no per-message fees. **Is there a free trial?** Yes — up to 24 hours, no card required. Message Supanode on Telegram, say what you want to test, and the trial is activated for the WebSocket Streaming tier. **How do I connect?** Your WebSocket endpoint is provisioned for you over Telegram when you subscribe. Once provisioned, you connect over standard WebSocket and subscribe to the streams you need — orderbook, trades, account events. **Can I get historical Hyperliquid data over WebSocket?** WebSocket delivers live events from the moment you subscribe. For history, the Supanode Hyperliquid Indexer holds every fill with nanosecond block timing plus liquidation and TWAP context, queryable over ClickHouse SQL. The two pair naturally: stream live, backtest on the warehouse. **What languages and tools can I connect with?** Any standard WebSocket client — Python, Node.js, Rust, Go, even a browser. There is no proprietary SDK to install: the interface is plain pub/sub JSON, so the library you already use is the right one. ## Related - [Hyperliquid services](https://supanode.xyz/services/hyperliquid) - [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid) - [Product overview](https://supanode.xyz/data-streaming) - Docs — [Hyperliquid WebSocket Streaming docs](https://supanode.xyz/docs/hyperliquid/websocket) --- Source: https://supanode.xyz/services/hyperliquid/websocket · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Hyperliquid Indexer — Supanode > Complete perpetual trading history — 2.9B fills with nanosecond block timing, liquidation and TWAP context — in a SQL-queryable ClickHouse warehouse. ## What's included - Direct ClickHouse SQL over full history - Fills · liquidations · TWAP, nanosecond block timing - Builder codes, priority gas, maker/taker flag - Per-wallet: positions · PnL · win-rate - All perp markets, real-time refresh - Order-level book archive on request ## Key facts - **Timestamp precision:** nanosecond block time - **Fills indexed:** 2.9B (211 GB) - **Coverage:** all perpetual markets, real-time refresh - **Interfaces:** ClickHouse SQL + custom REST - **Order-book archive:** order-level, on request - **Database name:** hyperliquid - **Access:** credentials provisioned via Telegram ## Pricing Flat monthly, no per-request fees — see [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid). ## FAQ **What does the Hyperliquid indexer contain?** Complete perpetual trading data: 2.9 billion fills across all perpetual markets, each with execution price, size, position before the fill, realized PnL, fee, builder code, TWAP membership and the full liquidation triple. Block timing is nanosecond-resolution for latency and order-flow analysis. Funding rates are not part of this dataset. **How do I query it?** Through direct ClickHouse SQL using clients like DBeaver, DataGrip, or psql against the `hyperliquid` database. Supanode can also build a custom REST endpoint around a specific query on request. **How is access provisioned?** Connection details — host, port, username, password — are provisioned per customer over Telegram. The indexer is a flat monthly subscription. **Can I analyze individual wallets and build leaderboards?** Yes — fills are queryable per wallet, so positions, realized PnL, and win-rate roll up with plain SQL. Trader leaderboards, copy-trading research, and smart-money screens are the most common workloads on this dataset. **Why do nanosecond timestamps matter?** They preserve the exact ordering of fills, which is what order-flow analysis, latency studies, and execution backtests depend on. At second or millisecond precision, simultaneous fills collapse together and the sequencing information is gone. ## Related - [Hyperliquid services](https://supanode.xyz/services/hyperliquid) - [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid) - [Product overview](https://supanode.xyz/data-analytics) - Docs — [Hyperliquid Indexer docs](https://supanode.xyz/docs/hyperliquid/indexer) --- Source: https://supanode.xyz/services/hyperliquid/indexer · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Hyperliquid Dedicated Node — Supanode > Private, single-tenant Hyperliquid node with its own WebSocket endpoint, your region and hardware. Custom quote within 24 h. ## What's included - Dedicated WebSocket endpoint, reserved - Private node, no shared limits - Custom region + hardware - Direct Telegram to your engineer ## Key facts - **Pricing:** custom quote, per deployment - **Quote turnaround:** within 24 hours - **Endpoint:** dedicated WebSocket, not shared - **Region:** your choice - **Hardware:** custom, sized to your load ## Pricing Flat monthly, no per-request fees — see [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid). ## FAQ **What is a Hyperliquid dedicated node?** A private Hyperliquid node built for your workload: your own WebSocket endpoint with no shared limits, in a custom region, on custom hardware. You also get a direct line to the engineer who builds it. **How is it priced?** By custom quote, per deployment. Share your region and throughput on Telegram and Supanode returns an exact quote within 24 hours. **Is a dedicated node trial-eligible?** Dedicated is built per order, so it runs on a quote rather than a trial. The free trial applies to WebSocket Streaming; for dedicated, get a quote first. **Who needs a dedicated Hyperliquid node?** Teams whose strategy depends on private capacity: market makers and HFT desks that cannot share limits with other tenants, and heavy data consumers that want a WebSocket endpoint reserved for them alone. If the shared flat tier covers your volume, start there and upgrade when it stops fitting. ## Related - [Hyperliquid services](https://supanode.xyz/services/hyperliquid) - [Hyperliquid pricing](https://supanode.xyz/pricing/hyperliquid) - Docs — [Hyperliquid Dedicated Node docs](https://supanode.xyz/docs/hyperliquid/dedicated) --- Source: https://supanode.xyz/services/hyperliquid/dedicated-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Polymarket Indexer — Supanode > Complete prediction-market data — order fills, market and event metadata — in a SQL-queryable ClickHouse warehouse — skip indexing and just query. ## What's included - Direct ClickHouse SQL over full history - Order fills: maker/taker · side · amounts · fee · Polygon tx - Market metadata: questions · outcomes · prices · liquidity - Event metadata: titles · categories · tags · volume - Custom REST endpoints, quoted per scope ## Key facts - **Order-fill events:** ~1.82B rows (polymarket_order_filled_v3) - **Market metadata:** ~12.1M rows, 140 columns (raw_market_meta) - **Event metadata:** ~2.48M rows, 92 columns (raw_event_meta) - **History:** fills from 2022-11-21 - **Refresh:** continuous updates - **Interfaces:** ClickHouse SQL + custom REST - **Database name:** polymarket - **Free trial:** up to 24h, no card ## Pricing Flat monthly, no per-request fees — see [Polymarket pricing](https://supanode.xyz/pricing/polymarket). ## FAQ **What does the Supanode Polymarket indexer contain?** Complete prediction-market data across three core tables: polymarket_order_filled_v3 (~1.82B on-chain order-fill events from the CTF Exchange, back to November 2022), raw_market_meta (12.1M rows across 140 columns - questions, outcomes, CLOB token ids, resolution status, prices, liquidity, volume), and raw_event_meta (2.48M rows across 92 columns, grouping related markets). Because USDC and token amounts share 6 decimals, their ratio is the executed probability - the fill history is also the price history. The dataset is continuously refreshed. **How do I query it?** Through direct ClickHouse SQL against the `polymarket` database, using clients like DBeaver, DataGrip, psql, or the Python client. Supanode can also deploy custom REST endpoints around recurring queries, quoted per scope. **How is the Polymarket indexer priced and provisioned?** A flat monthly subscription, crypto-only and prepaid, with unlimited queries within tier limits. Connection details — host, port, username, password — are provisioned per customer over Telegram. A free trial of up to 24 hours is available before committing. ## Related - [Polymarket services](https://supanode.xyz/services/polymarket) - [Polymarket pricing](https://supanode.xyz/pricing/polymarket) - [Product overview](https://supanode.xyz/data-analytics) - Docs — [Polymarket Indexer docs](https://supanode.xyz/docs/polymarket/indexer) --- Source: https://supanode.xyz/services/polymarket/indexer · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Monad gRPC Streaming — Supanode > Monad's native gRPC feed as one flat tier — the full real-time subscription stream, unlimited bandwidth, any region. ## What's included - Monad's native gRPC feed - Subscribe to on-chain events in real time - Unlimited, unmetered bandwidth - Any region on request - Direct Telegram support ## Key facts - **Protocol:** native Monad gRPC - **Stream:** full real-time subscription - **Bandwidth:** unlimited, unmetered - **Region:** any, on request - **Free trial:** up to 24h, no card ## Pricing Flat monthly, no per-request fees — see [Monad pricing](https://supanode.xyz/pricing/monad). ## FAQ **What protocol does Monad streaming use?** Monad exposes its own native gRPC feed — a different schema and protocol from Solana's Yellowstone. Supanode serves it as one flat tier: subscribe and consume the full real-time stream with no per-request bills. **How is throughput billed?** Bandwidth is unlimited and unmetered for the month. The flat monthly tier covers the full subscription stream; there are no per-request or per-byte fees. **Is there a free trial?** Yes — up to 24 hours, no card. Message Supanode on Telegram, say what you want to test, and a streaming trial is activated. The gRPC endpoint itself is provisioned for you over Telegram when you subscribe. **Which regions are available for Monad gRPC?** Any region, on request — tell Supanode where your infrastructure runs and the endpoint is provisioned there. Region choice is part of the flat tier, priced the same wherever you are. ## Related - [Monad services](https://supanode.xyz/services/monad) - [Monad pricing](https://supanode.xyz/pricing/monad) - [Product overview](https://supanode.xyz/data-streaming) - Docs — [Monad gRPC Streaming docs](https://supanode.xyz/docs/monad/grpc) --- Source: https://supanode.xyz/services/monad/grpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Monad Dedicated Node — Supanode > Private Monad node built to order — your own RPC, WebSocket, and gRPC endpoints, custom hardware, your region. Custom quote within 24 h. ## What's included - Private RPC + WebSocket endpoints - Dedicated gRPC endpoint, yours alone - Custom region + hardware - Direct Telegram to your engineer ## Key facts - **Pricing:** custom quote, per deployment - **Quote turnaround:** within 24 hours - **Endpoints:** private RPC + WS + gRPC - **Region:** your choice - **Hardware:** custom, sized to your load ## Pricing Flat monthly, no per-request fees — see [Monad pricing](https://supanode.xyz/pricing/monad). ## FAQ **What does a Monad dedicated node include?** Your own private Monad RPC and WebSocket endpoints plus a dedicated gRPC endpoint — the same Monad feed, reserved entirely for you — on custom hardware in the region you pick, with a direct engineer in Telegram. **Why is there no list price?** Dedicated configs vary by region and hardware availability, so pricing is per deployment. Tell Supanode what you need on Telegram and you get an exact quote within 24 hours. EVM-family dedicated is typically lighter than a Solana node. **Is a dedicated node trial-eligible?** Dedicated is built per order and runs on a quote. For a no-card trial, use the flat Monad gRPC Streaming tier instead. **When should I choose a dedicated Monad node over the shared gRPC tier?** The shared tier is the native gRPC feed alone; dedicated adds private RPC and WebSocket endpoints plus your own gRPC on hardware reserved for you. Go dedicated when you need request-style access — reads and transaction submission — or guaranteed capacity in a specific region. For pure event streaming, the flat tier usually suffices. ## Related - [Monad services](https://supanode.xyz/services/monad) - [Monad pricing](https://supanode.xyz/pricing/monad) - Docs — [Monad Dedicated Node docs](https://supanode.xyz/docs/monad/dedicated) --- Source: https://supanode.xyz/services/monad/dedicated-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # BNB Chain Dedicated Node — Supanode > Private, single-tenant BNB Chain node — full or archive, own RPC and WebSocket, no rate limits — standard EVM stack, your region. Custom quote within 24 h. ## What's included - Full node or archive node - Private RPC + WS, no rate caps - Custom region + hardware - Standard EVM: web3.js · ethers · viem - Direct Telegram to your engineer ## Key facts - **Pricing:** custom quote, per deployment - **Quote turnaround:** within 24 hours - **Node types:** full node or archive node - **Endpoints:** private RPC + WebSocket, no rate limits - **Tooling:** standard EVM (web3.js, ethers, viem) - **Region:** your choice ## Pricing Flat monthly, no per-request fees — see [BNB Chain pricing](https://supanode.xyz/pricing/bnb). ## FAQ **What does a BNB Chain dedicated node include?** A node that is only yours — full or archive — with private RPC and WebSocket endpoints and no rate limits beyond what the hardware can do, in the region and on the hardware you pick. The standard EVM stack works out of the box. **Does my existing Ethereum tooling work?** Yes. BNB Chain is EVM-compatible, so web3.js, ethers, and viem work without changes. The endpoints speak standard EVM JSON-RPC and WebSocket — point your existing client at the URL Supanode provisions and you are done. **How is it priced?** By custom quote, per deployment. Tell Supanode your region, full vs archive, and expected load on Telegram, and you get a concrete quote within 24 hours. Billing is crypto-only, monthly prepaid, with no setup fees. **Should I order a full node or an archive node?** A full node covers current state and recent history — enough for trading, transaction submission, and event monitoring. Order an archive node when you need state at arbitrary historical blocks: balance snapshots, contract storage at a past height, deep analytics. Archive needs more storage, which the quote reflects. **Does the node support WebSocket subscriptions?** Yes — every deployment ships a private WebSocket endpoint alongside HTTP RPC. Standard EVM subscriptions such as new heads, logs, and pending transactions work with web3.js, ethers, and viem, with no rate caps beyond the hardware. ## Related - [BNB Chain services](https://supanode.xyz/services/bnb) - [BNB Chain pricing](https://supanode.xyz/pricing/bnb) - Docs — [BNB Chain Dedicated Node docs](https://supanode.xyz/docs/bnb/dedicated) --- Source: https://supanode.xyz/services/bnb/dedicated-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Infrastructure for DeFi teams — Supanode > The read-and-write path for swaps, lending, and liquidations: real-time streams for live pool and account state, priority transaction landing for liquidations under congestion, drop-in JSON-RPC, and SQL analytics over normalized DEX activity. ## What teams need - **Live pool & account state** — Quotes and health checks read true on-chain state, not a stale snapshot. - **Landing under congestion** — Liquidations and arbitrage still reach the slot leader, not the public mempool. - **DEX activity as a database** — Normalized swaps and token flows in SQL — no decoding raw program output. - **Drop-in standard interfaces** — JSON-RPC, Yellowstone gRPC, sendTransaction — no SDK rewrite. ## Products that serve it - [Yellowstone gRPC streaming](https://supanode.xyz/services/solana/grpc) — Live accounts, transactions, slots, and blocks over a Triton-compatible Geyser interface, streamed from the Frankfurt edge — react the moment pool state changes. - [TPU Sender](https://supanode.xyz/services/solana/tpu-sender) — Stake-weighted routing straight to the current slot leader, with the Jito Bundle Engine running in parallel and whichever path lands first kept. Swap your RPC URL, keep your sendTransaction calls. - [Solana JSON-RPC](https://supanode.xyz/services/solana/rpc) — Standard JSON-RPC — every method, all three commitment levels — for balances, account state, and history. Included in every Bundle plan. - [Solana indexer (ClickHouse)](https://supanode.xyz/services/solana/indexer) — Swaps across six DEX platforms, token flows, and holder distributions normalized into one ClickHouse schema — queryable in plain SQL at roughly 15 seconds of freshness. ## FAQ **What does Supanode provide for a DeFi protocol on Solana?** The full Solana read-and-write path: JSON-RPC and Yellowstone gRPC for live account and pool state, the TPU Sender for landing transactions under congestion, and a ClickHouse indexer for DEX analytics. Each is a standard interface that drops into existing Solana tooling. **Which chains does Supanode support for DeFi?** Solana has the deepest coverage: RPC, Yellowstone gRPC, ShredStream, TPU transaction landing, and a DEX indexer. Hyperliquid runs WebSocket streaming, a perpetuals indexer, and dedicated nodes; Monad has its native gRPC feed plus dedicated; BNB Chain runs as dedicated nodes. Ethereum, Base, Arbitrum, and other ecosystems are available as dedicated nodes on request. **What makes Supanode different from other RPC providers for DeFi?** The team builds and trades on this infrastructure itself, so the published numbers are the ones we depend on. Nodes run in top-tier datacenters adjacent to major validator clusters, every shared plan states its limits openly, and support is a direct Telegram channel with the engineers who run the systems. **How does Supanode help liquidations and arbitrage land under congestion?** The TPU Sender routes transactions over stake-weighted QoS directly to the current slot leader, with the Jito Bundle Engine running in parallel and whichever path lands first kept. It lands 98.7% of transactions (24h rolling) at a 1.2 ms submit-to-leader p50, bypassing the crowded public mempool. **Will a volume spike change my bill or throttle my app?** Subscriptions are flat monthly and streaming throughput is unmetered, so a volatile day moves your data volume, not your invoice. Shared tiers keep their published RPS and TPS caps, and when you need headroom beyond PROFESSIONAL, a dedicated node removes rate limits entirely. **Can I read DEX activity as a database instead of parsing raw RPC?** Yes. The Solana indexer normalizes swaps across 6 DEX platforms — Raydium, Meteora, Pump.fun, PumpSwap, LaunchLab, and Letsbonk.fun — into one ClickHouse schema, queryable with SQL joins and window functions at about 15 seconds of freshness from chain. **How do I integrate Supanode into an existing DeFi application?** Through the interfaces your stack already speaks: standard Solana JSON-RPC for reads, Triton-compatible Yellowstone gRPC for streaming, and a drop-in sendTransaction endpoint for landing — no SDK rewrite. Endpoints and your access token are provisioned over Telegram. **Can I try Supanode before committing?** Yes — most products carry a free trial of up to 24 hours, no card required, including Bundles, ShredStream, the TPU Sender, and the indexer. Message Supanode on Telegram with what you want to test and an engineer activates it. Dedicated nodes run on a quote rather than a trial. ## Related - [trading use case](https://supanode.xyz/cases/trading) - [analytics use case](https://supanode.xyz/cases/analytics) --- Source: https://supanode.xyz/cases/defi · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Infrastructure for trading teams — Supanode > A latency-first trading stack across Solana, Hyperliquid, Monad, and BNB: market data streamed ahead of the crowd, stake-weighted transaction landing, SQL history for backtesting, and dedicated nodes when the strategy scales. ## What teams need - **Earliest signal from chain** — Raw shreds at the source land ahead of RPC indexing — see the edge first. - **Straight to the leader** — Transactions reach the current slot leader over SWQoS, not the public mempool. - **Unmetered streaming** — Volatility spikes scale freely — tier sets connections and filters, no per-byte bill. - **History for backtesting** — Fill and wallet-flow data in SQL — no decoding pipeline to build. ## Products that serve it - [ShredStream (raw UDP)](https://supanode.xyz/services/solana/shredstream) — Raw Solana shreds delivered over UDP multicast from the Frankfurt receiver — the earliest possible data path, ahead of RPC indexing or gRPC re-emission. - [TPU Sender](https://supanode.xyz/services/solana/tpu-sender) — Dual-path landing: stake-weighted QoS to the current leader and the Jito Bundle Engine in parallel, whichever wins. Pay-per-use via tips, no subscription. - [Yellowstone gRPC streaming](https://supanode.xyz/services/solana/grpc) — Live accounts, transactions, slots, and blocks with server-side filters — unmetered, so a volatility spike never becomes a surprise invoice. - [Solana indexer (ClickHouse)](https://supanode.xyz/services/solana/indexer) — Normalized swaps, holder distributions, and wallet PnL in direct ClickHouse SQL — backtest and research without building a decoding pipeline. ## FAQ **Which chains does Supanode support for trading?** Solana carries the full stack: JSON-RPC, Yellowstone gRPC, ShredStream, the TPU Sender, and a DEX indexer. Hyperliquid adds live WebSocket orderbook streaming and a nanosecond-precise fills indexer, Monad runs its native gRPC feed, BNB Chain runs as dedicated nodes, and a Polymarket indexer covers prediction-market history. Ethereum, Base, Arbitrum, and other ecosystems are available as dedicated nodes on request. **What latency can I expect for trading on Solana?** ShredStream delivers raw shreds at 0.4 ms p99 and Yellowstone gRPC streams live state at 3.8 ms p99, both from the Frankfurt edge; on the write side, the TPU Sender runs a 1.2 ms submit-to-leader p50. Nodes sit adjacent to major validator clusters in top-tier datacenters, so in-region round trips stay in single-digit milliseconds. **What is the lowest-latency data path Supanode offers for trading?** ShredStream — raw Solana shreds delivered over UDP multicast at 0.4 ms p99 from the Frankfurt receiver. Reading shreds at the source avoids the latency of RPC indexing or gRPC re-emission. It is rented per IP, with a 7-day minimum and 90-day maximum subscription. **How does Supanode get transactions to the slot leader?** The TPU Sender fans every transaction out over two parallel paths: stake-weighted QoS direct to the current slot leader, and the Jito Bundle Engine. Whichever lands first wins. It tracks the leader schedule in real time and lands 98.7% of transactions at a 1.2 ms submit-to-leader p50, with a 1,000,000-lamport (0.001 SOL) minimum tip. **Is streaming throughput metered?** No. Yellowstone gRPC throughput is unlimited and unmetered — there is no per-MB or per-credit billing. The bundle tier sets concurrent connections and total addresses watched; data volume on top of that is not billed, so a volatility spike does not create a surprise invoice. **Are there rate limits for high-frequency trading?** Shared Bundle plans publish their caps openly — RPS scales 15 to 500 and TPS 5 to 100 by tier — so the hardware is never oversold. The TPU Sender is open at 5 TPS per client. For unlimited RPS and TPS, dedicated nodes have no rate limits: the hardware is reserved entirely for your traffic. **How do I migrate from my current RPC provider?** Supanode runs standard interfaces, so the change is the endpoint URL: JSON-RPC stays JSON-RPC, the gRPC feed is Triton/Yellowstone-compatible with the same protobuf and subscribe API, and the TPU Sender keeps your sendTransaction calls as they are. Provisioning is hands-on over Telegram — describe your workload, and an engineer sets up the endpoint and issues your token. **How is trading infrastructure priced?** Streaming and RPC products are flat monthly subscriptions, crypto-only, with no per-request metering — a busy month costs the same as a quiet one. The TPU Sender is pay-per-use via the tip on each transaction (minimum 0.001 SOL) with no monthly fee, and dedicated nodes are quoted per deployment. Most products carry an up-to-24-hour free trial, no card; exact rates live on the pricing pages. ## Related - [defi use case](https://supanode.xyz/cases/defi) - [analytics use case](https://supanode.xyz/cases/analytics) --- Source: https://supanode.xyz/cases/trading · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Infrastructure for analytics teams — Supanode > Query-ready blockchain data: normalized Solana DEX activity, nanosecond-precise Hyperliquid trading history, and Polymarket markets in plain ClickHouse SQL — with gRPC streams for real-time ingestion. ## What teams need - **Normalized, typed columns** — DEX swaps and token flows as typed columns, not raw base64 to decode. - **A real database interface** — Direct ClickHouse SQL — joins, CTEs, window functions an analyst already knows. - **Real-time ingestion** — Yellowstone gRPC pushes live events into a pipeline, no polling gaps. - **Depth for backfills** — Solana coverage since 2024-01-17 — range for time-series and backfills. ## Products that serve it - [Solana indexer (ClickHouse)](https://supanode.xyz/services/solana/indexer) — Swaps across six DEX platforms, token flows, holders, and wallet PnL as typed ClickHouse columns. History since 2024-01-17, about 15 seconds fresh. - [Hyperliquid indexer (ClickHouse)](https://supanode.xyz/services/hyperliquid/indexer) — Complete perpetual trading history — every fill, liquidation, and TWAP execution — each carrying nanosecond block timing, in the same ClickHouse SQL. - [Yellowstone gRPC streaming](https://supanode.xyz/services/solana/grpc) — Live accounts, transactions, slots, and blocks pushed straight into your pipeline — real-time ingestion with no polling gaps. - [ShredStream (raw UDP)](https://supanode.xyz/services/solana/shredstream) — Raw shreds over UDP — launches, liquidity events, and program activity visible before RPC or gRPC re-emit them. ## FAQ **What data can I access through Supanode for analytics?** Normalized Solana DEX swaps across 6 platforms with token flows, holder distributions, and wallet PnL; complete Hyperliquid perpetual trading history with nanosecond-stamped fills; and Polymarket prediction-market history — about 1.82B order-fill events back to November 2022, plus market and event metadata. All three are ClickHouse datasets queryable in plain SQL, and raw JSON-RPC plus live gRPC streams cover anything the indexers do not. **Do you offer indexed data or just raw RPC access?** Both. The indexers serve normalized, typed columns in ClickHouse for SQL analytics, while standard JSON-RPC handles raw on-chain reads and Yellowstone gRPC streams live events into ingestion pipelines. Many teams query the indexer for history and keep gRPC for the real-time tail. **How do I query Supanode indexed data?** Through direct ClickHouse SQL — joins, CTEs, and window functions — using clients like DBeaver, DataGrip, or psql. Supanode can also build a custom REST endpoint around a specific query if SQL is too low-level for a given team. Connection details are provisioned per customer over Telegram. **What Solana data is indexed and how fresh is it?** DEX swaps normalized across 6 platforms (Raydium, Meteora, Pump.fun, PumpSwap, LaunchLab, Letsbonk.fun), plus token holder counts, mints, burns, transfers, and wallet PnL history. Freshness is about 15 seconds from chain (p50 14s) with an 82 ms query p99, and historical coverage since 2024-01-17. **Can I get perpetual trading data for Hyperliquid?** Yes. The Hyperliquid indexer holds complete perpetual trading history — 2.9 billion fills across all perpetual markets, each with nanosecond block timing plus liquidation, TWAP and builder-code context — in the same ClickHouse SQL interface. An order-level book archive is available separately for exact-moment reconstruction. **Can I analyze multiple ecosystems from one provider?** Yes. The Solana, Hyperliquid, and Polymarket indexers run in the same ClickHouse SQL interface, so one set of tooling covers DEX activity, perpetual fills, and prediction-market history. Each dataset is provisioned with its own credentials over Telegram. **How do I feed real-time data into a live dashboard?** Yellowstone gRPC pushes accounts, transactions, slots, and blocks into your pipeline the moment they happen, with no polling gaps. For SQL-backed dashboards, the Solana indexer runs about 15 seconds behind chain with an 82 ms query p99 — fresh enough for monitoring panels without running a streaming consumer. **Will rate limits affect my data ingestion pipeline?** gRPC throughput is unlimited and unmetered, so streaming ingestion scales without a per-byte bill; the tier sets concurrent connections and total addresses watched. Shared RPC plans publish per-tier RPS caps, and indexer queries are unlimited within tier limits. Backfills heavy enough to saturate a shared tier can run on a dedicated node, which has no rate limits. ## Related - [defi use case](https://supanode.xyz/cases/defi) - [trading use case](https://supanode.xyz/cases/trading) --- Source: https://supanode.xyz/cases/analytics · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Shared RPC — Supanode > Reliable, low-latency RPC across five ecosystems: standard JSON-RPC, WebSocket, and gRPC behind published plan caps. On Solana — five Bundle tiers from STARTER to PROFESSIONAL (RPS 15 → 500), token-authenticated, flat monthly, with a 24-hour free trial. ## What's included - Solana JSON-RPC — all methods, all three commitment levels - Yellowstone gRPC from FOCUS up — Triton-compatible, unmetered - One endpoint and one token per subscription - Shared RPS budget across RPC + gRPC, 10-second sliding window - Unfiltered block streaming — included in PROFESSIONAL ## Key facts - **Tiers:** STARTER · FOCUS · BUILD · GROW · PROFESSIONAL - **RPS by tier:** 15 → 500 - **TPS by tier:** 5 → 100 - **gRPC connections by tier:** FOCUS 1 → PROFESSIONAL 50 - **Region:** Frankfurt (FRA) only — NTT FRA2 on DE-CIX - **Auth:** token — x-token or Authorization: Bearer - **Free trial:** up to 24h, no card ## Who it's for - **Building & testing Solana apps** — Tiered throughput on shared infra — pick a tier, the bill stays flat. - **Bots & backends, steady volume** — Moderate, steady request volume — no single-tenant node to pay for. - **One subscription, RPC + gRPC** — JSON-RPC and Yellowstone gRPC share one endpoint and one token. - **Indexers, explorers & dashboards** — Steady read traffic over JSON-RPC and gRPC — one endpoint, predictable monthly cost. ## Tiers (RPS / TPS / gRPC connections) - **STARTER** (SOLO): RPS 15 · TPS 5 · gRPC — - **FOCUS** (BEST $/req): RPS 25 · TPS 10 · gRPC 1 - **BUILD** (SCALE): RPS 200 · TPS 30 · gRPC 10 - **GROW** (+ SHREDS): RPS 300 · TPS 50 · gRPC 20 - **PROFESSIONAL** (MAX): RPS 500 · TPS 100 · gRPC 50 ## FAQ **What is included in a Supanode Bundle plan?** Each Bundle pairs Solana JSON-RPC with Yellowstone gRPC under one token. STARTER is RPC-only; FOCUS and above add gRPC. RPS scales by tier from 15 to 500, TPS from 5 to 100, and gRPC concurrent connections from 1 to 50, measured over a 10-second sliding window. **Which chains does shared RPC cover?** The Bundle plans are Solana: JSON-RPC plus Yellowstone gRPC from one Frankfurt edge. Other ecosystems run their own products — Hyperliquid WebSocket streaming and indexer, Monad native gRPC, a Polymarket indexer, and BNB Chain dedicated nodes — while Ethereum, Base, Arbitrum, and other chains are available as dedicated nodes on request. **How fast is shared RPC?** The shared edge runs in Frankfurt — NTT FRA2 on DE-CIX — with nodes adjacent to major validator clusters, so in-region reads return in single-digit milliseconds and gRPC streams at a 3.8 ms p99. Uptime over the trailing 30 days is 99.9%. **How is shared RPC authenticated and rate-limited?** By token — sent as x-token or Authorization: Bearer on every request. The RPS budget is shared between RPC HTTP calls and gRPC subscribe updates and measured over a 10-second sliding window. Most methods cost 1 RPS unit; heavier ones cost more (getProgramAccounts is 30). **How do I integrate shared RPC into my app?** Swap the endpoint URL. The Bundle speaks standard Solana JSON-RPC — every method, all three commitment levels — and the gRPC side is Triton/Yellowstone-compatible, so existing clients keep their code. Your endpoint and access token are provisioned over Telegram. **How is shared RPC priced?** Each tier is a flat monthly subscription, crypto-only and prepaid, with no per-request metering — only the caps (RPS, TPS, gRPC connections) change between tiers. Every tier carries an up-to-24-hour free trial, no card. Rates live on the Solana pricing page. **Can I change tiers later?** Yes. Upgrades and downgrades are arranged over Telegram and prorated against the time left on the current subscription. When PROFESSIONAL gets tight, the next step is a dedicated node with no shared budget at all. **When should I move from shared to dedicated?** When you need unlimited RPS/TPS, a private endpoint with no shared budget, or a custom region and hardware. Shared Bundles cover development and moderate production; dedicated nodes are single-tenant and built to your spec. See the Dedicated RPC solution. ## Related - [view pricing](https://supanode.xyz/pricing/solana) - [solana services](https://supanode.xyz/services/solana) --- Source: https://supanode.xyz/solutions/shared-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Dedicated RPC — Supanode > A single-tenant node built to your spec — your region, hardware, and custom integrations — with unlimited RPS and TPS. Quote in 24h, deployed in ~48h, priced per deployment. ## What's included - Single-tenant bare-metal or VM — dedicated compute and bandwidth - Validator-grade Solana node: gRPC + Shreds + TPU on your own box - Custom integrations: special RPC methods, validator plugins, pipelines - Region of your choice — 10+ locations on request - Direct Telegram channel with the engineer who deployed it ## Key facts - **Pricing:** custom quote, per deployment - **Quote turnaround:** within 24 hours - **Lead time:** ~48 hours from talk to deployed - **RPS / TPS:** unlimited - **Regions on request:** 10+ locations globally - **Chains:** Solana · Monad · Hyperliquid · BNB · more on request ## Who it's for - **Trading desks, MEV & HFT bots** — Unlimited RPS/TPS on hardware reserved entirely for your traffic. - **Production needing guaranteed capacity** — Single-tenant compute and bandwidth — predictable headroom a shared tier cannot promise. - **Teams with specific requirements** — A particular region, custom hardware, or bespoke integrations — built to spec. - **Heavy indexing & data pipelines** — Full-history backfills and high-throughput reads that would saturate a shared tier — on a box reserved for you. ## FAQ **What is a Supanode dedicated node?** A single-tenant node — bare-metal or VM — with dedicated compute and bandwidth, built to your spec. On Solana it is a validator-grade node with gRPC, Shreds, and TPU on infrastructure reserved entirely for your traffic, plus any custom integrations built as part of setup. RPS and TPS are unlimited. **How is a dedicated node different from a shared endpoint?** Shared plans place many customers on common infrastructure with published per-tier caps. A dedicated node reserves the entire machine for you: full compute and bandwidth, unlimited RPS and TPS, your choice of region and hardware, and custom integrations built in as part of the deployment. **Which chains run on a dedicated node?** Solana, Monad, Hyperliquid, and BNB Chain today, with more ecosystems built on request. Each is single-tenant with private endpoints in the region and on the hardware you choose. Per-chain dedicated details live on each ecosystem service page. **Are there rate limits on a dedicated node?** No. RPS and TPS are unlimited; the only ceiling is the hardware itself, which is sized to your workload at quote time. Shared-tier budgets, sliding windows, and method weights do not apply — the full capacity of the machine is yours. **Does a dedicated Solana node include transaction landing?** Yes. A dedicated Solana node is validator-grade and ships with gRPC, Shreds, and TPU on your own hardware, so the transaction path runs on a box reserved for your traffic. The stake-weighted TPU Sender also remains available as a drop-in, pay-per-use service alongside it. **How do I migrate from my current provider?** Each node speaks the standard interfaces of its chain — JSON-RPC, WebSocket, gRPC — so migration is pointing existing clients at the private endpoints. On EVM chains such as BNB and Monad, web3.js, ethers, and viem work without changes, and the engineer who built the node stays in your Telegram channel through the cutover. **Why is there no list price?** Dedicated configs change per region, and CPU, RAM, and bandwidth availability shift weekly. Pricing is per deployment, sized to your hardware, region, and SLA, with an exact quote within 24 hours and deployment in roughly 48 hours from the first Telegram message. **Is there a free trial for dedicated nodes?** Dedicated is built per order, so it runs on a quote rather than a trial. The up-to-24-hour free trial applies to shared products — Bundles, streaming, and indexers — which are a practical way to validate a workload before committing to dedicated hardware. ## Related - [solana dedicated](https://supanode.xyz/services/solana/dedicated-rpc) - [bnb dedicated](https://supanode.xyz/services/bnb/dedicated-rpc) --- Source: https://supanode.xyz/solutions/dedicated-rpc · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Solana pricing — Supanode > Solana infrastructure pricing — gRPC Bundle tiers (STARTER → PROFESSIONAL), ShredStream, TPU Sender, ClickHouse Indexer, and dedicated nodes. Flat monthly, no per-request fees; TPU is pay-per-use via tips. ## FAQ **What is included in a Solana Bundle plan?** Each Bundle pairs Solana JSON-RPC with Yellowstone gRPC under one token. STARTER is RPC + WebSocket only; FOCUS and above add gRPC. Across the five tiers (STARTER, FOCUS, BUILD, GROW, PROFESSIONAL), RPS scales 15 to 500, TPS 5 to 100, and gRPC connections 1 to 50. **How much do the Solana Bundle tiers cost?** Flat monthly per 30 days: STARTER $40, FOCUS $99, BUILD $159, GROW $259, PROFESSIONAL $459. Crypto-only and prepaid, with an up-to-24-hour free trial on every tier. **How is the Solana indexer priced?** A flat $300 / mo for direct ClickHouse SQL over normalized DEX activity across 6 platforms - 21 tables and 463 typed columns - with about 15-second freshness from chain. Custom REST endpoints are quoted per scope. **How is ShredStream priced?** ShredStream is $200 / mo per IP in Frankfurt, rented per IP, with a 7-day minimum and 90-day maximum per subscription. An up-to-24-hour trial is available to validate the feed. **How does TPU Sender pricing work?** Pay-per-transaction via the tip itself, with no monthly fee. The minimum tip is 1,000,000 lamports (0.001 SOL) per transaction; a higher tip buys higher priority under congestion. Access is open at 5 TPS per client. **How are dedicated Solana nodes priced?** By custom quote, per deployment — sized to your hardware, region, and SLA, with an exact quote within 24 hours and deployment in roughly 48 hours. Dedicated configs change per region, so there is no list price. ## Related - [Pricing catalog](https://supanode.xyz/pricing) - [Solana services](https://supanode.xyz/services/solana) --- Source: https://supanode.xyz/pricing/solana · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Hyperliquid pricing — Supanode > Hyperliquid infrastructure pricing — native WebSocket streaming, ClickHouse Indexer, and dedicated nodes. Flat monthly, no per-request fees. ## FAQ **How much does Hyperliquid infrastructure cost on Supanode?** WebSocket Streaming is a flat $289 / mo and the Indexer is a flat $300 / mo, both with no per-message fees. Dedicated nodes are priced by custom quote, returned within 24 hours. **What does the WebSocket tier cover?** One flat tier carrying the live orderbook, trades, and account events over Hyperliquid's native WebSocket pub/sub, billed flat monthly with no per-message billing. **What is in the Hyperliquid indexer?** Complete perpetual trading history — every fill, liquidation, and TWAP execution with nanosecond block timing — in a ClickHouse SQL warehouse, queryable directly or through a custom REST endpoint. **Is there a free trial?** Yes — up to 24 hours on the WebSocket streaming tier, no card. Dedicated runs on a quote. Trials are activated over Telegram. ## Related - [Pricing catalog](https://supanode.xyz/pricing) - [Hyperliquid services](https://supanode.xyz/services/hyperliquid) --- Source: https://supanode.xyz/pricing/hyperliquid · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Polymarket pricing — Supanode > Polymarket infrastructure pricing — prediction-market ClickHouse Indexer with SQL + REST access over full history. Flat monthly, no per-request fees. ## FAQ **How much does the Polymarket indexer cost?** A flat $300 / mo, crypto-only and monthly prepaid, with unlimited queries within tier limits. Custom REST endpoints around recurring queries are quoted per scope. **What is indexed for Polymarket?** Three core tables — about 1.82B on-chain order-fill events back to November 2022, 12.1M market-metadata rows, and 2.48M event-metadata rows — joinable for questions, outcomes, prices, liquidity, and volume, continuously refreshed. **Is there a free trial?** Yes — up to 24 hours, no card, before committing to the monthly tier. ClickHouse credentials are provisioned per customer over Telegram. ## Related - [Pricing catalog](https://supanode.xyz/pricing) - [Polymarket services](https://supanode.xyz/services/polymarket) --- Source: https://supanode.xyz/pricing/polymarket · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # Monad pricing — Supanode > Monad infrastructure pricing — native gRPC streaming and dedicated nodes. Flat monthly, no per-request fees. ## FAQ **How much does Monad streaming cost?** Monad gRPC Streaming is a flat $199 / mo with unlimited bandwidth and the full real-time subscription stream, in any region. Dedicated nodes are priced by custom quote within 24 hours. **What protocol does Monad streaming use?** Monad's own native gRPC feed — a different schema and protocol from Solana's Yellowstone. You subscribe and consume the full real-time stream with no per-request bills. **Is there a free trial?** Yes — up to 24 hours on the gRPC streaming tier, no card, activated over Telegram. The endpoint is provisioned for you when you subscribe. ## Related - [Pricing catalog](https://supanode.xyz/pricing) - [Monad services](https://supanode.xyz/services/monad) --- Source: https://supanode.xyz/pricing/monad · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs --- # BNB Chain pricing — Supanode > BNB Chain infrastructure pricing — dedicated single-tenant nodes with full EVM access. Priced per deployment on request. ## FAQ **How is a BNB Chain dedicated node priced?** By custom quote, per deployment, returned within 24 hours. Billing is crypto-only, monthly prepaid, with no setup fees. **What does a BNB Chain dedicated node include?** A single-tenant node — full or archive — with private RPC and WebSocket endpoints and no rate limits beyond the hardware, in the region and configuration you choose. **Does my existing Ethereum tooling work?** Yes. BNB Smart Chain is 100% EVM-compatible, so web3.js, ethers, and viem work without changes against the provisioned endpoint. ## Related - [Pricing catalog](https://supanode.xyz/pricing) - [BNB Chain services](https://supanode.xyz/services/bnb) --- Source: https://supanode.xyz/pricing/bnb · Supanode (operated by Hightower LLC) · Access: provisioning via Telegram @supanode_tgs