Learn-skills.dev solana-tx-building
Solana transaction construction including instruction building, account resolution, compute budget, priority fees, and versioned transactions
git clone https://github.com/NeverSight/learn-skills.dev
T=$(mktemp -d) && git clone --depth=1 https://github.com/NeverSight/learn-skills.dev "$T" && mkdir -p ~/.claude/skills && cp -r "$T/data/skills-md/agiprolabs/claude-trading-skills/solana-tx-building" ~/.claude/skills/neversight-learn-skills-dev-solana-tx-building && rm -rf "$T"
data/skills-md/agiprolabs/claude-trading-skills/solana-tx-building/SKILL.mdSolana Transaction Building
This skill covers how to construct, simulate, and inspect Solana transactions programmatically. It addresses the full anatomy of a Solana transaction — from raw instruction encoding to versioned transaction formats, compute budget management, priority fees, and address lookup tables.
Safety: This skill is for transaction construction and analysis only. Scripts in this skill NEVER sign or submit real transactions. Always simulate before sending. Never auto-sign.
Transaction Anatomy
A Solana transaction consists of:
- Signatures: One or more Ed25519 signatures (64 bytes each)
- Message: The serializable payload containing:
- Header: Counts of required signers, read-only signers, read-only non-signers
- Account keys: Array of all pubkeys referenced by instructions
- Recent blockhash: 32-byte hash for replay protection (expires ~60-90 seconds)
- Instructions: Array of program calls
Transaction Size Limit
The hard limit is 1232 bytes for the entire serialized transaction. This constrains how many instructions and accounts you can include. Strategies to stay within the limit:
- Use versioned transactions with Address Lookup Tables (ALTs)
- Minimize the number of accounts per instruction
- Combine related operations into single instructions where supported
- Split complex operations across multiple transactions
Instruction Format
Each instruction contains three fields:
Instruction { program_id_index: u8, // Index into the account keys array accounts: [u8], // Indices into account keys array data: [u8], // Opaque byte array interpreted by the program }
Account Meta
Every account referenced in an instruction has metadata:
AccountMeta { pubkey: Pubkey, // 32-byte public key is_signer: bool, // Must sign the transaction is_writable: bool, // Will be written to by this instruction }
The four combinations determine the account's role:
| is_signer | is_writable | Role |
|---|---|---|
| true | true | Fee payer, token owner performing transfer |
| true | false | Multisig co-signer, read-only authority |
| false | true | Destination account, PDA being written |
| false | false | Program ID, sysvar, clock |
Legacy vs Versioned Transactions
Legacy Transactions
The original format. All accounts must be listed in the account keys array. With the 1232-byte limit, you can fit roughly 20-35 accounts depending on instruction data size.
Versioned Transactions (v0)
Introduced to support Address Lookup Tables (ALTs). A v0 transaction includes:
- A version prefix byte (
for v0)0x80 - The same message structure as legacy
- An additional
arrayaddress_table_lookups
ALTs let you reference accounts by a compact index into an on-chain table rather than including the full 32-byte pubkey. This dramatically increases the number of accounts a transaction can reference.
AddressTableLookup { account_key: Pubkey, // The ALT account address writable_indexes: [u8], // Indices for writable accounts readonly_indexes: [u8], // Indices for read-only accounts }
When to use v0: Any transaction referencing more than ~20 accounts, Jupiter swaps with multi-hop routes, complex DeFi interactions.
Compute Budget
Every transaction has a compute budget that determines how many compute units (CUs) it can consume and what priority fee to pay.
Compute Budget Instructions
Two key instructions from the Compute Budget Program (
ComputeBudget111111111111111111111111111111):
1. Set Compute Unit Limit
Instruction data: [0x02, <units as u32 LE>]
Sets the maximum CUs this transaction can consume. Default is 200,000 per instruction (max 1,400,000 per transaction). Setting this lower than needed causes the transaction to fail. Setting it higher wastes budget but does not cost more (you only pay for requested, not consumed).
2. Set Compute Unit Price
Instruction data: [0x03, <micro_lamports as u64 LE>]
Sets the price per CU in micro-lamports. This is the priority fee mechanism. The total priority fee is:
priority_fee = compute_unit_limit * compute_unit_price / 1_000_000
Priority Fee Estimation
To estimate an appropriate priority fee:
- Call
RPC method with the accounts your transaction touchesgetRecentPrioritizationFees - Look at the median or 75th percentile fee from recent slots
- During congestion, fees spike — monitor and adjust dynamically
import httpx def get_priority_fees(rpc_url: str, accounts: list[str]) -> list[dict]: """Fetch recent prioritization fees for given accounts.""" resp = httpx.post(rpc_url, json={ "jsonrpc": "2.0", "id": 1, "method": "getRecentPrioritizationFees", "params": [accounts] }) return resp.json()["result"]
Common Transaction Patterns
1. SOL Transfer
The simplest transaction: a System Program transfer.
# System Program transfer instruction data layout: # [2, 0, 0, 0] (u32 LE = instruction index 2 = Transfer) # + amount as u64 LE (lamports) import struct def build_sol_transfer_data(lamports: int) -> bytes: """Build instruction data for a SOL transfer.""" return struct.pack("<I", 2) + struct.pack("<Q", lamports)
Accounts required:
- Sender (signer, writable)
- Recipient (writable)
2. SPL Token Transfer
Transferring SPL tokens requires the Token Program.
# Token Program transfer instruction: # [3] (instruction index 3 = Transfer) # + amount as u64 LE def build_token_transfer_data(amount: int) -> bytes: """Build instruction data for an SPL token transfer.""" return bytes([3]) + struct.pack("<Q", amount)
Accounts required:
- Source token account (writable)
- Destination token account (writable)
- Owner/delegate (signer)
3. Create Associated Token Account (ATA)
Before transferring tokens, the recipient must have an Associated Token Account.
# ATA Program: instruction index 0 = Create # No instruction data needed (empty bytes) ATA_PROGRAM_ID = "ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL"
Accounts required (in order):
- Payer (signer, writable) — pays rent
- Associated token account (writable) — the ATA to create
- Wallet address — owner of the new ATA
- Token mint
- System Program
- Token Program
4. Jupiter Swap
Jupiter provides a
/swap-instructions endpoint that returns pre-built instructions. See the jupiter-api skill for full details.
General flow:
- Get a quote from
/quote - Get swap instructions from
/swap-instructions - Build transaction with setup instructions + swap instruction + cleanup instructions
- Add compute budget instructions
- Simulate, then sign and send
Simulation
Always simulate before sending. Use the
simulateTransaction RPC method:
def simulate_transaction(rpc_url: str, tx_base64: str) -> dict: """Simulate a transaction without submitting it. Args: rpc_url: Solana RPC endpoint URL. tx_base64: Base64-encoded serialized transaction. Returns: Simulation result with logs and compute units consumed. """ resp = httpx.post(rpc_url, json={ "jsonrpc": "2.0", "id": 1, "method": "simulateTransaction", "params": [ tx_base64, {"encoding": "base64", "replaceRecentBlockhash": True} ] }) result = resp.json()["result"] if result["value"]["err"]: print(f"Simulation failed: {result['value']['err']}") for log in result["value"].get("logs", []): print(f" {log}") else: cu = result["value"].get("unitsConsumed", 0) print(f"Simulation OK — {cu} compute units consumed") return result
The
replaceRecentBlockhash: True flag lets you simulate even if your blockhash has expired, which is useful for testing transaction construction without timing pressure.
Error Handling
Common transaction errors and their causes:
| Error | Cause | Fix |
|---|---|---|
| Blockhash expired (~60-90s) | Fetch new blockhash and rebuild |
| Not enough SOL for fees + transfer | Check balance before building |
| Token account doesn't exist | Create ATA first |
| Exceeded compute budget | Increase compute unit limit |
| Over 1232 bytes | Use ALTs or split into multiple txs |
| Wrong account passed to instruction | Verify account derivation |
| Missing or wrong signer | Check all accounts signed |
Retry Strategy
import time def send_with_retry( rpc_url: str, build_fn, max_retries: int = 3, base_delay: float = 0.5 ) -> dict: """Build and send a transaction with blockhash refresh on expiry. Args: rpc_url: Solana RPC endpoint. build_fn: Callable that takes a blockhash and returns a signed tx. max_retries: Maximum retry attempts. base_delay: Base delay between retries in seconds. Returns: Send result from RPC. """ for attempt in range(max_retries): blockhash = get_latest_blockhash(rpc_url) tx = build_fn(blockhash) result = send_transaction(rpc_url, tx) if "error" not in result: return result err = result["error"] if "BlockhashNotFound" in str(err): time.sleep(base_delay * (attempt + 1)) continue raise RuntimeError(f"Transaction failed: {err}") raise RuntimeError("Max retries exceeded")
Transaction Decoding
To decode an existing transaction from the chain:
def decode_transaction(rpc_url: str, signature: str) -> dict: """Fetch and return a parsed transaction. Args: rpc_url: Solana RPC endpoint. signature: Transaction signature (base58). Returns: Parsed transaction data. """ resp = httpx.post(rpc_url, json={ "jsonrpc": "2.0", "id": 1, "method": "getTransaction", "params": [ signature, {"encoding": "jsonParsed", "maxSupportedTransactionVersion": 0} ] }) return resp.json()["result"]
Integration with Other Skills
: Provides the RPC connection layer for submitting and querying transactionssolana-rpc
: Supplies swap instructions that this skill assembles into transactionsjupiter-api
: Orchestrates the full execution flow using transactions built by this skilldex-execution
: Evaluates MEV risk of constructed transactions before submissionmev-analysis
: Enhanced transaction parsing and webhook-based confirmation trackinghelius-api
Safety Checklist
Before submitting any transaction to mainnet:
- Simulate first — always call
beforesimulateTransactionsendTransaction - Verify accounts — confirm all account addresses are correct (especially for token transfers)
- Check balances — ensure sufficient SOL for fees and any transfers
- Review compute budget — set appropriate CU limit based on simulation
- Confirm priority fee — check current network fees, do not overpay
- Never auto-sign — require explicit user confirmation before signing
- Use devnet for testing — build and test on devnet before mainnet
- Log everything — record transaction signatures, simulation results, and errors
Files
References
— Message format, versioned transactions, compute budget, blockhash managementreferences/transaction_anatomy.md
— Instruction layouts for System, Token, ATA, Compute Budget, Memo, and Jupiter programsreferences/common_instructions.md
Scripts
— Build and simulate a SOL transfer transaction (demo mode, never signs)scripts/build_transfer.py
— Fetch and decode on-chain transactions with program identificationscripts/decode_transaction.py