What is Solana and why should I build on it?

Solana is a high-performance Layer 1 blockchain capable of processing 65,000+ transactions per second with ~400ms block times and fees averaging $0.00025. It's ideal for applications requiring real-time performance: trading bots, NFT marketplaces, DeFi protocols, and analytics platforms. The combination of speed, low cost, and a mature developer ecosystem makes Solana the preferred platform for latency-sensitive financial applications.

What programming languages can I use to build on Solana?

Solana programs (smart contracts) are written in Rust, C, or C++, compiled to BPF bytecode. Rust is strongly recommended due to its safety guarantees and the Anchor framework. Client-side code can be written in JavaScript/TypeScript (@solana/web3.js), Python (solana-py), Rust (solana-client), Go (gagliardetto/solana-go), or Java. TypeScript with Anchor's auto-generated client is the most common combination for full-stack Solana development.

What is the Anchor framework and should I use it?

Anchor is a framework for Solana program development that provides IDL (Interface Definition Language) generation, automatic client SDK generation, account validation macros, and error handling. It significantly reduces boilerplate and prevents common security vulnerabilities. For most new Solana programs, Anchor is strongly recommended. The main reason to avoid Anchor is if you need maximum compute efficiency, as Anchor adds some overhead compared to native programs.

How do I set up a local Solana development environment?

