To integrate Solana into a Web3 project, you point your application at a node connection and send it JSON-RPC calls. Reads like account balances, writes like signed transactions, block lookups — all of it travels over that one connection. You either run the node yourself or rent access from a provider.
That is the whole shape of it. The rest of this guide fills in the parts that matter: how the connection works, which tools you install, the methods you’ll call most, and the things that quietly break once real traffic hits.
What does “integrating Solana” actually involve?
Integrating Solana means giving your app a way to talk to the network and getting structured answers back. A node holds the current state of the chain. Your app asks it questions — or asks it to broadcast a transaction — through a request format called JSON-RPC.
JSON-RPC is a protocol where you call a function by name and pass arguments in the request body. You send a POST request with a small JSON payload, and the node runs the matching procedure and returns the result. It’s function-based, so instead of hitting different URL paths like a REST API, you call getBalance, getTransaction, or getBlock against a single address.
How is this different from a REST API?
REST organizes everything around resources and URL paths: /accounts/123, /blocks/456. JSON-RPC keeps one address and switches behavior by method name. For blockchain work this fits well, because the “resources” are really a fixed set of node operations that every client needs to call the same way.
Why do Web3 projects need a node connection?
Without a connection to a node, your app is blind. It can’t read a wallet’s holdings, can’t check whether a transfer confirmed, and can’t submit anything on-chain. Every balance you display and every button that sends SOL depends on a live link to the network.
The honest problem is that running your own Solana node is demanding. A validator-class machine wants many CPU cores, 256–512 GB of RAM in practice, fast NVMe storage, and a high-bandwidth connection, plus someone to keep it synced and patched as the client updates. For a lot of teams that’s a full-time job wrapped around what was supposed to be a side quest.
That’s the gap a managed connection fills. You skip the hardware and the on-call rotation and get a hosted address to query right away.
Who connects to Solana this way?
Most products that touch the chain need this layer. The common ones:
- Wallets — reading balances and token holdings, building and sending transfers.
- Block explorers and dashboards — pulling blocks, slots, and transaction details to display.
- dApp front-ends — DeFi, NFT marketplaces, games, and anything a browser wallet connects to.
- Analytics and indexing tools — scanning historical blocks and transactions for data.
- Trading bots — polling state and submitting transactions on tight timing.
- Staking interfaces — tracking epochs, validators, and delegation requirements.
Should you run your own node or use a provider?
For most projects, a managed provider wins until you have a specific reason not to. Running your own node gives you full control and no third party in the path; a provider removes the setup, the sync time, and the maintenance. Here’s the trade-off side by side.
| Factor | Self-hosted Solana node | Managed node provider |
|---|---|---|
| Setup time | Days to provision, sync, and tune | Minutes to get an address and key |
| Hardware | High-spec server (many cores, 256 GB+ RAM, NVMe) | None — hosted for you |
| Maintenance | You patch, monitor, and re-sync | Handled by the provider |
| Historical data | You run an archive node yourself | Archive access offered as a feature |
| Control | Complete | Scoped to the plan and API |
| Best for | Large teams, latency-sensitive infra | Early projects, most dApps, fast shipping |
If you go the managed route, a provider like NOWNodes gives you a Solana address over JSON-RPC and WebSockets, covering mainnet and testnet, with archive access for historical queries and a free tier to start. The practical upside is that you can be calling methods the same afternoon instead of babysitting a sync.
Solana node setup is still worth understanding even if you outsource it, because it explains what you’re paying someone else to carry: the storage growth, the version upgrades, and the uptime pressure.
Which tools do you use to connect?
You have three realistic paths, and they’re not mutually exclusive.
@solana/kit is the current official JavaScript SDK. It’s the renamed 2.x line of @solana/web3.js — the rename landed in February 2025 — rebuilt to be modular, zero-dependency, and much smaller in the bundle. In Kit, the old Connection class is gone; you create a client with createSolanaRpc() and call methods on it. (Kit on GitHub)
@solana/web3.js 1.x is the legacy library. Plenty of production code still runs on it, and it still works, but new projects should start on Kit.
Raw JSON-RPC works from any language with an HTTP client — Python’s requests, Go, Rust, or plain curl. No SDK required. This is the lowest-level option and the one every example in this guide can fall back to.
Connecting from the browser with a wallet
For a front-end dApp, the connection splits in two. Your app reads the chain through a node address, but signing is delegated to the user’s wallet (Phantom, Solflare, and others) through the Solana wallet-adapter. The wallet holds the keys and approves transactions; your node connection broadcasts them. Never put a private key in front-end code or in an environment the browser can read.
How to connect your app to Solana, step by step
Here’s the minimal path from nothing to a confirmed transaction.
- Get a node address and key. Run your own node, or sign up with a provider and copy the Solana address plus any API key.
- Pick your client. Install
@solana/kitfor JavaScript/TypeScript, or just prepare an HTTP client in your language of choice. - Create the connection. Point the client at your address.
- Make a read call. Fetch a balance to confirm the link works.
- Build and send a transaction. Get a fresh blockhash, assemble the transaction, sign it, and broadcast it.
- Confirm it. Look up the signature to verify finality and status.
A read call over raw JSON-RPC looks like this:
bash
curl https://your-endpoint-here -s -X POST -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getBalance",
"params": ["vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg"]
}'The same read in @solana/kit:
javascript
import { createSolanaRpc, address } from '@solana/kit';
const rpc = createSolanaRpc('https://your-endpoint-here');
const { value } = await rpc
.getBalance(address('vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg'))
.send();
console.log(value); // balance in lamportsBalances come back in lamports, Solana’s smallest unit. One SOL equals 1,000,000,000 lamports, so divide by a billion for a human-readable figure.
Core Solana methods you’ll call most
A handful of methods cover the majority of integration work. This table is the quick map; the notes below it cover the three that trip people up.
| Method | Returns | Typical use |
|---|---|---|
getBalance | SOL balance of an address, in lamports | Showing wallet balances |
getLatestBlockhash | Current blockhash for signing | Building any transaction |
getTransaction | Full transaction + metadata by signature | Confirming and auditing transactions |
getSlot | Current slot number | Timing and monitoring |
getBlock | Block contents for a slot | Explorers, indexing |
getEpochInfo | Current epoch and progress | Staking and validator tools |
getStakeMinimumDelegation | Minimum stake, in lamports | Staking interfaces |
getTransaction — read a transaction by signature
Call getTransaction with a transaction signature to pull its full record: status, logs, inner instructions, and pre/post account balances. It’s what powers a transaction detail page and what you use to confirm a transfer landed.
bash
curl https://your-endpoint-here -s -X POST -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getTransaction",
"params": ["<SIGNATURE>", {"maxSupportedTransactionVersion": 0}]
}'One gotcha worth burning into memory: if you omit maxSupportedTransactionVersion, the call fails whenever it hits a versioned transaction. Setting it to 0 covers today’s versioned format. (Solana RPC method reference)
getEpochInfo — track the staking cycle
Solana runs in epochs, and getEpochInfo reports where the network is in the current one. It returns epoch (the epoch number), slotIndex and slotsInEpoch (progress through the epoch), absoluteSlot, blockHeight, and transactionCount. Staking dashboards and validator pages lean on it to show how far along a cycle is.
bash
curl https://your-endpoint-here -s -X POST -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getEpochInfo"
}'getStakeMinimumDelegation — the floor for staking
If your product lets users stake, you need the minimum they’re allowed to delegate. getStakeMinimumDelegation returns that floor in lamports. On a recent mainnet query the value was 1,000,000,000 lamports — exactly 1 SOL — but read it live rather than hardcoding it, since it’s a network parameter that can change. (getStakeMinimumDelegation docs)
What breaks once you’re in production?
The sample calls work on day one. These are the things that bite later.
- Deprecated methods.
getRecentBlockhashhas been removed and is no longer supported on Solana. UsegetLatestBlockhashto build transactions, andgetFeeForMessageto estimate fees — the old fee calculator came bundled with the removed method and no longer exists. - Commitment levels. Methods accept a
commitmentofprocessed,confirmed, orfinalized. Usefinalizedfor anything involving money;processedis fast but can still be rolled back. - Versioned transactions. As above, pass
maxSupportedTransactionVersionongetTransactionand related calls, or legacy-only parsing will throw on modern transactions. - Rate limits. Shared connections cap requests. If you’re polling aggressively, batch your calls, cache what doesn’t change, and move to a higher plan or a dedicated connection before you hit the ceiling.
- Historical depth. A standard node prunes old data. Pulling transactions or blocks from months back needs an archive node — run one or use a provider that offers archive access.
- Live updates. Polling
getSlotin a loop is wasteful. For real-time events, open a WebSocket subscription instead of hammering HTTP.
Putting it together
Integrating Solana comes down to three decisions: where your node connection lives, which client you call it with, and which methods your product actually needs. Pick a managed connection to ship fast, reach for @solana/kit on new JavaScript projects, and build around the current methods — getLatestBlockhash, getTransaction, getEpochInfo, and friends — rather than the removed ones.
Start on devnet, confirm your reads and a test transaction behave, then switch the address to mainnet. If you’d rather not stand up infrastructure first, a hosted Solana connection through NOWNodes lets you test the whole flow today and scale the plan as traffic grows. The documentation lists the exact methods supported.
FAQ
What educational resources help you use Solana node providers effectively?
Start with the official Solana developer docs for the method reference, then use Solana Stack Exchange for specific problems and the Anza/Agave GitHub repositories to see how the client behaves under the hood. Your provider’s own docs matter too, since they document supported methods, limits, and archive availability. Working through small scripts on devnet teaches more than reading alone.
How much does it cost to connect a Web3 project to Solana?
It ranges from free to usage-based. Public connections exist but are rate-limited and unreliable for anything real. Managed providers typically offer a free tier for development and paid plans priced by request volume or dedicated capacity. Running your own node has no per-request cost but a real hardware and maintenance bill. Check the plans page for current provider pricing.
What’s the difference between Solana’s mainnet, devnet, and testnet connections?
Mainnet is the live network where real SOL and real value move. Devnet is a free sandbox with airdropped test tokens, meant for building and debugging. Testnet is where validators and the Solana team stress-test upcoming releases. Build on devnet, then switch your address to mainnet when you’re ready to go live.
Is @solana/web3.js still usable, or do I have to move to Kit?
The 1.x line of @solana/web3.js still works and plenty of production apps run on it. It’s now the legacy option, though — the 2.x line became @solana/kit, which is where active development and new features go. Existing code doesn’t have to migrate immediately, but start new projects on Kit.
