PIPE SOLANA

Use Pipe’s Solana data endpoints.

Snapshots, the ledger, shreds, account changes, the bank stream, JSON-RPC and fee analytics from Pipe’s mainnet producer, and every other Pipe Solana service. Without a key, requests get the free public tier where it covers the endpoint; a key from a paid plan raises your limits and reaches the rest. Part of it also runs on testnet, free without a key: Testnet.

Free tier change, in effect

Since October 23, 2026, downloads need a key

These routes need a key since October 23, 2026. Without one they answer 401 key_required:

Snapshots/snapshots/snapshot-<slot>-<hash>.tar.zst/snapshots/incremental-snapshot-<base>-<slot>-<hash>.tar.zst/snapshots/<archive>.tar.zst.sha256
Ledger/ledger/<slot>.bin/ledger/<slot>.json
Shreds by slot/shreds/<bucket>/<slot>.bin
Account changes/changes/<bucket>/<slot>.chg
Live shreds/shreds/live?from=<slot>
Bank stream/bank/stream?from=<slot>
Divergence debugger/debug/

The free public tier keeps only light views and APIs, at 2 requests a second per address (5 a second for JSON-RPC) and 25 GB a month per address:

Validator views
Alpenglow certificates and participation
Duplicate blocks
Fees, programs and census
Bank states
JSON-RPC
Every index, manifest and status file

The download services built on them (history, filtered snapshots, snapshot indexes, the status cache and Agave snapshots) need a key too.

To download: buy Recovery, the entry plan for downloads, or any higher stake tier in the Solana dashboard, then create a key under API keys. Send it as Authorization: Bearer psol_…, or give it to Pipe’s tools with --api-key-file FILE, PIPE_API_KEY_FILE or PIPE_API_KEY (how). The data feeds serve live shreds, account changes and the bank stream at higher speeds.

Connect

The endpoints are served from http://186.233.184.235:8080. Send a key as Authorization: Bearer psol_…, or in an X-Pipe-Key header. Indexes, manifests and status files (index.json, manifest.json, status.json) and signed attestations need no key.

export PIPE_SOLANA=http://186.233.184.235:8080
export PIPE_API_KEY='<your psol_ key>'

Check a key at any time: the answer lists its plan, its limits for each endpoint group and what it has used today and this month.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" "$PIPE_SOLANA/access/key.json"

This address answers plain HTTP today, so a key crosses the network as written. Use keys from machines you control, give each machine its own key, and revoke a key you think was exposed.

Testnet

Pipe serves Solana testnet beside mainnet, under http://186.233.184.235:8080/testnet: mainnet’s paths with /testnet in front, free and without a key. 13 services and 3 live data endpoints answer there today, each marked Testnet; every other service is mainnet only for now. Testnet’s genesis hash is 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY and its shred version 52352; its status file is /testnet/status.json.

export PIPE_SOLANA=http://186.233.184.235:8080/testnet

Free, without a key

Testnet needs no key and never counts against a plan. Its requests are outside mainnet’s free tier: they never count toward its 25 GB a month per address or its rates. Its gated paths each belong to a testnet group with its own limits per address (catalog 2026-10-30-v9):

tn_feeds (Testnet shreds): 10 requests a second, bursts of 20; 5 MiB/s per connection
tn_rpc (Testnet JSON-RPC): 5 requests a second, bursts of 20; 2 connections per address
tn_streams (Testnet streams): 2 connections per address
tn_data (Testnet views and planners): 5 requests a second, bursts of 10; 2 connections per address
tn_bootstrap (Testnet bootstrap): 5 MiB/s per connection; 4 connections per address

Indexes, manifests, status files and signed statements are ungated, as on mainnet, and so are testnet’s snapshot and bootstrap archives. On a gated path a key sent anyway is checked and served at these limits, never charged; an unknown, expired or revoked key gets 401, so testnet examples send none. tn_validator and tn_lab answer nothing without a key, and no live testnet path uses them.

JSON-RPC

POST http://186.233.184.235:8080/testnet/rpc answers getAccountInfo, getBalance, getGenesisHash, getHealth, getMinimumBalanceForRentExemption, getMultipleAccounts, getSlot, getTokenAccountBalance, getTokenSupply, and getVersion. It does not offer getTokenAccountsByOwner and getProgramAccounts (-32601). At most 8 calls a request, and at most 20 accounts (getMultipleAccounts takes at most 20 keys here: chunk by 20); answers up to 8 MiB. It takes POST only, so there are no WebSocket subscriptions on this path. Check the cluster when you connect: getGenesisHash answers 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY on testnet. A client that builds /rpc from the origin alone reaches mainnet’s free JSON-RPC instead, without an error.

curl -fsS -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getGenesisHash"}' "http://186.233.184.235:8080/testnet/rpc"

POST http://186.233.184.235:8080/testnet/transactions/rpc is the transaction history RPC: getBlock, getBlockTime, getFirstAvailableBlock, getSignaturesForAddress, getSlot, and getTransaction, at most 8 calls a request. On testnet it needs no key.

Testnet has no gRPC stream yet: mainnet’s are on ports 8081 and 8082.

Testnet’s own keys

Testnet signs with keys of its own, and every testnet statement names "cluster": "testnet". Its key directory, /testnet/attest/keys.json, lists testnet’s service keys and is signed by testnet’s attestation key, FYFj6qzV8x7Rf6qH3Mn8NfKLWdkf6RCzQErJWycHiUAs. The clusters share no key: never check a testnet statement or directory with mainnet’s key, or mainnet’s with testnet’s.

curl -fsS -o keys-testnet.json "http://186.233.184.235:8080/testnet/attest/keys.json"
pipe-attest key-directory verify keys-testnet.json --pubkey FYFj6qzV8x7Rf6qH3Mn8NfKLWdkf6RCzQErJWycHiUAs --cluster testnet

On testnet today

Testnet’s snapshots and JSON-RPC come from Pipe’s testnet bank, an unmodified Agave validator following testnet; its shred feed is an unstaked node’s share, so its slots are recoverable but rarely complete.

Use a key with Pipe’s tools