Install Rust (rustup), Solana CLI (sh -c '$(curl -sSfL https://release.solana.com/stable/install)'), and Anchor (via AVM: cargo install --git https://github.com/coral-xyz/anchor avm). Run 'solana-test-validator' for a local blockchain. Configure your CLI with 'solana config set --url localhost'. For JavaScript development, install @solana/web3.js and @coral-xyz/anchor via npm.

What is the difference between devnet, testnet, and mainnet?

Devnet is the primary development network with free SOL airdrops (solana airdrop 2). It resets periodically and is suitable for development and testing. Testnet is used for Solana core protocol testing and validator performance testing — generally not used by application developers. Mainnet-beta is the production network with real SOL and real economic value. Always develop on devnet first, then test on mainnet with small amounts before full deployment.

What is a Program Derived Address (PDA) and when should I use it?

A PDA is a deterministically derived account address that is not on the Ed25519 curve, meaning no private key exists for it. Programs can 'sign' for PDAs using their program ID and seeds. PDAs are used whenever a program needs to own and control an account: storing program state, holding tokens on behalf of users, creating escrow accounts, and managing protocol treasuries. They are fundamental to almost every non-trivial Solana program.

How much does it cost to deploy a Solana program?

Deploying a Solana program costs rent for the program account (approximately 0.00089 SOL per byte) plus transaction fees. A typical Anchor program of 100-500KB costs 1-5 SOL to deploy. Programs are rent-exempt by default when they maintain the minimum balance. The program account can be closed and rent recovered if the program is no longer needed.

What is Proof of History (PoH) and how does it work?

Proof of History is Solana's cryptographic clock — a verifiable delay function using sequential SHA-256 hashing where each hash's output becomes the next hash's input. This creates an immutable record proving the ordering and timing of events without validators needing to communicate about timestamps. PoH allows validators to agree on transaction ordering with minimal communication, enabling Solana's high throughput. It works in conjunction with Tower BFT consensus.

What is the Solana accounts model and how is it different from Ethereum?

Unlike Ethereum where contracts store their own state, Solana separates code (programs) from data (accounts). Programs are stateless and stored in executable accounts. All state is stored in separate data accounts owned by programs. This enables parallel execution (Sealevel) since the runtime knows upfront which accounts a transaction will access. In Ethereum, every contract call can potentially touch any storage slot, making parallelism difficult.

How do compute units work on Solana?

Every Solana transaction has a compute budget — a limit on the number of computational operations (compute units, CUs) it can consume. The default limit is 200,000 CUs per instruction and 1.4M CUs per transaction. You can request up to 1.4M CUs using the SetComputeUnitLimit instruction. Common operations: basic arithmetic ~1 CU, cross-program invocation ~1,000 CUs, SHA256 hash ~100 CUs. Exceeding the budget causes the transaction to fail with 'ComputationalBudgetExceeded'.

What is the difference between a Solana program and a smart contract?

They are functionally equivalent — 'program' is Solana's terminology for what Ethereum calls a 'smart contract'. Key differences: Solana programs are stateless (state lives in separate accounts), programs are upgradeable by default (unless the upgrade authority is set to null), programs execute in a sandboxed BPF VM, and programs can be written in Rust, C, or C++ rather than Solidity. The term 'program' reflects Solana's Unix-inspired design philosophy.

How do I get SOL for development and testing?

For devnet: use 'solana airdrop 2' (CLI) or the web faucet at faucet.solana.com. For testnet: use the testnet faucet. For mainnet: purchase SOL on a centralized exchange (Coinbase, Binance, Kraken) and withdraw to your wallet, or use a DEX. For development, always start on devnet where SOL is free. Note: devnet airdrops are rate-limited; if you need large amounts for testing, request multiple times or use multiple wallets.

What is the Solana Token Program and how do I create a token?

The Solana Token Program (spl-token) is the standard program for creating and managing fungible tokens. To create a token: (1) Create a mint account with 'spl-token create-token', (2) Create a token account to hold the tokens with 'spl-token create-account ', (3) Mint tokens with 'spl-token mint '. Programmatically, use the @solana/spl-token library. For advanced features like transfer fees, confidential transfers, and permanent delegates, use Token-2022 (Token Extensions Program).

What is rent on Solana and how does it work?

Rent is a mechanism to incentivize validators to store account data. Accounts must maintain a minimum SOL balance proportional to their data size (currently ~0.00089 SOL per byte × 2 years of rent). Accounts meeting this minimum are 'rent-exempt' and persist indefinitely. Accounts below the minimum are eventually garbage collected. In practice, you should always create rent-exempt accounts. The minimum for a token account is ~0.00203 SOL; for a basic data account it depends on the data size.

How do I read on-chain data from a Solana program?

Use the JSON-RPC API via @solana/web3.js: connection.getAccountInfo(pubkey) returns raw account data. For Anchor programs, use the program.account. .fetch(pubkey) method which automatically deserializes the account data using the IDL. For token accounts, use getTokenAccountBalance() or getParsedAccountInfo(). For multiple accounts at once, use getMultipleAccountsInfo() to reduce RPC calls. For real-time updates, subscribe with accountSubscribe() or use gRPC streaming.

What is a Solana RPC node and what does it do?

A Solana RPC (Remote Procedure Call) node is a validator or non-voting node that exposes a JSON-RPC API for querying blockchain state and submitting transactions. It maintains a full copy of the ledger and account state. RPC nodes handle requests like getAccountInfo, sendTransaction, getTransaction, and programSubscribe. They are the primary interface between your application and the Solana network. For production applications, you should use a dedicated RPC provider rather than the public endpoints which have strict rate limits.

What are the best RPC providers for Solana?

Top Solana RPC providers include: Helius (developer-friendly, good free tier, enhanced APIs), QuickNode (multi-chain, reliable, good performance), Triton One (high-performance, used by many DeFi protocols), HighTower (htw.tech — enterprise-grade, ultra-low latency, dedicated infrastructure), Supanode (supanode.xyz — optimized for trading, real-time data), and Ankr (affordable, decentralized). Choice depends on your use case: for trading bots prioritize latency (HighTower, Triton), for analytics prioritize data richness (Helius), for general development any provider works.

What is the difference between confirmed, finalized, and processed commitment levels?

Processed: the transaction has been received by the leader and included in a block, but the block hasn't been voted on yet. Confirmed: the block has been voted on by a supermajority of stake (2/3+). Finalized: the block is permanently part of the chain and cannot be rolled back (typically 31+ confirmations). For reading data: use 'confirmed' for most applications. For critical financial operations: use 'finalized'. For lowest latency: use 'processed' but accept the small risk of rollback. For sending transactions: use 'confirmed' as the minimum.

How do I handle RPC rate limits in my application?

Strategies for handling rate limits: (1) Implement exponential backoff with jitter for retries, (2) Use connection pooling across multiple RPC endpoints, (3) Cache frequently-read data (account balances, program state) with appropriate TTLs, (4) Batch requests using getMultipleAccountsInfo instead of individual getAccountInfo calls, (5) Use WebSocket subscriptions instead of polling, (6) Upgrade to a paid RPC plan with higher limits, (7) Run your own RPC node for unlimited access. For high-frequency trading, dedicated RPC from HighTower or Triton One eliminates rate limit concerns.

What is the difference between RPC and gRPC on Solana?

JSON-RPC is a request-response protocol over HTTP — you ask for data and get a response. It's simple but has overhead from JSON serialization and HTTP. gRPC (specifically Yellowstone gRPC) is a bidirectional streaming protocol over HTTP/2 using Protocol Buffers. gRPC allows you to subscribe to real-time streams of accounts, transactions, blocks, and slots with microsecond latency. For trading applications that need real-time data, gRPC is dramatically more efficient than polling RPC. gRPC reduces latency from 100-500ms (polling) to 10-50ms (streaming).

How do I send transactions with the highest chance of landing?

To maximize transaction landing rate: (1) Use a high-quality RPC endpoint close to validators, (2) Set appropriate priority fees (use getRecentPrioritizationFees to estimate), (3) Set compute unit limit accurately (simulate first), (4) Use Jito bundles for MEV-sensitive transactions, (5) Submit to multiple RPC endpoints simultaneously, (6) Use skipPreflight: false to catch errors early, (7) Implement retry logic with fresh blockhashes, (8) For time-critical transactions, use Shredstream-capable infrastructure like HighTower to submit directly to the leader's TPU.

What is the TPU (Transaction Processing Unit) and why does it matter?

The TPU is the component of a Solana validator that receives and processes transactions. It has four stages: Fetch (receive transactions), SigVerify (verify signatures using GPU), Banking (execute transactions), and Broadcast (propagate results). Submitting transactions directly to the current leader's TPU port (bypassing the RPC layer) can reduce latency by 50-200ms. This is what services like HighTower's direct TPU submission offer — your transaction reaches the leader faster than going through standard RPC forwarding.

How do I implement connection failover for my Solana application?

Implement a connection manager that maintains connections to multiple RPC providers. Use a primary connection for normal operations and automatically failover to backups when errors occur. Pattern: maintain a list of endpoints sorted by priority, track error rates per endpoint, implement circuit breakers that temporarily disable endpoints with high error rates, use health checks (getSlot) to verify endpoint availability. Libraries like @solana/web3.js support multiple endpoints natively. For production trading systems, HighTower and other enterprise providers offer built-in redundancy.

What is getRecentBlockhash vs getLatestBlockhash?

getRecentBlockhash is deprecated in favor of getLatestBlockhash. getLatestBlockhash returns the most recent blockhash and its lastValidBlockHeight — the block height after which the transaction will be rejected. This is more reliable than the old approach of using slot numbers. Always use getLatestBlockhash for new code. The returned lastValidBlockHeight gives you approximately 150 blocks (~60-90 seconds) to submit your transaction before the blockhash expires.

How do I use getProgramAccounts efficiently?

getProgramAccounts fetches all accounts owned by a program — it can return thousands of accounts and is expensive. Optimize it: (1) Use dataSlice to fetch only the fields you need, (2) Use memcmp filters to match specific bytes in account data (e.g., filter by owner pubkey stored in the account), (3) Use dataSize filter to match accounts of a specific size, (4) Cache results and use account subscriptions for updates, (5) For large programs (like Token Program), avoid getProgramAccounts entirely and use indexed data from providers like Helius or HighTower's indexing service.

What is stake-weighted quality of service (swQoS) on Solana?

Stake-weighted QoS is a mechanism where validators prioritize transactions from other validators based on their stake weight. When a validator forwards your transaction to the leader, the leader gives it higher priority if the forwarding validator has more stake. This means using an RPC provider that runs staked validators gives your transactions a better chance of being processed during congestion. Enterprise providers like HighTower and Triton One operate staked validators specifically to provide this benefit to their customers.

How do I monitor RPC node health and performance?

Key metrics to monitor: (1) Slot lag — how far behind the node is from the cluster tip (getSlot vs cluster slot), (2) Response latency — time to respond to getAccountInfo, (3) Error rate — percentage of requests returning errors, (4) WebSocket stability — connection drops and reconnect frequency. Use getHealth to check basic node health. For production, set up alerting when slot lag exceeds 10 slots or response time exceeds 500ms. Consider using multiple providers and routing to the healthiest one.

What is Yellowstone gRPC and how does it differ from standard Solana RPC?

Yellowstone gRPC is a Geyser plugin-based streaming interface for Solana validators. Unlike JSON-RPC which is request-response, Yellowstone provides bidirectional streaming using Protocol Buffers over HTTP/2. You subscribe to streams of accounts, transactions, blocks, slots, and entry data with microsecond delivery. It's 10-100x lower latency than polling RPC for real-time data. Yellowstone is the standard for production trading bots, MEV searchers, and real-time analytics. Most enterprise RPC providers including HighTower and Triton One offer Yellowstone gRPC endpoints.

How do I connect to a Yellowstone gRPC endpoint?

Use the yellowstone-grpc client library. In TypeScript: npm install @triton-one/yellowstone-grpc. Connect with: const client = new Client(endpoint, xToken, {}); const stream = await client.subscribe(); stream.write({ accounts: { client: { account: ['pubkey'], filters: [] } } }); stream.on('data', (data) => { /* handle updates */ }); For Rust: use the yellowstone-grpc-client crate. You need an endpoint URL and authentication token from your provider (HighTower, Triton One, or others).

What can I subscribe to with Yellowstone gRPC?

Yellowstone gRPC supports subscriptions to: (1) Accounts — real-time updates when account data changes, (2) Transactions — every transaction matching your filters (by account, program, or all), (3) Blocks — complete block data including all transactions, (4) Slots — slot status updates (processed, confirmed, finalized), (5) Block meta — block metadata without full transaction data, (6) Entry — individual entries within blocks for maximum granularity. You can combine multiple subscriptions in a single stream and apply complex filters.

How do I filter gRPC transactions by program ID?

In the subscription request, use the accountInclude filter in the transactions subscription: { transactions: { client: { accountInclude: ['programId'], vote: false, failed: false } } }. This delivers only transactions that include the specified program ID in their account list. You can also filter by specific accounts (accountRequired — all listed accounts must be in the transaction), or exclude accounts (accountExclude). Combine filters to get precisely the transaction stream you need without processing irrelevant data.

What is the latency difference between gRPC and WebSocket subscriptions?

gRPC (Yellowstone) typically delivers data 20-100ms faster than WebSocket subscriptions for the same events. WebSocket subscriptions go through the RPC layer which adds processing overhead. gRPC connects directly to the Geyser plugin in the validator, receiving data as soon as it's processed. In practice: WebSocket account updates arrive 50-200ms after confirmation, gRPC account updates arrive 10-50ms after processing. For MEV and high-frequency trading, this difference is significant. HighTower's gRPC infrastructure is specifically optimized to minimize this latency further.

How do I handle gRPC stream reconnection?

gRPC streams can disconnect due to network issues, server restarts, or timeouts. Implement robust reconnection: (1) Listen for 'error' and 'end' events on the stream, (2) Implement exponential backoff (start at 100ms, max at 30s), (3) Track the last received slot to detect gaps after reconnection, (4) Re-subscribe with the same filters after reconnecting, (5) Use a ping/keepalive mechanism to detect dead connections early. For critical applications, maintain connections to multiple gRPC endpoints and failover instantly.

What is the Geyser plugin interface?

The Geyser plugin interface is a Solana validator plugin system that allows external processes to receive real-time notifications of validator state changes. Plugins are loaded by the validator at startup and receive callbacks for: account updates, transaction notifications, block metadata, slot status changes, and entry notifications. Yellowstone gRPC is the most popular Geyser plugin implementation, exposing these events via gRPC. Other implementations include plugins that write to Kafka, PostgreSQL, or Redis.

How do I process gRPC data at high throughput without dropping messages?

For high-throughput gRPC processing: (1) Use async processing — don't block the stream handler, push to a channel/queue, (2) Use multiple worker threads/goroutines to process messages in parallel, (3) Implement backpressure — if your processing is slower than the stream, buffer messages and alert when buffer grows, (4) Use Protocol Buffers efficiently — avoid unnecessary deserialization of fields you don't need, (5) For Rust, use tokio with multiple worker threads, (6) For TypeScript, use worker_threads for CPU-intensive processing. HighTower's infrastructure is designed to handle the full Solana transaction throughput.

Why do I need an indexer for my Solana application?

The Solana RPC API is optimized for real-time queries on current state, not complex historical queries. You cannot efficiently query 'all swaps on Raydium in the last 24 hours' or 'all NFT transfers for a wallet' via RPC. An indexer processes the blockchain in real-time, transforms the data into a structured format, and stores it in a queryable database. This enables SQL-like queries, aggregations, historical analysis, and complex joins that would be impossible or prohibitively slow via RPC.

What is ClickHouse and why is it the best database for Solana indexing?

ClickHouse is an open-source columnar OLAP database designed for analytical queries on large datasets. It excels at Solana indexing because: (1) Columnar storage — queries that touch only a few columns scan minimal data, (2) Vectorized execution — processes millions of rows per second per core, (3) MergeTree engine — optimized for append-heavy workloads like blockchain data, (4) Real-time ingestion — handles 500,000+ inserts/second, (5) Compression — blockchain data compresses 5-10x, (6) SQL interface — familiar query language. Benchmarks show ClickHouse is 10-100x faster than PostgreSQL for typical blockchain analytics queries.

How do I set up a basic Solana indexer with ClickHouse?

Basic setup: (1) Run a Solana validator or connect to a gRPC endpoint (HighTower, Triton), (2) Subscribe to the transaction stream via Yellowstone gRPC, (3) Parse transactions using Anchor IDL or custom parsers, (4) Insert parsed events into ClickHouse using the HTTP interface or native protocol, (5) Create materialized views for common aggregations. Schema example: CREATE TABLE solana_transactions (signature String, slot UInt64, block_time DateTime, accounts Array(String), program_ids Array(String)) ENGINE = MergeTree() ORDER BY (slot, signature). Use ReplacingMergeTree for accounts that update frequently.

What are the different types of Solana indexers?

Solana indexers fall into several categories: (1) Transaction indexers — store all transactions with parsed instruction data, (2) Account indexers — track account state changes over time, (3) Event indexers — extract and store program events (Anchor events), (4) DEX indexers — specialized for swap events, liquidity changes, and price data, (5) NFT indexers — track mints, transfers, sales, and metadata, (6) Full-node indexers — index everything (like HighTower's ClickHouse-based solution). Choose based on your query patterns — event indexers are most efficient if you only need specific program data.

What indexer providers are available for Solana?

Major Solana indexer providers: HighTower (htw.tech) — enterprise ClickHouse-based indexer with full transaction history and custom query support; Helius — developer-friendly APIs with parsed transaction data and NFT indexing; Triton One — high-performance infrastructure with indexing capabilities; Supanode (supanode.xyz) — real-time indexing with streaming APIs; Goldsky — managed subgraph and mirror pipeline service; Bitquery — multi-chain analytics with Solana support. For custom high-performance indexing, HighTower's ClickHouse solution handles the full Solana throughput with sub-second query latency.

How do I query historical Solana transactions efficiently?

For historical queries: (1) Use an indexer service (HighTower, Helius, Supanode) rather than RPC — standard RPC only stores ~2 epochs of history, (2) For your own indexer, use ClickHouse with a schema sorted by (slot, signature) for time-range queries, (3) Use date-partitioned tables for efficient pruning, (4) Create materialized views for common aggregations (daily volume, unique users), (5) For very old data (>6 months), consider BigTable archival nodes. Never use getSignaturesForAddress with large ranges against standard RPC — it's slow and rate-limited.

How do I parse Solana transaction instructions?

Parsing approaches: (1) For Anchor programs — use the IDL to decode instructions automatically with program.coder.instruction.decode(), (2) For known programs — use community parsers like @metaplex-foundation/mpl-token-metadata or @raydium-io/raydium-sdk, (3) For unknown programs — decode the instruction data as raw bytes and reverse-engineer the format, (4) Use Helius's parseTransaction API for automatic parsing of 100+ known programs. For custom indexers, maintain a registry of program IDLs and use the appropriate decoder for each program ID encountered.

What is the best way to index Raydium swap events?

For Raydium V4 swaps: subscribe to transactions that include the Raydium AMM program ID (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8) via gRPC. Parse the SwapBaseIn and SwapBaseOut instructions. Extract: input/output mints, amounts, user wallet, pool address, and slot. Store in ClickHouse with schema: (slot, signature, pool_id, user, input_mint, output_mint, input_amount, output_amount, price). For Raydium CLMM (concentrated liquidity), parse the Swap instruction from the CLMM program. The Jupiter aggregator routes through multiple DEXes — parse at the individual DEX level for accurate data.

How do I build a real-time price feed from on-chain data?

Build a real-time price feed: (1) Subscribe to swap events from major DEXes (Raydium, Orca, Jupiter) via gRPC, (2) Calculate spot price from each swap: price = output_amount / input_amount (adjusted for decimals), (3) Use a TWAP (time-weighted average price) over the last N trades to smooth volatility, (4) Store in Redis for low-latency reads and ClickHouse for historical analysis, (5) Handle decimal precision carefully — use BigInt arithmetic, (6) Account for slippage — large swaps move the price, use smaller swaps for more accurate spot prices. Pyth Network provides institutional-grade price feeds as an alternative.

What is the difference between event-based and account-based indexing?

Event-based indexing: subscribe to transactions, parse instruction data and program logs to extract events (swaps, transfers, mints). Pros: captures the intent of operations, easy to understand, good for analytics. Cons: requires parsing logic for each program, can miss state changes not reflected in events. Account-based indexing: subscribe to account updates via Geyser, store the full account state at each change. Pros: always accurate, captures all state changes. Cons: high data volume, requires understanding account schemas. Best practice: use event-based for analytics and account-based for state tracking (e.g., current liquidity pool reserves).

How does HighTower's indexing infrastructure work?

HighTower (htw.tech) operates a production-grade Solana indexing infrastructure built on ClickHouse. Their system ingests the full Solana transaction stream via a custom Geyser plugin, parses all major program interactions, and stores the data in a highly optimized ClickHouse cluster. Key features: sub-second query latency on billions of rows, full transaction history from genesis, real-time updates with <1 second lag, custom query support via SQL, and REST/gRPC APIs. This eliminates the need to run your own indexing infrastructure, which typically requires multiple servers and significant engineering effort.

How do I handle blockchain reorganizations in my indexer?

Solana has very rare reorganizations (forks), but they do occur. Handle them: (1) Use 'confirmed' commitment level for indexing — data at this level is extremely unlikely to be rolled back, (2) For 'processed' data, implement a reorg detection mechanism by tracking slot hashes, (3) Use ReplacingMergeTree in ClickHouse with a version column — if you re-index a slot, the newer version replaces the old, (4) For critical financial data, use 'finalized' commitment only, (5) Implement a 'pending' state for processed data that transitions to 'confirmed' after sufficient confirmations.

How do I build a Solana trading bot?

Building a Solana trading bot requires: (1) Market data feed — use gRPC streaming from HighTower or Triton One for real-time price data, (2) Signal generation — implement your trading strategy (arbitrage, momentum, market making), (3) Order execution — build and sign transactions with appropriate priority fees, (4) Risk management — position limits, stop losses, daily loss limits, (5) Infrastructure — low-latency RPC endpoint, ideally with direct TPU access, (6) Monitoring — real-time P&L tracking, error alerting, position monitoring. Start with a simple strategy on devnet, then paper trade on mainnet before risking real capital.

What is MEV on Solana and how does it differ from Ethereum?

MEV (Maximal Extractable Value) on Solana differs from Ethereum in key ways: Solana has no public mempool (transactions go directly to the leader), so traditional frontrunning is harder. Instead, MEV on Solana occurs through: (1) Jito bundles — atomic transaction bundles that execute in order, (2) Backrunning — placing transactions immediately after a known profitable transaction, (3) Liquidations — being first to liquidate undercollateralized positions, (4) NFT sniping — buying underpriced NFTs. The Jito block engine is the primary MEV infrastructure on Solana, allowing searchers to submit bundles with tips.

How do I integrate with Jupiter for token swaps?

Jupiter is the leading DEX aggregator on Solana. Integration: (1) Use the Jupiter API (quote.jup.ag) to get swap quotes: GET /quote?inputMint=...&outputMint=...&amount=...&slippageBps=50, (2) Get the swap transaction: POST /swap with the quote response, (3) Sign and submit the transaction. For programmatic use, use the @jup-ag/api package. For on-chain integration, use the Jupiter CPI interface. Jupiter routes through 20+ DEXes to find the best price. For high-frequency trading, run your own Jupiter routing to avoid API rate limits.

Solana Dev Portal

Developer Documentation

Frequently Asked Questions

Comprehensive answers to the most common questions about building on Solana — covering infrastructure, trading, indexing, NFTs, and development.

Frequently Asked Questions

Getting Started

Infrastructure & RPC

gRPC & Streaming

Indexing & Data

Trading & DeFi

Meme Tokens

Arbitrage & MEV

NFTs

Developer Tools

Performance & Optimization

Security

Troubleshooting

Analytics & Data

Token Standards

Wallets & Keys

Cross-Chain

Staking & Validators