Photon on Alchemy: compressed Solana data, standard RPC

For teams building wallets, exchanges, indexers, and consumer apps on Solana, compressed state is an increasingly common pattern. High-scale token-account workloads can benefit meaningfully from ZK compression — and reading that data requires Photon methods that, until recently, meant standing up a separate provider or running your own indexer.

That's why we added the full Photon / ZK Compression method suite directly to Alchemy's standard Solana RPC endpoint.

Why compression matters on Solana

Solana's account model is fast, but writing every piece of state directly on-chain is expensive, especially for high-scale consumer apps that mint millions of tokens, NFTs, or loyalty assets. ZK compression flips the cost curve such that only a compact cryptographic commitment — a "fingerprint" of the state — lives on-chain, plus the rules to validate updates against it. The detailed state, the part wallets and apps actually want to query, lives off-chain.

That's great for issuers and great for the chain, but not necessarily great for clients. A standard Solana RPC node has no idea what a compressed token balance is. Without an indexer that watches compressed-program activity and reconstructs the underlying state, compressed assets are effectively invisible to your app.

Photon is that indexer. It watches blocks and transactions that touch the compression protocol, rebuilds the detailed state into a queryable database, and exposes it through a standard RPC method surface. For wallets displaying balances and apps verifying holdings, Photon is what makes compressed data readable.

Photon has emerged as a common interface for compressed-state reads on Solana. We adopted its method surface directly, so migration from any Photon-compatible provider is a URL change, not a rewrite.

How it works

Photon continuously tails blocks and transactions touching the compression program. Every relevant instruction — mint, transfer, burn, account update — gets decoded against the on-chain commitment, and the resulting state changes are applied to an off-chain database that mirrors what the compressed accounts actually represent. The on-chain commitment remains the source of truth; the index is a deterministic projection of it, reconstructable from scratch at any time.

The Photon methods live on the same Solana RPC endpoint as every other Solana call. Requests are routed internally based on method name: standard JSON-RPC hits our Solana node fleet, Photon methods hit our Photon fleet. Developers can access everything via one URL.

What we measure

Photon read methods on Alchemy are the most performant across both US and EU regions, and consistently run ~3x faster than other providers on the same calls:

• getCompressedTokenBalancesByOwner — P50 8 ms / P95 12 ms / P99 20 ms in the US (vs. ~30 / 45 / 65 ms on alternative providers); P50 16 ms / P99 53 ms in EU.
• getCompressedTokenBalancesByOwner on heavy accounts (wallets sorted by large compressed-mint sets) — P50 10 ms / P99 23 ms in the US, ~3x tighter at the tail than alternative implementations.
• getCompressedTokenAccountsByOwner — P50 10 ms / P99 25 ms in the US; P50 18 ms / P99 45 ms in EU. ~3x faster end-to-end than alternatives.
• getValidityProof — P50 130 ms / P99 200 ms in the US, with no multi-second tail spikes. We observed alternative providers spike to 3+ seconds on this method under load — proof generation is the heaviest call in the surface, and an unstable tail here stalls wallet flows visibly.

The interesting line is the heavy-accounts tail. Wallets with very large compressed-mint sets are the workload that exposes the gap between "supports Photon" and "supports Photon at production scale" — and it's where these gaps matter most.

Get started

Photon methods are available today on all Solana plans via the standard Solana RPC endpoint. If you're already running against another Photon-compatible provider, migration is a URL change.

• Read the docs
• Talk to our team for custom benchmarks, pricing, or solutions at scale.