Pipe’s client tools and SDKs take the key the same way, the first one found: --api-key-file FILE, PIPE_API_KEY_FILE (a path), PIPE_API_KEY (the key itself), or a config’s api_key_file. Keep the key in a file of mode 600: a key on a command line shows in the process list.

install -D -m 600 /dev/null ~/.config/pipe/solana.key
printf '%s' 'psol_…' > ~/.config/pipe/solana.key
pipe-catchup fetch-snapshot --api-key-file ~/.config/pipe/solana.key --base http://186.233.184.235:8080 --out snapshot/
# or, for every Pipe tool in this shell:
export PIPE_API_KEY_FILE=~/.config/pipe/solana.key

The tools send the key as Authorization: Bearer only to Pipe’s origin, http://186.233.184.235:8080, unless --api-key-origin, PIPE_API_KEY_ORIGINS or a config’s api_key_origins name others. A mirror, a peer, a public RPC or a redirect to another host never gets it. A 401, 403 or 429 from the gate comes back with what to do.

They include pipe-catchup and pipe-fast-forward-runner, pipe-geo-mirror, pipe-chunk-swarm and pipe-restore-image-runner, pipe-ngsol-updater, pipe-watchdog and pipe-maintenance-planner, pipe-state-bisect and pipe-state-attest, pipe-block-validation-ctl, pipe-replay-bench-agent, pipe-program-feed, pipe-rewards-verify, pipe-boundary-rehearsal, and the Rust and Python SDKs, and the client tools below.

Client tools

Pipe’s client tools run on your own hosts beside your validator. Any key from any plan downloads them; each tool then calls only the services your plan includes. Every release has a .sha256 file and a .release.json statement, signed by the downloads key that /attest/keys.json lists for client-release: its sha256, size, target and source revision. Both are free without a key, so you can check a copy you got anywhere. /downloads/index.json lists every tool and version.

Check a tool before you run it: its sha256, then its statement through the key directory. The tools send your key only to Pipe’s origin, run no code they download, and keep consensus on your node’s own verified state: none votes on Pipe’s word. The start-up tools write files and send shreds only where you point them, and your node checks what they bring before it uses it. The vote-safety agent only alerts: it never stops, restarts or otherwise acts on your validator.

pipe-alpenglow-vectors 0.1.0
Live
Checks a downloaded vector set against the vendored reference, offline: what Pipe’s weekly refresh runs before it signs a set.
Works with Alpenglow readiness; built for x86_64-unknown-linux-gnu, 2.6 MB; sha256 27537fc6760afc208edba0f78e5a7e7928cebbda6aacf3d5af8e909528b5c35a.
- http://186.233.184.235:8080/downloads/pipe-alpenglow-vectors/0.1.0/x86_64-unknown-linux-gnu/pipe-alpenglow-vectors
- http://186.233.184.235:8080/downloads/pipe-alpenglow-vectors/0.1.0/x86_64-unknown-linux-gnu/pipe-alpenglow-vectors.sha256
- http://186.233.184.235:8080/downloads/pipe-alpenglow-vectors/0.1.0/x86_64-unknown-linux-gnu/pipe-alpenglow-vectors.release.json
pipe-bootstrap 0.1.0
Live
Lays out the fastboot files from the converted archives, checking every frame, then starts your validator, which verifies its own lattice hash and falls back to the archives on any mismatch. Pinned client versions only.
Works with Bootstrap artifacts; built for x86_64-unknown-linux-gnu, 8.1 MB; sha256 c067899648f1983ed7f48dd3d07cb917dfd3e4331afd8fcce77d52a904623591.
- http://186.233.184.235:8080/downloads/pipe-bootstrap/0.1.0/x86_64-unknown-linux-gnu/pipe-bootstrap
- http://186.233.184.235:8080/downloads/pipe-bootstrap/0.1.0/x86_64-unknown-linux-gnu/pipe-bootstrap.sha256
- http://186.233.184.235:8080/downloads/pipe-bootstrap/0.1.0/x86_64-unknown-linux-gnu/pipe-bootstrap.release.json
pipe-fast-catchup 0.1.0
Live
Fetches a signed Agave incremental over the Pipe full your node kept, checks it against its statement and installs it; your node verifies the state itself at start. The key goes only to Pipe’s origin.
Works with Fast catch-up; built for x86_64-unknown-linux-gnu, 8.5 MB; sha256 25c8500e9951524a40d01539d04792bd62783cd953bc2c4c29edefa605803293.
- http://186.233.184.235:8080/downloads/pipe-fast-catchup/0.1.0/x86_64-unknown-linux-gnu/pipe-fast-catchup
- http://186.233.184.235:8080/downloads/pipe-fast-catchup/0.1.0/x86_64-unknown-linux-gnu/pipe-fast-catchup.sha256
- http://186.233.184.235:8080/downloads/pipe-fast-catchup/0.1.0/x86_64-unknown-linux-gnu/pipe-fast-catchup.release.json
pipe-host-audit 0.1.0
Live
A read-only check of your validator’s host (kernel, NIC, clock, disk, memory pressure). It sends nothing unless you opt in to upload a summary, which carries no hostname, address, path or key.
Works with Is it me or the network?; built for x86_64-unknown-linux-gnu, 11.1 MB; sha256 f4b65d2394ecfa63ebb748e4c6cdad97ec45f27b282f947fe44198ad31e65c99.
- http://186.233.184.235:8080/downloads/pipe-host-audit/0.1.0/x86_64-unknown-linux-gnu/pipe-host-audit
- http://186.233.184.235:8080/downloads/pipe-host-audit/0.1.0/x86_64-unknown-linux-gnu/pipe-host-audit.sha256
- http://186.233.184.235:8080/downloads/pipe-host-audit/0.1.0/x86_64-unknown-linux-gnu/pipe-host-audit.release.json
pipe-onboard 0.1.1
Live
Brings your validator to voting, for a new key, a restart or a cluster restart: the snapshot, the catch-up and the onboarding plan from Pipe, each checked by your node, then it starts your validator’s own service. Consensus stays on your node’s own verified state: it never votes on anything it has not executed itself.
Works with Onboarding (Fast start); built for x86_64-unknown-linux-gnu, 11.7 MB; sha256 7aedbf0f094caf966354c8cc32f479095beaef06e42258c9ea1a9b4844a94d3b.
- http://186.233.184.235:8080/downloads/pipe-onboard/0.1.1/x86_64-unknown-linux-gnu/pipe-onboard
- http://186.233.184.235:8080/downloads/pipe-onboard/0.1.1/x86_64-unknown-linux-gnu/pipe-onboard.sha256
- http://186.233.184.235:8080/downloads/pipe-onboard/0.1.1/x86_64-unknown-linux-gnu/pipe-onboard.release.json
pipe-shred-feeder 0.1.0
Live
Feeds the slots since your snapshot into your node’s TVU on loopback, checking each against a signed manifest and its leader’s signature. It never votes, signs or touches the identity, tower or ledger: your node replays every block itself.
Works with Catch-up shreds; built for x86_64-unknown-linux-gnu, 8.9 MB; sha256 4f85f55960e3d6f2e18f78a1166f06d9c1e4e4f6b41471fc407ae9598c792711.
- http://186.233.184.235:8080/downloads/pipe-shred-feeder/0.1.0/x86_64-unknown-linux-gnu/pipe-shred-feeder
- http://186.233.184.235:8080/downloads/pipe-shred-feeder/0.1.0/x86_64-unknown-linux-gnu/pipe-shred-feeder.sha256
- http://186.233.184.235:8080/downloads/pipe-shred-feeder/0.1.0/x86_64-unknown-linux-gnu/pipe-shred-feeder.release.json
pipe-standby-agent 0.1.0
Live
Runs beside each of your nodes (primary and standby): checks health, holds or waits for the fence’s voting lease, and switches the identity (Agave and Jito-Solana through their admin RPC, Frankendancer through fdctl, ngSol through its control directory) only with a current fencing token, so one node votes at a time. Your keys stay on your machines; the fence holds none.
Works with Managed standby; built for x86_64-unknown-linux-gnu, 7.4 MB; sha256 2f98f798d812907e52f5c884cbe5ad3f6b74efdc9fba51bcc8ba740c501d402d.
- http://186.233.184.235:8080/downloads/pipe-standby-agent/0.1.0/x86_64-unknown-linux-gnu/pipe-standby-agent
- http://186.233.184.235:8080/downloads/pipe-standby-agent/0.1.0/x86_64-unknown-linux-gnu/pipe-standby-agent.sha256
- http://186.233.184.235:8080/downloads/pipe-standby-agent/0.1.0/x86_64-unknown-linux-gnu/pipe-standby-agent.release.json
pipe-vote-guard-agent 0.1.0
Live
Runs beside your validator and compares its bank hash with Pipe’s signed verdict each slot. Fail-open: an unknown or unverifiable answer, or Pipe unreachable, never counts. It only alerts, on a confirmed divergence or a node that stops advancing: it never stops, restarts or otherwise acts on your validator.
Works with Vote-safety guard; built for x86_64-unknown-linux-gnu, 11 MB; sha256 29954c09810cc831231c5f34861a356fe56682729f7d74e389fc83aab58e3844.
- http://186.233.184.235:8080/downloads/pipe-vote-guard-agent/0.1.0/x86_64-unknown-linux-gnu/pipe-vote-guard-agent
- http://186.233.184.235:8080/downloads/pipe-vote-guard-agent/0.1.0/x86_64-unknown-linux-gnu/pipe-vote-guard-agent.sha256
- http://186.233.184.235:8080/downloads/pipe-vote-guard-agent/0.1.0/x86_64-unknown-linux-gnu/pipe-vote-guard-agent.release.json

