Quick-reference definitions for terms used throughout Helius documentation and on Solana. Each entry links to the relevant product page or guide where applicable. Jump to:Documentation Index
Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
- Helius Products & Platform
- Solana Fundamentals
- Transaction Mechanics
- Tokens & Assets
- Connectivity & Streaming
- Ecosystem
Helius Products and Platform
Autoscaling
Helius’s automatic credit top-up mechanism for fiat plans. When the monthly credit allowance is exhausted, autoscaling purchases additional credits up to a user-set cap, preventing429 errors from interrupting production traffic. Crypto plans don’t have autoscaling. Instead, they use prepaid credits, which are purchased manually.
See Autoscaling.
Credit
The unit Helius bills API and streaming usage in. RPC methods, DAS calls, and streaming throughput each have a specific credit cost. Every plan includes a monthly credit allowance that resets each billing cycle (unused credits don’t roll over). See Credits for the full cost table.DAS API
Digital Asset Standard — an open specification for a unified interface for Solana digital assets (NFTs, compressed NFTs, fungible tokens, inscriptions). Helius’s DAS API implementation returns enriched metadata, ownership, and pricing in a single structured response, eliminating the need for custom parsers over onchain asset data. See DAS API.Dedicated Nodes
Private Helius RPC nodes with no rate limits or credit metering, billed at a fixed monthly rate. They suit narrow use cases needing unlimited throughput; most applications are better served by regular Helius RPC due to superior performance, failover, and feature coverage. See Dedicated Nodes.Enhanced Transactions
Helius’s parsed transaction API that decodes raw Solana transactions into human-readable events — token transfers, NFT sales, swaps, staking operations, and more — without requiring per-program instruction parsers. See Enhanced Transactions.Error Codes
Standard HTTP status codes returned by Helius APIs, with Helius-specific context:400 Bad Request— invalid parameters or malformed request (e.g., invalid address format, missing required fields, malformed JSON)401 Unauthorized— missing or invalid API key403 Forbidden— access denied, typically from IP restrictions, a subscription that doesn’t include the endpoint, or insufficient API-key permissions404 Not Found— no data available for the requested resource (normal for identity lookups on unknown wallets)429 Too Many Requests— credit allowance exhausted, rate limit exceeded, or concurrent-request limit hit5xx— Helius-side issues; retry with exponential backoff
Gatekeeper
Helius’s edge gateway that delivers significantly lower latency than standard RPC calls by routing requests through a globally distributed proxy fleet. Accessed by swappingmainnet.helius-rpc.com for beta.helius-rpc.com in the RPC URL.
See Gatekeeper and the Introducing Gatekeeper blog post for architectural background.
LaserStream
Helius’s high-performance gRPC streaming service for Solana onchain data, featuring historical replay, multi-region failover, and the richest feature set among Helius streaming products. Official SDKs ship for JavaScript/TypeScript, Rust, and Go. LaserStream WebSocket runs on the same infrastructure. See LaserStream and the LaserStream SDK performance blog post for a deep dive on SDK benchmarks.LaserStream WebSocket
Helius’s persistent WebSocket streaming service. It serves both the standard Solana WebSocket methods and Helius-specific extensions (transactionSubscribe and an enhanced accountSubscribe with richer filtering) on a single unified endpoint. LaserStream WebSocket shares its backend with LaserStream gRPC.
See LaserStream WebSocket.
Priority Fee API
Helius’s fee estimation endpoint that returns recommended priority fee values based on real-time onchain fee markets. Enables competitive fee pricing without guesswork or overpaying during congestion. See Priority Fee API.Rate Limit
The maximum requests per second allowed under a given Helius plan. Rate limits vary by plan tier and by API family (standard RPC, Enhanced APIs, streaming). Exceeding them returns429 Too Many Requests.
See Rate Limits.
Sender
Helius’s specialized transaction landing service built for low latency traders, combining priority fees, Jito tips, and staked connection routing to maximize landing rates. Available athttps://sender.helius-rpc.com/fast.
See Sender.
Shred Delivery
Helius’s service for streaming raw Solana shreds over UDP — the earliest possible onchain signal, delivered before final block assembly. Helius aggregates shreds from a distributed network of validators across regions to minimize the geographic latency variance of any single validator. Useful for high-frequency trading, arbitrage, and other low latency applications. See Shred Delivery and the blog post Winning the Millisecond Game: Shreds, LaserStream, and the Edge of Solana for a deep dive on how shreds work.Staked Connections
The default transaction submission path for Helius paid plans. Staked connections route transactions to upcoming block leaders via Solana’s protocol-level Stake-Weighted Quality of Service (SWQoS), which grants preferential connection slots based on validator stake and reduces packet drops during congestion. Helius’s paid plans inherit this landing-rate advantage without callers needing to operate a heavily staked validator directly. See Optimizing Transactions and the blog post Stake-Weighted Quality of Service: Everything You Need to Know.Wallet API
Helius’s REST API for querying a Solana wallet’s balances, transaction history, transfers, identity, and funding source — structured, USD-priced responses instead of raw RPC output. It accepts SNS.sol and ANS domain names in addition to addresses.
See Wallet API.
Solana Fundamentals
Account
A container that holds data persistently on Solana, identified by a 32-byte public key. All onchain state — user balances, program code, token metadata — lives in accounts, including the programs themselves. Every account has an owner, which is a program that is allowed to modify its data or withdraw lamports, and must maintain a minimum SOL balance (rent-exempt) to persist. See the blog post The Solana Programming Model: An Introduction to Developing on Solana for a deeper dive.Agave
The current canonical Solana validator client, maintained by Anza — the rebranded successor to the original Solana Labs client. References to specific Agave releases (e.g., the v1.17.31 SWQoS minimum-stake threshold) typically pin behavior to a specific version of the client. Jito-Solana is a fork of Agave with their block engine integrated; Firedancer is an independent C-based alternative developed by Jump Crypto. See the blog post Solana Virtual Machine for the SVM model Agave implements.Airdrop
A grant of SOL or SPL tokens to an address. On Devnet and Testnet, an airdrop typically refers to a small amount of test SOL from a faucet used to fund development wallets; on Mainnet, it refers to bulk token distributions to existing holders. Devnet airdrops are available via the Devnet faucet.Associated Token Account (ATA)
A deterministically derived token account holding a specific SPL token for a given wallet address. Each wallet has at most one ATA per token mint, making ATAs the canonical place to look up a user’s token balance. It is derived using the wallet address and token mint as seeds.Block
A data structure containing a set of transactions plus essential metadata — including the block’s hash and the previous block’s hash, forming an immutable chain. Blocks are produced during slots: the assigned leader for a slot validates incoming transactions, packages them into a block, and broadcasts the block to the network via Turbine. Not every slot produces a block — if the leader fails to produce one in time, the slot is skipped and the network moves on. Once a block has received a supermajority of stake-weighted validator votes, it is considered confirmed (see Commitment Level). See the blog post Understanding Slots, Blocks, and Epochs on Solana for a deeper dive.Commitment Level
The degree of confidence that a transaction has been included onchain:processed— seen by the current leader but not yet voted on; can still be dropped if the block loses consensus (~0.4s)confirmed— ≥66% stake-weighted validator votes on the block; historically, no confirmed block has reverted (~0.6s)finalized— the block has ≥66% votes plus 31 subsequent blocks built atop it (i.e., the Tower BFT maximum lockout), making it effectively irreversible (~13s)
confirmed is the recommended default. Use processed for UI feedback, finalized for high-value operations like exchange deposits or cross-chain bridges. Blockhashes fetched at finalized expire sooner than confirmed ones, shrinking the window before transaction expiry.
See the blog post What are Solana Commitment Levels? for a deeper dive.
Compute Units (CU)
Solana’s measure of computational work performed by a transaction, analogous to gas on Ethereum. Each transaction specifies a compute unit limit and a compute unit price (priority fee in microlamports per CU); the product determines total priority fee cost. Exceeding the limit fails the transaction.CPI (Cross-Program Invocation)
A Solana mechanism that lets one onchain program call another, passing accounts and instruction data — the primitive that enables Solana’s composability. CPIs are exposed via thesol_invoke_signed syscall, which verifies the caller has the appropriate permissions for the accounts being passed; PDAs let programs sign on behalf of accounts they own.
A called program operates within the calling program’s remaining compute budget: if it exhausts the budget or exceeds a set limit, the entire chain of calls fails — including the original transaction.
See the blog post Solana Virtual Machine for a deeper dive.
Epoch
A cluster of approximately 432,000 Solana slots — the higher-level organizational interval at which Solana updates its validator set, leader schedule, stake delegations, and reward distributions. Each epoch takes ~2 days at the current slot target. See the blog post Understanding Slots, Blocks, and Epochs on Solana for a deeper dive.Firedancer
A second independent Solana validator client, written from scratch in C by Jump Crypto. Firedancer’s stated goals are (1) documenting and standardizing the Solana protocol via an independent implementation, (2) improving client diversity (no single client controls >33% of stake), and (3) raising ecosystem performance. The architecture is modular: many single-purpose Linux processes called “tiles” (QUIC tile, verify tile, etc.) communicate via shared memory, in contrast to Agave’s single-process design. Frankendancer is their hybrid intermediate — Firedancer’s high-performance C networking code paired with Agave’s Rust runtime and consensus code. See the blog post What is Firedancer? for a deeper dive.Instruction
The smallest unit of work inside a Solana transaction — a single program invocation with the relevant accounts and data. A transaction bundles one or more instructions, executed atomically (all succeed or all revert together). See the blog post The Solana Programming Model: An Introduction to Developing on Solana for a deeper dive.Lamport
The smallest unit of SOL: 1 SOL = 1,000,000,000 lamports (10⁻⁹ SOL), named after Leslie Lamport, the Turing Award winner for foundational work in distributed systems. Raw Solana RPC methods return balances and fees in lamports; Helius’s Wallet API handles the conversion automatically. Priority fees are denominated in microlamports — one millionth of a lamport (10⁻¹⁵ SOL).Leader / Leader Schedule
The leader is the validator assigned to propose a new block during a given slot. Leaders are picked by a stake-weighted random schedule computed at the start of each epoch, so any validator can independently derive who will lead every slot in the upcoming ~2-3 day window. Each leader is assigned four consecutive slots (~1.6 seconds at ~400 ms per slot), giving them a short window of consecutive block production. If a leader fails to produce a block in their slot, the slot is skipped — the network moves on rather than waiting for the missing block. Transaction-sending services like Sender route signed transactions to the current leader and the next two leaders to maximize landing probability. See the blog post Consensus on Solana: Tower BFT and Proof of History for a deeper dive.Merkle Tree
A cryptographic tree structure where each non-leaf node is a hash of its children, so the single root hash commits to the entire dataset. Verifying that a piece of data belongs to the tree requires only the sibling hashes along the path from the leaf to the root — a Merkle proof — which is O(log n) data regardless of tree size. For a depth-26 tree that proof is 26 sibling hashes (~832 bytes), which is small but still per-leaf: this is the proof shape used by compressed NFTs. ZK Compression replaces it with a single constant-size Validity Proof that doesn’t grow with the dataset. See the blog post Cryptographic Tools 101: Hash Functions and Merkle Trees Explained.Program
An executable account containing compiled sBPF bytecode (i.e., a smart contract on Solana). Programs are stateless — they read and write data accounts they own, and are identified by a program ID (their 32-byte address). Solana ships with a set of native programs (System, Stake, Vote, etc.) built into the runtime; everything else is a user-deployed program. See the blog post The Solana Programming Model: An Introduction to Developing on Solana for a deeper dive.Program Derived Address (PDA)
A deterministic address derived from a program ID and a set of seeds. PDAs let programs sign for accounts they control, making them essential for stateful program design. PDAs are intentionally off-curve, so no private key exists for them.Proof of History (PoH)
Solana’s synchronization primitive — not a consensus algorithm. PoH provides a cryptographic time-stamping function that lets validators agree on the order of events without communicating with each other. Implementation: a sequential SHA-256 hash chain that runs continuously on a single CPU core per validator, using each iteration’s output as the next iteration’s input. Generation is sequential and single-threaded; verification is parallelizable. PoH provides the “ticks” that define when a block is valid. Leaders must publish blocks within a given PoH tick range — a block outside the range is considered skipped. PoH runs alongside Tower BFT, which is the actual consensus mechanism. See the blog post Proof of History, Proof of Stake, and Proof of Work Explained for a deeper dive.Rent / Rent-exempt
The SOL balance every Solana account must hold to persist onchain, scaled to the account’s storage size. Accounts must be created rent-exempt: transactions that would leave an account below the minimum fail. Once rent-exempt, the account persists indefinitely without further payments.Sealevel
Solana’s parallel transaction execution engine. Unlike sequential VMs such as the EVM, Sealevel executes multiple transactions simultaneously across CPU cores. This is possible because every Solana transaction explicitly declares which accounts it will read from and write to before execution begins, so the scheduler can identify non-conflicting batches without runtime analysis. The scheduling rules are simple: transactions touching different accounts run in parallel; transactions that only read the same accounts also run in parallel (reads don’t conflict); transactions that write to the same accounts run sequentially to prevent race conditions. See the blog post Solana Virtual Machine for a deeper dive.Slot
Solana’s fundamental time unit, during which a designated leader validator has the opportunity to produce a block. Slots currently target 400ms, though actual durations can vary with network conditions. If a leader fails to produce a block during its slot, the slot is skipped — the network moves on to the next slot rather than waiting, so not every slot results in a block. See the blog post Understanding Slots, Blocks, and Epochs on Solana for a deeper dive.SVM (Solana Virtual Machine)
Solana’s full transaction execution stack — not a narrow bytecode interpreter. The SVM encompasses the Bank component that orchestrates execution, the Banking Stage scheduler, BPF loaders, and the sBPF virtual machine itself (a register-based VM with 11 general-purpose registers and ~100 opcodes, JIT-compiled for performance). This is distinct from the EVM, which refers unambiguously to a single bytecode executor. Solana programs compile to sBPF, Solana’s fork of Linux eBPF. Any language with an LLVM frontend (C, C++, Rust, Zig) can target sBPF. Requiring transactions to declare account access up front is what unlocks Sealevel’s parallel execution and Solana’s localized fee markets. See the blog post Solana Virtual Machine for a deeper dive.Tower BFT
Solana’s consensus mechanism. Tower BFT is a pBFT-like algorithm that takes advantage of Proof of History’s synchronized clock, eliminating the need for a synchronous consensus round on every slot. Validators build a “vote tower” — a sequential stack of votes where each new vote doubles the lockout period of all previous votes, exponentially raising the stake-loss cost of switching forks. Confirmation thresholds: a block is confirmed once ≥2/3 of stake-weighted votes have landed on it (≥4.6% of total stake would have to be slashed to violate finality). A block is finalized once it has votes plus 31 subsequent blocks built on top, the Tower BFT maximum lockout. See Commitment Level for usage guidance. See the blog post Consensus on Solana: Tower BFT and Proof of History for a deeper dive.Turbine
Solana’s block propagation protocol. The leader splits each block into MTU-sized shreds plus Reed-Solomon erasure-coded recovery shreds — the FEC rate (typically 32:32) lets the network reconstruct a block even with ~33% packet loss. The leader then forwards shreds across a deterministic stake-weighted tree of peer validators (seeded per shred-group by(leader id, slot, shred index, shred type)) rather than broadcasting the full block to every validator directly. The tree (DATA_PLANE_FANOUT = 200) keeps the leader’s outbound bandwidth roughly constant regardless of validator count and lets blocks reach the network in 2–3 hops instead of O(n).
See the blog post Turbine: Block Propagation on Solana.
Validator
A node on the Solana network that participates in consensus by producing blocks during its assigned leader slots and voting on blocks from other validators. Validators are selected for leader slots proportionally to their active stake.Transaction Mechanics
Address Lookup Table (ALT)
An onchain table of Solana addresses that a versioned transaction can reference using a 1-byte index instead of a full 32-byte pubkey, letting a single transaction reference up to 256 accounts. ALTs are essential for complex DeFi operations that would otherwise exceed transaction size limits.Blockhash
A 32-byte hash identifying a recent block, included in every Solana transaction to prove freshness. Blockhashes expire after ~150 slots (~1 minute); transactions with expired blockhashes are rejected. Clients fetch a recent blockhash viagetLatestBlockhash just before signing.
Priority Fee
A per-compute-unit tip paid to validators to give a transaction priority over others, improving its time to inclusion. Priority fees are set in microlamports per compute unit (µLamports/CU). Helius’s Priority Fee API returns real-time estimates based on recent onchain fee markets.Shred
The smallest unit of a Solana block. Blocks are split (i.e., shredded) into shreds for parallel propagation across the validator network via Turbine. Shred-level access gives the earliest possible onchain signal, ahead of block assembly. See Shred Delivery.Stake-Weighted Quality of Service (SWQoS)
A Solana protocol-level mechanism that prioritizes incoming transactions to the current and upcoming leaders based on the sender’s stake. Introduced after Solana’s April 30, 2022 outage as a Sybil-resistance measure, SWQoS prevents low-stake or unstaked peers from monopolizing leader bandwidth during congestion. The leader exposes two incoming connection pools: ~500 open connections shared across all unstaked peers, and ~2,000 stake-weighted connections distributed proportionally to staked validators — a validator holding X% of total active stake can send up to X% of packets to the leader. Validators below ~15,000 SOL of active stake (~1/25,000 of total network stake) are treated as unstaked. The minimum-stake threshold landed in Agave v1.17.31. Helius’s Staked Connections inherit this landing-rate advantage by routing customer transactions through Solana’s largest validator, so callers benefit from SWQoS without operating a heavily staked validator directly. See the blog post Stake-Weighted Quality of Service: Everything You Need to Know.Versioned Transaction
A newer Solana transaction format that supports Address Lookup Tables, allowing one transaction to reference up to 256 accounts (vs. ~35 in legacy transactions). Versioned transactions are required for most modern DeFi integrations. They are denoted by a version byte at the start of the serialized transaction.Tokens and Assets
Compressed Account
A compressed account is a Solana account whose data is committed to the ledger via transaction logs, with only a hash fingerprint stored in validator state — rather than the full data occupying a traditional account slot on validator disks. Developers can treat compressed accounts like regular accounts; indexers (such as Photon) parse transaction logs to reconstruct current state, and a constant-size Groth16 zero-knowledge proof verifies integrity when accounts are read or modified via ZK Compression. This model is best suited to small-data accounts — larger data (above ~100 bytes) makes compression impractical.Compressed NFT (cNFT)
A Solana NFT represented as a leaf in an onchain concurrent Merkle tree rather than its own account. The tree lives in a Solana account and its state transitions are secured by the ledger; the NFT’s current state is derived from transaction history by indexers, which produce Merkle proofs verifiable against the tree’s onchain root. Reading a cNFT therefore requires an indexer like the DAS API — standard Solana RPC cannot return cNFT data directly. This model reduces mint costs by up to 99% versus standard NFTs.Concurrent Merkle Tree
A Solana-specific variant of a Merkle Tree designed to allow multiple writers to update the tree in the same slot without invalidating each other’s proofs. The onchain account stores not just the current root but a changelog buffer of recent valid roots and a canopy (a cached subset of upper-tree nodes), letting validators verify proofs generated against any root still in the buffer window. Three parameters define a tree: max depth (caps the leaf count at 2^depth), buffer size (changelog depth — how many writes can occur before older in-flight proofs become invalid), and canopy depth (which trades onchain rent for smaller in-transaction proofs). Valid (depth, buffer) pairs range from (3, 8) up to (30, 2048); for practical composability keepmaxDepth − canopyDepth ≤ 10.
Concurrent Merkle trees are implemented by the SPL Account Compression program and are the substrate for compressed NFTs, which are minted as leaves via Metaplex Bubblegum.
See the blog post All You Need to Know About Compression on Solana.
Groth16
A zk-SNARK proving system that produces constant-size zero-knowledge proofs (128 bytes on the BN254 curve, using point compression) regardless of statement complexity, with O(1) verification. ZK Compression uses Groth16 to generate Validity Proofs that a compressed account belonged to a known state at a known root — the small proof size is what keeps compressed-account transactions cheap. See the blog post Solana Builders: ZK Compression.Mint Account
The onchain account defining an SPL token’s properties — supply, decimals, and mint/freeze authorities. The mint account’s address is the token’s canonical identifier (its “contract address” in Ethereum terms).SPL Token
A token on Solana issued via the Solana Program Library’s (SPL) Token Program. Fungible tokens (USDC, BONK, JUP, etc.) are SPL tokens; standard (non-compressed) NFTs are also SPL tokens, minted with supply 1 and 0 decimals. SPL tokens are roughly the Solana equivalent of ERC-20 and ERC-721 on Ethereum. Token-2022 is a newer program that extends this interface with optional features like transfer fees and confidential transfers.State Tree
The Merkle tree that ZK Compression uses to store the hashes of compressed accounts. The onchain account holds only the current root plus minimal metadata; the actual compressed data lives in transaction logs and is reconstructed by indexers like Photon. Programs read or modify compressed state by passing a Validity Proof that the account’s claimed contents hash to a leaf under the current root. See ZK Compression.Token Account
An onchain account holding a balance of a specific SPL token for a specific owner. A wallet can own arbitrary token accounts, but the convention is to use an Associated Token Account (ATA) — a deterministically derived token account per (wallet, mint) pair created by the Associated Token Account Program.Token-2022 (Token Extensions)
A variant of the SPL Token Program supporting optional extensions (e.g., transfer fees, confidential transfers, interest-bearing tokens, non-transferable tokens). Token-2022 runs as a separate onchain program, with its own program ID, but is designed as a compatible successor to the classic Token Program, so SDKs can typically handle both. Mints must be created under the Token-2022 program to use extensions. See the blog post What are Token Extensions?.Validity Proof
A constant-size Groth16 zero-knowledge proof that a compressed account’s claimed contents existed in the State Tree at a specific root. ZK Compression programs require a validity proof whenever compressed accounts are read or modified; the proof lets the program verify off-chain state without the validator storing the data onchain. Photon exposes validity proofs to callers via itsgetValidityProof RPC method.
Validity proofs are what distinguish ZK Compression from compressed NFTs: cNFTs use plain Merkle proofs (a list of sibling hashes from leaf to root, which grows with tree depth), while ZK Compression’s constant-size ZK proof doesn’t reveal the path or surrounding tree state.
See the blog post Solana Builders: ZK Compression.
ZK Compression
ZK Compression is a Solana primitive developed by Helius and Light Protocol that dramatically reduces onchain storage costs by committing account data to transaction logs in the ledger and storing only a hash fingerprint in validator state. Cryptographic integrity is preserved via constant-size Groth16 zero-knowledge proofs generated from indexed transaction data. This primitive is distinct from compressed NFTs, which use concurrent Merkle trees without zero-knowledge proofs. See ZK Compression and the blog post Solana Builders: ZK Compression for a deeper dive.Connectivity and Streaming
Geyser
Solana’s plugin system for streaming validator state changes — accounts, transactions, slots, blocks — to external consumers in real time. Validators load Geyser plugins as dynamic libraries; the plugin receives state updates as the validator processes them, eliminating the need to poll RPC for changes. Yellowstone gRPC — the dominant Geyser plugin — exposes those updates over gRPC. Helius’s LaserStream implements the Yellowstone gRPC interface with added features like historical replay (up to ~216,000 slots / ~24 hours) and multi-region failover.gRPC
gRPC is a general-purpose, high-performance binary RPC protocol (a recursive acronym for “gRPC Remote Procedure Call”). In Solana contexts, “gRPC” typically refers to Yellowstone gRPC — a streaming interface built on Solana’s Geyser plugin system that exposes account and transaction updates over gRPC. Helius’s LaserStream service is built on a Yellowstone-based interface with added features like historical replay, multi-region failover, and managed infrastructure.RPC
RPC stands for Remote Procedure Call, which is a general pattern for calling a server method as if it were a local function. In Solana, “RPC” most often refers to an RPC node — a node that tracks Solana’s state, but doesn’t participate in consensus, specializing in serving data requests (i.e., account state, transaction history, transaction submission) over a JSON-RPC interface. Validators, by contrast, produce blocks and vote on them. Helius’s RPC service is a globally distributed fleet of RPC nodes optimized for production workloads. See the blog post Solana Nodes — A Primer on Solana RPCs, Validators, and RPC Providers for a deeper dive.Webhook
A webhook is an HTTP POST request sent by a server to a receiver URL when a subscribed event occurs — “reverse” HTTP, where the server initiates the call. Helius Webhooks push Solana onchain events (transfers, NFT sales, custom program activity) to a registered endpoint, eliminating the need for polling.WebSocket (WSS)
A WebSocket is a persistent bidirectional TCP connection upgraded from HTTP, used for push-based streaming of Solana data without repeated HTTP requests. WSS (WebSocket Secure) is the same protocol running over TLS, and is the variant used for production Solana connections. LaserStream WebSocket — Helius’s WebSocket streaming product, including the standard Solana methods and Helius extensions liketransactionSubscribe — uses WSS.
Ecosystem
Anchor
Anchor is a Rust framework for building Solana programs quickly and securely. It handles boilerplate like account serialization, validation, and instruction dispatch through procedural macros, letting developers focus on program logic instead of low-level details. Most Solana developers use Anchor rather than writing programs in native Rust. See the blog post An Introduction to Anchor: A Beginner’s Guide to Building Solana Programs for a deeper dive.IDL
IDL stands for Interface Definition Language. An IDL is a JSON schema describing a Solana program’s instructions, accounts, and data types; clients use it to construct transactions and decode program data without hand-rolling instruction layouts. Anchor generates IDLs automatically and publishes them onchain by default in a dedicated account for public discoverability.Jito
A Solana ecosystem company that operates the network’s dominant block engine — an MEV (maximal extractable value) infrastructure layer that accepts transaction bundles (atomic groups of transactions that execute together or not at all) and lets searchers pay tips to validators to prioritize landing them. The Jito-Solana validator client is a fork of Agave with the block engine integrated. Bundle inclusion requires a minimum tip of 10,000 lamports, and the Jito-Relayer holds inbound traffic for ~200 ms to enable the off-chain bundle auction. Helius’s Sender submits transactions through both staked connections and Jito’s block engine simultaneously, taking whichever path lands first. See the blog post Solana MEV: An Introduction.Light Protocol
The Solana protocol team that co-developed ZK Compression with Helius. Helius built the canonical indexer (Photon) and operates the public RPC; Light Protocol builds the onchain programs and proving stack that the indexer depends on. See github.com/Lightprotocol/light-protocol.Photon
The open-source ZK Compression indexer built by Helius. Compressed account data lives in Solana transaction logs rather than account state, so validators don’t expose it via standard RPC — Photon parses Solana transactions, reconstructs compressed account state, and serves it through a JSON-RPC interface that mirrors Solana’s native RPC plus ZK-Compression-specific methods likegetCompressedAccount and getValidityProof. Developers can self-host from github.com/helius-labs/photon or use the hosted Helius endpoint.
See ZK Compression.