Solana transaction construction including instruction building, account resolution, compute budget, priority fees, and versioned transactions

Solana 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: 1. Signatures : One or more Ed25519 signatures (64 bytes each) 2. 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: Account Meta Every account referenced in an instruction has metadata: 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 ( 0x80 for v0) The same message structure as legacy An additional address table lookups array 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. 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 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 Sets the price per CU in micro lamports. This is the priority fee mechanism. The total priority fee is: Priority Fee Estimation To estimate an appropriate priority fee: 1. Call getRecentPrioritizationFees RPC method with the accounts your transaction touches 2. Look at the median or 75th percentile fee from recent slots 3. During congestion, fees spike — monitor and adjust dynamically Common Transaction Patterns 1. SOL Transfer The simplest transaction: a System Program transfer. Accounts required: 1. Sender (signer, writable) 2. Recipient (writable) 2. SPL Token Transfer Transferring SPL tokens requires the Token Program. Accounts required: 1. Source token account (writable) 2. Destination token account (writable) 3. Owner/delegate (signer) 3. Create Associated Token Account (ATA) Before transferring tokens, the recipient must have an Associated Token Account. Accounts required (in order): 1. Payer (signer, writable) — pays rent 2. Associated token account (writable) — the ATA to create 3. Wallet address — owner of the new ATA 4. Token mint 5. System Program 6. 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: 1. Get a quote from /quote 2. Get swap instructions from /swap instructions 3. Build transaction with setup instructions + swap instruction + cleanup instructions 4. Add compute budget instructions 5. Simulate, then sign and send Simulation Always simulate before sending. Use the simulateTransaction RPC method: 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 BlockhashNotFound Blockhash expired (~60 90s) Fetch new blockhash and rebuild InsufficientFunds Not enough SOL for fees + transfer Check balance before building AccountNotFound Token account doesn't exist Create ATA first ProgramFailedToComplete Exceeded compute budget Increase compute unit limit TransactionTooLarge Over 1232 bytes Use ALTs or split into multiple txs InvalidAccountData Wrong account passed to instruction Verify account derivation SignatureVerificationFailed Missing or wrong signer Check all is signer accounts signed Retry Strategy Transaction Decoding To decode an existing transaction from the chain: Integration with Other Skills solana rpc : Provides the RPC connection layer for submitting and querying transactions jupiter api : Supplies swap instructions that this skill assembles into transactions dex execution : Orchestrates the full execution flow using transactions built by this skill mev analysis : Evaluates MEV risk of constructed transactions before submission helius api : Enhanced transaction parsing and webhook based confirmation tracking Safety Checklist Before submitting any transaction to mainnet: 1. Simulate first — always call simulateTransaction before sendTransaction 2. Verify accounts — confirm all account addresses are correct (especially for token transfers) 3. Check balances — ensure sufficient SOL for fees and any transfers 4. Review compute budget — set appropriate CU limit based on simulation 5. Confirm priority fee — check current network fees, do not overpay 6. Never auto sign — require explicit user confirmation before signing 7. Use devnet for testing — build and test on devnet before mainnet 8. Log everything — record transaction signatures, simulation results, and errors Files References references/transaction anatomy.md — Message format, versioned transactions, compute budget, blockhash management references/common instructions.md — Instruction layouts for System, Token, ATA, Compute Budget, Memo, and Jupiter programs Scripts scripts/build transfer.py — Build and simulate a SOL transfer transaction (demo mode, never signs) scripts/decode transaction.py — Fetch and decode on chain transactions with program identification

solana-tx-building