curl -fsS -H "Authorization: Bearer psol_…" -O "http://186.233.184.235:8080/downloads/pipe-alpenglow-vectors/0.1.0/x86_64-unknown-linux-gnu/pipe-alpenglow-vectors"
curl -fsS -O "http://186.233.184.235:8080/downloads/pipe-alpenglow-vectors/0.1.0/x86_64-unknown-linux-gnu/pipe-alpenglow-vectors.sha256"
curl -fsS -O "http://186.233.184.235:8080/downloads/pipe-alpenglow-vectors/0.1.0/x86_64-unknown-linux-gnu/pipe-alpenglow-vectors.release.json"
sha256sum -c pipe-alpenglow-vectors.sha256
curl -fsS -o keys.json "http://186.233.184.235:8080/attest/keys.json"
pipe-attest verify keys.json --pubkey 4Kf16X3Fvvhy3W43jCUbkT1KxWhfPRZfkR3dZm95xQRB
pipe-attest key-directory check pipe-alpenglow-vectors.release.json --directory keys.json --kind client-release
test "$(jq -r .statement.sha256 pipe-alpenglow-vectors.release.json)" = "$(sha256sum < pipe-alpenglow-vectors | cut -d' ' -f1)" && chmod +x pipe-alpenglow-vectors

Verification

Pipe signs what it vouches for: snapshot archives and their chunk lists, bank-hash checkpoints, account-state attestations, history, program changes, scorecards, readiness, startup plans, webhooks and more. Each service signs with a key of its own.

The key directory, /attest/keys.json, lists every service’s key: the service, its public key, the kinds of statement it signs, when the key is valid and whether it was revoked. The directory is signed by Pipe’s main attestation key, 4Kf16X3Fvvhy3W43jCUbkT1KxWhfPRZfkR3dZm95xQRB, and is served without an API key. A client verifies in one of two ways:

Trust only the main key. Verify the directory under the main key, then accept a statement whose signer the directory lists for that statement’s kind, valid when it signed and not revoked before.
Pin a service’s key. Verify that service’s statements under its own key, and read the directory for revocations when online.

curl -fsS -o keys.json "$PIPE_SOLANA/attest/keys.json"
pipe-attest verify keys.json --pubkey 4Kf16X3Fvvhy3W43jCUbkT1KxWhfPRZfkR3dZm95xQRB

