Skip to main content
Solana uses an account-based architecture where data is stored in accounts and mutated by programs (smart contracts).
Jupiter is deployed on Solana mainnet only.

​
Core Concepts

  • Programs - Executable code deployed on-chain. They define instructions, process transactions, and interact with accounts.
  • Accounts - Store data on-chain. Mutable by their owning program.
  • Instructions - Defined by programs, similar to API endpoints.
  • Transactions - Bundles of one or more instructions sent to the network.
See the official Solana docs for Web3.js and Rust client libraries.

​
Interacting with Jupiter

The Swap API’s order and execute path handles transaction building, sending, priority fees, and compute optimisation for you. No RPC required.

​
Transaction Fundamentals

​
Priority Fees

An optional fee to improve transaction landing speed. Higher priority fee = higher position in the execution queue. Priority Fee = Compute Budget x Compute Unit Price (excluding the 5,000 lamport base fee).
Overpaying priority fees drives up costs across the network over time. Estimate appropriately rather than always bidding high.

​
Compute Units

Compute Units (CU) measure the resources a transaction needs. The Solana runtime caps transactions at 1.4M CU, with a default of 200K CU per instruction. You can set a custom limit with SetComputeUnitLimit.

​
Slippage

A threshold (percentage or bps) that causes the transaction to fail if the actual output falls below the quoted amount by that margin. Tighter slippage protects against price movement but makes landing harder.

​
Transaction Broadcasting

Transactions reach the network via:
  1. Standard RPCs
  2. RPCs with Stake-Weighted Quality of Service (SWQoS)
  3. Jito RPC