The Python SDK does both: KeyDirectory.fetch(base, key) verifies the directory and verify_statement(envelope, kind) checks a statement against it; keys.verify_pinned pins a service key.

Plans, keys and billing

Plans are prepaid 30-day periods, paid from your infrastructure credit. Stake tiers share one line: you hold one tier at a time, and a tier bought while another runs starts when the current period ends. Each data feed and each add-on is a line of its own: hold any combination, beside a tier or alone. Validator Ops comes in three sizes by the total active stake of the validators it covers; hold the one that fits. Client Lab gives each key monthly job quotas. Fast start holds one key: the line of the validator you bring up or restart. Managed standby covers one validator, with two keys for its primary and standby hosts. An add-on sold beside a stake tier can be bought only while you hold a current tier (or with one in the same checkout), and serves only while one is current. The dashboard buys a tier, feeds and add-ons in one checkout, one purchase per line, each confirmed on its own. Buying the same plan again extends its line; nothing renews by itself, and periods can be prepaid up to a year ahead.

A key serves one line for its whole life. A stake-tier key follows your current tier; a feed or add-on key serves only its own plan’s endpoint groups, so each feed you hold needs its own key, and so does each add-on: with a tier, two feeds and Validator Ops, create four keys. Rate limits and monthly quotas, Client Lab’s job quotas among them, apply to each key, and each plan includes a number of active keys. A key works while its line has a paid period; requests without a key get the free public tier where it applies. Keys last 30 to 730 days, and a revoked key stops working within about 30 seconds.

Overage is off unless you set a monthly cap. With a cap, a key that has used its monthly quota keeps working at the published per-GiB rate until the cap for that UTC month is reached. Every purchase and cap change needs your explicit consent, and a retried purchase never charges twice.

Open Solana data to buy a plan, create keys and see usage, or compare plans and prices.

Endpoints

Each endpoint belongs to an access group, and each plan names the groups its keys reach: a stake-tier key reaches the groups its tier includes, a feed or add-on key only its own. Each service’s page lists the plans that include it. Replace <slot> and the other placeholders with values from the index files.

Snapshots

Access group snapshots

Full and incremental snapshot archives from Pipe’s mainnet producer, each with a SHA-256 file. The index lists them with their slots, hashes and sizes.

/snapshots/index.json
/snapshots/snapshot-<slot>-<hash>.tar.zst
/snapshots/incremental-snapshot-<base>-<slot>-<hash>.tar.zst
/snapshots/<archive>.tar.zst.sha256

Mainnet only for now.

curl -fsS "$PIPE_SOLANA/snapshots/index.json" | jq -r '.snapshots[0].url'
curl -fL -C - -H "Authorization: Bearer $PIPE_API_KEY" -O "$PIPE_SOLANA/snapshots/snapshot-<slot>-<hash>.tar.zst"

Ledger

Access group ledger

Every shred the producer stored for a rooted slot, after erasure recovery and repair, with a JSON summary beside it.

/ledger/index.json
/ledger/<slot>.bin
/ledger/<slot>.json

Mainnet only for now.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" -o <slot>.bin "$PIPE_SOLANA/ledger/<slot>.bin"

Shreds by slot

Access group shreds

Per-slot shred files for catching up to the tip. <bucket> is the slot divided by 1,000, rounded down.

/shreds/index.json
/shreds/<bucket>/manifest.json
/shreds/<bucket>/<slot>.bin

Testnet Free without a key: /testnet/shreds/index.json, /testnet/shreds/<bucket>/manifest.json, /testnet/shreds/<bucket>/<slot>.bin. About testnet.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" -o <slot>.bin "$PIPE_SOLANA/shreds/<bucket>/<slot>.bin"

Live shreds

Access group live

A stream of the newest shreds from <slot> on: frames of slot (u64), length (u16) and shred bytes, little-endian. A zero-length frame is a heartbeat.

/shreds/live?from=<slot>

Testnet Free without a key: /testnet/shreds/live?from=<slot>. About testnet.

curl -fsS -N -H "Authorization: Bearer $PIPE_API_KEY" "$PIPE_SOLANA/shreds/live?from=<slot>" > live.bin

Account changes

Access group changes

One zlib-compressed batch of account changes per rooted slot, with the inputs to its bank hash.

/changes/index.json
/changes/<bucket>/manifest.json
/changes/<bucket>/<slot>.chg

Mainnet only for now.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" -o <slot>.chg "$PIPE_SOLANA/changes/<bucket>/<slot>.chg"

Bank stream

Access group stream

Server-Sent Events with the producer’s bank hash for each slot beside mainnet’s, for divergence alerts. Reconnect with Last-Event-ID to resume.

/bank/stream?from=<slot>

Mainnet only for now.

curl -fsS -N -H "Authorization: Bearer $PIPE_API_KEY" "$PIPE_SOLANA/bank/stream?from=<slot>"

Bank states

Access group bank

The same per-slot states for up to 1,000 slots at a time. The status file is free.

/bank/stream.json?from=<slot>&to=<slot>
/bank/stream/status.json

Mainnet only for now.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" "$PIPE_SOLANA/bank/stream.json?from=<slot>&to=<slot>"

JSON-RPC

Access group rpc

Solana JSON-RPC methods answered from Pipe’s execution of mainnet.

POST /rpc

Testnet Free without a key: POST /testnet/rpc. About testnet.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}' "$PIPE_SOLANA/rpc"

Fees and programs

Access group analytics

Compute-unit prices, utilization, fees and contended accounts by slot, and the programs mainnet invoked. The program index is free.

/fees/recent.json
/fees/slots.json?from=<slot>&to=<slot>
/fees/accounts.json?window=150
/programs/index.json
/programs/elf/<sha256>.so

Mainnet only for now.

curl -fsS -H "Authorization: Bearer $PIPE_API_KEY" "$PIPE_SOLANA/fees/recent.json"

Services

Every Pipe Solana service, its status and its endpoints. Each has a page with a curl example, the plans that include it and their limits; the services directory lists them all. A service that is coming soon answers once its rollout batch opens.

Data

Account historyLive
An account as of any slot in the change feed's window, and every write to it, from Pipe's own execution. The index is free.
- /accounts/index.json
- /accounts/<pubkey>?slot=<slot>
- /accounts/<pubkey>/history?from=<slot>&to=<slot>
Account streamLive
Writes to the accounts you filter, slot by slot, as Server-Sent Events or Yellowstone gRPC at finalized commitment. Resume with Last-Event-ID or from_slot.
- /accounts/stream?account=<pubkey>&owner=<pubkey>
- POST /accounts/stream
- /accounts/stream/status.json
- gRPC 186.233.184.235:8081 geyser.Geyser/Subscribe
The gRPC stream takes the key in an x-token header, as Yellowstone clients send it, or as Authorization: Bearer psol_….
TransactionsLiveTestnet
Agave-compatible JSON-RPC for the last ~8 hours of rooted transactions, with Pipe's replay results, and a Yellowstone gRPC transaction stream.
- POST /transactions/rpc
- /transactions/status.json
- gRPC 186.233.184.235:8082 geyser.Geyser/Subscribe
The gRPC stream takes the key in an x-token header, as Yellowstone clients send it, or as Authorization: Bearer psol_….
- POST /testnet/transactions/rpc
Long-term historyLive
Shred and account-change slot files kept beyond the live feeds' window, byte-identical to the feeds and signed by Pipe's history key.
Its statements are signed by its own service key, listed in /attest/keys.json.
- /history/index.json
- /history/slots.json?from=<slot>&to=<slot>
- /history/slot/<slot>.bin
- /history/changes/<slot>.chg
Program changesLive
Every program deploy, upgrade and close on mainnet, signed, with the exact ELF bytes and a hot list, as JSON pages or a live stream.
Its statements are signed by its own service key, listed in /attest/keys.json.
- /programs/feed/index.json
- /programs/feed/events.json?after=<seq>&limit=100
- /programs/feed/stream
- /programs/feed/hot.json
- /programs/feed/elf/<sha256>.so
Status cacheLive
The status cache and blockhash queue of the newest rooted banks, so a node restoring from a snapshot and the change feed can switch straight to replay.
- /bank/status-cache.json
- /bank/blockhash-queue.json?slot=<slot>
- /bank/status-cache/status.json
Account attestationsLive
A statement signed by Pipe (its key is in Pipe's signed key directory) that an account held a state at a slot, tied to mainnet's bank hash, for light clients, bridges and audits.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /attest/account/index.json
- /attest/account/<pubkey>?slot=<slot>
State bisectionLive
Find which accounts differ between your node and Pipe's producer at a slot in a few round trips, from lattice-hash sums by pubkey prefix.
- /state/index.json
- /state/<slot>.json
- /state/<slot>/range?prefix=<hex>&depth=2
- /state/<slot>/accounts?prefix=<hex>
Snapshot indexesLive
Token accounts by owner and by mint, and the top programs' accounts, for the two newest full snapshots, so an RPC node can skip its startup scan.
- /snapshots/indexes.json
- /snapshots/<archive>.index/manifest.json
- /snapshots/<archive>.index/<file>
Filtered snapshotsLive
Only the accounts that selected programs own (token, stake, Raydium AMM v4), cut from the newest full snapshot and attested by Pipe.
Its statements are signed by the main attestation key, 4Kf16X3Fvvhy3W43jCUbkT1KxWhfPRZfkR3dZm95xQRB.
- /filtered/index.json
- /filtered/<filter>/snapshot-<slot>-<hash>.accounts.zst
- /attest/filtered/<filter>/<file>.json
Agave snapshotsLiveTestnet
Pipe's snapshots converted for Agave, Jito-Solana and Frankendancer, full and incremental, with SHA-256 files and statements signed by Pipe.
Restore-tested: Agave and Jito-Solana validators restored these converted snapshots, a full and its incremental, and replayed them against mainnet’s bank hashes.
Each archive’s statement is signed by agave-snapshots’ own key, listed in /attest/keys.json.
- /agave/snapshots/index.json
- /agave/snapshots/snapshot-<slot>-<hash>.tar.zst
- /agave/snapshots/incremental-snapshot-<base>-<slot>-<hash>.tar.zst
- /agave/attest/snapshots/<archive>.json
- /testnet/agave/snapshots/index.json
- /testnet/agave/snapshots/snapshot-<slot>-<hash>.tar.zst
- /testnet/agave/snapshots/incremental-snapshot-<base>-<slot>-<hash>.tar.zst
Archive chunk listsLiveTestnet
Each published archive's 64 MiB chunk hashes, signed by Pipe, so a downloader or mirror checks every range as it arrives. Free.
Its statements are signed by the main attestation key, 4Kf16X3Fvvhy3W43jCUbkT1KxWhfPRZfkR3dZm95xQRB.
- /attest/chunks/<archive>.json
- /testnet/attest/chunks/<archive>.json

Validator operations

Leader healthLive
For each upcoming leader: TPU-QUIC reachability and round trips, skips, fill, fee floors and landing estimates, as JSON or a live stream.
- /leaders/upcoming.json?slots=64
- /leaders/health.json
- /leaders/fees.json
- /leaders/node/<identity>.json
- /leaders/stream
Leader revenueLive
Revenue per leader slot (fees and Jito tips) against neighbouring slots, each validator's index and rank, and what caused a shortfall. Per-validator reports are signed.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /revenue/epoch/<epoch>.json
- /revenue/epoch/<epoch>/validators/<identity>.json
- /revenue/slots.json?from=<slot>&to=<slot>
- /monitor/revenue/<vote>.json
Leader and vote performanceLive
Each leader's produced and skipped slots, block fill and timing, and each vote account's latency and credits, by epoch and slot.
- /perf/leaders.json?epoch=<epoch>
- /perf/votes.json?account=<vote>
- /perf/slots.json?from=<slot>&to=<slot>
Validator scorecardsLive
A signed scorecard for every staked vote account each epoch: credits, latency, skips, commission, MEV, software and stake, with JSON and CSV exports.
Its statements are signed by its own service key, listed in /attest/keys.json.
- /scorecards/index.json
- /scorecards/<epoch>/<vote>.json
- /scorecards/<epoch>/export.csv
Validator readinessLive
Whether the next epoch boundary admits a validator under Alpenglow's rules, and what each pending feature gate asks of it, signed.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /readiness/<vote>.json
- /readiness/summary.json
- /readiness/boundary.json
- /readiness/features.json
Delegation guardLive
Your validator against SFDP, Jito StakeNet and Marinade criteria: what fails, what is at risk and by when, signed. Part of Validator Ops.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /delegation/criteria.json
- /delegation/<vote>.json
- /delegation/summary.json
Validator monitoringLive
Alerts for your validators by signed webhook (delinquency, vote latency, skips, bank-hash mismatches, readiness and delegation risk, pre-leader checks) and dashboards. Part of Validator Ops.
Its statements are signed by its own service key, listed in /attest/keys.json.
- POST /monitor/subscriptions
- /monitor/subscriptions/<id>/dashboard.json
- /monitor/subscriptions/<id>/alerts.json
- /monitor/validators/<vote>.json
Startup plansLiveTestnet
A signed plan to start an ngSol node and catch it up: which archive or image, which mirror, expected hashes, worker settings and time and disk estimates.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /plan?cluster=mainnet-beta&bandwidth_mbps=<n>&disk_free_gb=<n>
- POST /plan
- /plan/status.json
- /testnet/plan?cluster=testnet&bandwidth_mbps=<n>&disk_free_gb=<n>
- POST /testnet/plan
- /testnet/plan/status.json
ngSol warm setLive
The programs and accounts a restarting ngSol node should preload, signed and valid for 48 hours.
Its statements are signed by its own service key, listed in /attest/keys.json.
- /ngsol/warm-set.json
Cluster restart kitLive
During an announced cluster restart: the restart slot, expected bank hash, shred version and the exact flags for Agave, Firedancer and ngSol, signed by Pipe. Free.
Its statements are signed by its own service key, listed in /attest/keys.json.
- /restart.json
- /restart/status.json
Epoch boundary rehearsalLive
What the next boundary will do before mainnet finalizes it: every stake reward and partition, frozen stakes and the next leader schedule, then the comparison.
- /epoch/rehearsal/index.json
- /epoch/<epoch>/rehearsal.json
- /epoch/<epoch>/rehearsal/<pubkey>.json
- /epoch/<epoch>/rehearsal/rewards.json
Shred propagationLiveTestnet
How each slot's shreds reached Pipe: arrival against the slot's start, erasure-set completeness, repair needed and duplicates, by slot and by leader.
- /shreds/health.json?from=<slot>&to=<slot>
- /shreds/health/leaders.json?epoch=<epoch>&leader=<identity>
- /testnet/shreds/health.json?from=<slot>&to=<slot>
- /testnet/shreds/health/leaders.json?epoch=<epoch>&leader=<identity>
Turbine treeLiveTestnet
For any node and shred, who sends it the shred and whom it relays to, as Agave builds the tree, and a node's positions over the next slots.
- /turbine/<slot>.json?node=<pubkey>&shred=<index>
- /turbine/upcoming.json?node=<pubkey>&count=32
- /testnet/turbine/<slot>.json?node=<pubkey>&shred=<index>
- /testnet/turbine/upcoming.json?node=<pubkey>&count=32
Duplicate blocksLiveTestnet
Slots whose leader signed two versions, each with a proof in Agave's duplicate-shred format, checked against the leader's signature.
- /equivocation/index.json
- /equivocation/<slot>.json
- /testnet/equivocation/index.json
- /testnet/equivocation/<slot>.json
Alpenglow certificatesLiveTestnet
Every slot's notarization and finalization certificates, verified against the epoch's voters, as JSON or a live stream.
- /alpenglow/index.json
- /alpenglow/<slot>.json
- /alpenglow/slots.json?from=<slot>&to=<slot>
- /alpenglow/voters/<epoch>.json
- /alpenglow/stream
- /testnet/alpenglow/index.json
- /testnet/alpenglow/<slot>.json
- /testnet/alpenglow/slots.json?from=<slot>&to=<slot>
- /testnet/alpenglow/voters/<epoch>.json
- /testnet/alpenglow/stream
Alpenglow participationLiveTestnet
Whether each validator's votes landed in certificates and reward aggregates, how fast, and what it did to its credits, by slot and epoch.
- /alpenglow-participation/validators/<vote>.json
- /alpenglow-participation/epochs/<epoch>.json
- /alpenglow-participation/slots.json?from=<slot>&to=<slot>
- /testnet/alpenglow-participation/validators/<vote>.json
- /testnet/alpenglow-participation/epochs/<epoch>.json
- /testnet/alpenglow-participation/slots.json?from=<slot>&to=<slot>
Maintenance windowsLive
Signed restart windows for your validator identity that miss none of its leader slots, refreshed hourly, for ngSol's updater. Part of Validator Ops.
Its statements are signed by its own service key, listed in /attest/keys.json.
- /maintenance/<identity>.json
Shadow trialBy request
Pipe watches your validator read-only for an epoch and signs a report of what Validator Ops would have caught and gained. Ask for a trial.
Its statements are signed by its own service key, listed in /attest/keys.json.
Is it me or the network?Live
For your validator and a window: whether missed votes or skipped slots were yours, the network's, or your client's or region's, with the evidence, signed; plus the cluster's incident feed.
Each correlation, incident and the feed are signed by the service’s own key, listed in /attest/keys.json.
- /incidents/correlate.json?vote=<vote>&at=<time>
- /incidents/feed.json
Leader postmortemsLive
Every leader slot explained: on time, late or skipped, when and why, what it earned against what it could have earned (estimates, labelled). Per epoch, with top causes. Signed.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /postmortem/validators/<identity|vote>/summary.json
- /postmortem/validators/<identity|vote>/epochs/<epoch>.json
- /postmortem/validators/<identity|vote>/slots.json?from=<slot>&to=<slot>
- /postmortem/slots/<slot>.json
Stake advisorLive
What to change to win more delegated stake (SFDP, Marinade's auction, JitoSOL) and what each change costs, ranked and signed. Part of Validator Ops.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /advisor/<vote>.json
- /advisor/inputs.json
Rewards ledgerLive
Per-epoch accounting reports for your validator: commission, delegators' rewards, fees, tips and vote costs, reconciled, traceable to each slot, signed, as JSON and CSV. Part of Validator Ops.
Each report is signed by the service’s own key, listed in /attest/keys.json; the signed report holds its CSV’s sha256.
- /rewards-ledger/<epoch>/<vote>.json
- /rewards-ledger/<epoch>/<vote>.csv
Managed standbyLive
A hot standby built so only one of your nodes votes at a time: Pipe's fence leases the voting right to one node per validator, with a fencing token and a signed audit log, and your agent switches identity only under the lease. Your keys stay on your machines.
Each lease and the audit log are signed by the fence’s own key, listed in /attest/keys.json; the fence holds no validator key.
- /standby/v1/enroll
- /standby/v1/lease
- /standby/v1/lease/<identity>
- /standby/v1/audit/<identity>
Vote-safety guardLive
A consensus diagnostic for custom clients: compare your validator's bank hash with Pipe's signed verdict every slot, and get alerted on a confirmed divergence or a node that stops advancing. Alerts only. Part of Validator Ops.
Each verdict and each check of your bank hash is signed by the guard’s own key, listed in /attest/keys.json; the agent verifies every answer before it counts.
- /vote-guard/index.json
- /vote-guard/<slot>.json
- /vote-guard/check?slot=<slot>&bank_hash=<hash>
- /vote-guard/stream?from=<slot>
Client tools (signed downloads)Live
Pipe's client tools for your hosts: download with your key, check the sha256 and the release statement signed by a key /attest/keys.json lists.
Each release’s statement (its sha256, size, target and source revision) is signed by the downloads key, listed in /attest/keys.json for client-release.
- /downloads/index.json
- /downloads/<tool>/<version>/<target>/<tool>
- /downloads/<tool>/<version>/<target>/<tool>.sha256
- /downloads/<tool>/<version>/<target>/<tool>.release.json

Fast start

Bootstrap artifactsLiveTestnet
Start Agave or Jito-Solana from Pipe's newest snapshot without the unpack: a signed map of the fastboot layout onto the converted archives, fetched in parallel by pipe-bootstrap, checked frame by frame and verified by the node's own lattice hash. Part of Fast start.
Each artifact’s manifest is signed by the service’s own key, listed in /attest/keys.json; the archives’ bytes are agave-snapshots’, signed by its own key.
- /bootstrap/agave/index.json
- /bootstrap/agave/agave-fastboot-<slot>/manifest.json
- /bootstrap/agave/archives/<archive>
- /testnet/bootstrap/agave/index.json
- /testnet/bootstrap/agave/agave-fastboot-<slot>/manifest.json
- /testnet/bootstrap/agave/archives/<archive>
Cluster restart artifactsLive
During an announced mainnet restart: the coordinated parameters (checked by two operators), Pipe's independent cross-check (never authoritative) and the restart-slot snapshot, each signed. Your node verifies all of it against the announcement and keeps its local fallback.
The parameters, Pipe’s cross-check and each restart snapshot are signed by the service’s own key, listed in /attest/keys.json; your node checks them against the coordinated announcement, never against Pipe alone.
- /restart/parameters.json
- /restart/crosscheck.json
- /restart/artifacts.json
- /restart/artifacts/<snapshot>
Fast catch-upLive
Restart from the Pipe full you kept: a signed Agave incremental to Pipe's newest slot, built on demand, verified and installed by pipe-fast-catchup.
Each incremental’s statement is signed by the service’s own key, listed in /attest/keys.json; the archive it builds on is agave-snapshots’, signed by its own key.
- POST /catchup/v1/incremental
- /catchup/v1/jobs/<id>
- /catchup/v1/bases.json
- /catchup/files/<incremental>
- /catchup/attest/<incremental>.json
Account proofs for lazy stateLive
Start an ngSol node replaying in seconds: its first blocks' accounts arrive in signed batches tied to mainnet's bank hash, while the full state loads; it votes only once its own full state verifies.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /state-proofs/index.json
- /state-proofs/slots.json
- POST /state-proofs/batch?slot=<slot>
- POST /state-proofs/stream?slot=<slot>
- /state-proofs/manifest/<slot>
- /state-proofs/features/<slot>
Onboarding (Fast start)LiveTestnet
Bring a validator to voting hot and verified: hot before its stake activates, back as soon as it is ready after a restart, or through a cluster restart. It never votes on anything it has not executed itself.
Each answer is signed by its own service key, listed in /attest/keys.json.
- /onboard/plan/<vote>.json?client=agave&version=4.3.2&mode=new
- /onboard/status.json
- /testnet/onboard/plan/<vote>.json?client=agave&version=4.3.2&mode=new
- /testnet/onboard/status.json
Catch-up shredsLiveTestnet
Restart and catch up in minutes: the slots since your snapshot, from Pipe's stored shreds, streamed into your validator's TVU by the pipe-shred-feeder tool, every shred checked against a signed manifest and its leader's signature first.
Each range manifest is signed by the service’s own key, listed in /attest/keys.json; the feeder checks every shred against it.
- /shred-range/status.json
- /shred-range/stream?from=<slot>&follow=1
- /shred-range/manifest/<bucket>.json
- /testnet/shred-range/status.json
- /testnet/shred-range/stream?from=<slot>&follow=1
- /testnet/shred-range/manifest/<bucket>.json

Client development and testing

Block validationLive
Submit a block your client built on a parent Pipe holds: it is replayed against that parent's state and every rule it breaks is named. Part of Client Lab.
- POST /blocks/validate
- /blocks/jobs/<id>.json
- /blocks/rules.json
Conformance checksLive
Compare your client's per-slot bank hashes, accounts and transactions with Pipe's replay and get the first slot, transaction and account that differ. Part of Client Lab.
- POST /conformance/check
- /conformance/slot/<slot>
- /conformance/status
Conformance fixturesLive
protosol transaction and instruction fixtures cut from mainnet replay, for solana-conformance, solfuzz and sol_compat. Part of Client Lab.
- /fixtures/index.json
- /fixtures/txn/<signature>.fix
- /fixtures/sets/<set>.tar.zst
Feature simulatorLive
What an unactivated feature gate would change in recent mainnet blocks: which transactions and which bank hashes. Part of Client Lab.
- /features/index.json
- /features/<feature>/simulate?from=<slot>&to=<slot>
- /features/jobs/<id>.json
Repro bundlesLive
A kit to re-execute a recent rooted slot offline and compare its bank hash: pre-state accounts, parent bank, entries and the producer's report. Part of Client Lab.
- /repro/index.json
- /repro/<slot>.tar.zst
- /repro/<slot>.json
Replay benchmarkLive
Compare your ngSol node's replay with Pipe's producer slot by slot and see what is slower, why, and what to change. In Validator Ops and Client Lab.
- POST /bench/submit
- /bench/report/<id>.json
- /bench/reference.json
Traffic replayBy request
Captured mainnet turbine and repair traffic re-sent to your test node at recorded speed or faster, with loss and reordering. Run by Pipe against a target you verify. Part of Client Lab.
Execution censusLive
What mainnet executes, by count and compute units, per epoch and day, so a client team knows what to implement and optimize first.
- /census/latest.json
- /census/<epoch>.json
- /census/day/<date>.json
Alpenglow readinessLiveTestnet
Mainnet's Alpenglow certificates, votes and aggregates plus edge cases, each with the reference outcome, as signed vector sets for your client's CI; a scored conformance check; and per-slot vote latency and credits attribution for a validator.
Each vector set, check report and attribution is signed by the service’s own key, listed in /attest/keys.json.
- /alpenglow-readiness/vectors/index.json
- /alpenglow-readiness/vectors/<set>.tar
- /alpenglow-readiness/vectors/<set>/manifest.json
- /alpenglow-readiness/vectors/<set>/statement.json
- POST /alpenglow-readiness/check
- /alpenglow-readiness/validators/<vote>.json
- /testnet/alpenglow-readiness/vectors/index.json
- /testnet/alpenglow-readiness/vectors/<set>.tar
- /testnet/alpenglow-readiness/vectors/<set>/manifest.json
- /testnet/alpenglow-readiness/vectors/<set>/statement.json
- /testnet/alpenglow-readiness/validators/<vote>.json
Release qualificationLive
Qualify a client release before you run it: Pipe builds it from source in a sandbox, restores it from recent mainnet, replays mainnet's blocks and signs a report: bank-hash agreement, the first divergence, replay speed, conformance and feature gates. Part of Client Lab.
Each finished job’s report is signed by the service’s own key, listed in /attest/keys.json.
- /qualify/allowlist.json
- /qualify/jobs (POST)
- /qualify/jobs.json
- /qualify/jobs/<id>.json
- /qualify/jobs/<id>/report.json
Leader shadow labLive
Run your client as a leader on a private fork of mainnet while mainnet's own transactions replay into its TPU; compare its packing slot by slot with the real leaders'. Part of Client Lab.
Each finished job’s report is signed by the service’s own key, listed in /attest/keys.json.
- POST /shadow-lab/jobs
- /shadow-lab/jobs/<id>.json
- /shadow-lab/reports/<id>.json
- /shadow-lab/clients.json
- /shadow-lab/status.json

Limits and errors

Refusals are JSON: {"error": "…", "reason": "…"}.

Gate responses
Status	Meaning	What to do
401	The route needs a key and none was sent (`key_required`), or the key is unknown, expired or revoked, or its line has no paid period.	Check the key with `/access/key.json` and your plan in the dashboard.
403	The key’s plan does not include this endpoint group.	Use a key from a plan that includes it: the service’s page lists them.
429	The key passed its request rate, or used its daily or monthly quota.	Wait for `Retry-After`, or set an overage cap for quota.
503	The key service or the server’s connection limits are busy.	Retry with backoff.

Search files

Use Pipe’s Solana data endpoints.

Since October 23, 2026, downloads need a key

Connect

Testnet

Free, without a key

JSON-RPC

Testnet’s own keys

On testnet today

Use a key with Pipe’s tools

Client tools

`pipe-alpenglow-vectors` 0.1.0

`pipe-bootstrap` 0.1.0

`pipe-fast-catchup` 0.1.0

`pipe-host-audit` 0.1.0

`pipe-onboard` 0.1.1

`pipe-shred-feeder` 0.1.0

`pipe-standby-agent` 0.1.0

`pipe-vote-guard-agent` 0.1.0

Verification

Plans, keys and billing

Endpoints

Snapshots

Ledger

Shreds by slot

Live shreds

Account changes

Bank stream

Bank states

JSON-RPC

Fees and programs

Services

Data

Validator operations

Fast start

Client development and testing

Limits and errors

Since October 23, 2026, downloads need a key

Connect

Testnet

Free, without a key

JSON-RPC

Testnet’s own keys

On testnet today

Use a key with Pipe’s tools

Client tools

pipe-alpenglow-vectors 0.1.0

pipe-bootstrap 0.1.0

pipe-fast-catchup 0.1.0

pipe-host-audit 0.1.0

pipe-onboard 0.1.1

pipe-shred-feeder 0.1.0

pipe-standby-agent 0.1.0

pipe-vote-guard-agent 0.1.0

Verification

Plans, keys and billing

Endpoints

Snapshots

Ledger

Shreds by slot

Live shreds

Account changes

Bank stream

Bank states

JSON-RPC

Fees and programs

Services

Data

Validator operations

Fast start

Client development and testing

Limits and errors

`pipe-alpenglow-vectors` 0.1.0

`pipe-bootstrap` 0.1.0

`pipe-fast-catchup` 0.1.0

`pipe-host-audit` 0.1.0

`pipe-onboard` 0.1.1

`pipe-shred-feeder` 0.1.0

`pipe-standby-agent` 0.1.0

`pipe-vote-guard-agent` 0.1.0