​

Simulate Solana Transaction

​

POST

​

Overview

​

Why Use This API?

• Pre-Broadcast Validation: Validate a transaction’s execution without committing it to the blockchain.
• Debugging: Identify issues such as program errors or insufficient balances.
• Cost Estimation: Assess fees and compute units before broadcasting.
• Risk Assessment: Identify whether any accounts involved in the transaction are malicious or suspicious.

​

Key Features

• Transaction Simulation: Simulate a raw Solana transaction in a safe, non-committal environment.
• Detailed Logs: Retrieve logs, errors, and result details.
• Resource Insights: View compute units used and fees incurred.
• Instruction Parsing: Automatic parsing of instructions for all programs with public IDLs. For programs without public IDLs, we reverse-engineer the instruction format using proven analysis techniques (marked with “reverse_engineered”: true).
• Nested Transaction Decoding: For Squads v4 transactions, we automatically decode and parse embedded transaction messages. For Squads v3, we decode and parse embedded instructions in addInstruction operations.
• State Change Predictions: See predicted account and token updates.
• Asset Movement Analysis: Detect token and SOL transfers.
• Account Risk Scoring: Evaluate the trustworthiness of accounts involved, including analysis of malicious address proximity and transaction patterns.
• Exploit Risk Detection: Identify potential exploit behaviors such as address poisoning attacks.
• Custom Inputs: Accepts base64-encoded transactions.
• Cluster Flexibility: Simulate on devnet, testnet, or mainnet-beta.

​

Use Cases

• Smart Contract Testing: Ensure expected behavior of on-chain programs.
• Transaction Fee Estimation: Estimate how much SOL a transaction will cost.
• Failed Transaction Debugging: Simulate failed transactions without spending SOL.
• State Validation: Ensure account and asset changes are accurate.
• Security Monitoring: Detect interactions with potentially risky accounts.

​

How to Use

1. Prepare a Transaction Use @solana/web3.js or any other SDK to construct a base64-encoded or base58-encoded Solana transaction.
2. Submit to the endpoint Send a GET request to https://api.range.org/v1/simulate/solana/transaction with header Content-Type: application/json and this JSON body:
   Copy

   {
     "payload": "<ENCODED_TRANSACTION>",
     "encoding_type": "base64"
   }
   
3. Analyze the Response. Review instruction_groups, asset_transfers, lamport_changes, expected_state_changes, accounts_risk_score, transaction_summary, and error to understand effects and risks.

​

Response Breakdown

• instruction_groups: A structured view of all transaction instructions, organized hierarchically with outer instructions and their corresponding inner instructions. Each instruction contains:
  • programId: The program being invoked (pubkey string)
  • program: The program name (only populated when instruction is successfully parsed)
  • parsed: Full parsed instruction data with human-readable account names and decoded arguments (when IDL is available)
  • data: Base58-encoded instruction data (shown only when parsing fails)
  • accounts: Array of account pubkeys involved (shown only when parsing fails)
  • stackHeight: Nesting level in the call stack

Reverse-engineered instruction formats for Anchor programs without public IDLs (marked with "reverse_engineered": true)

• asset_transfers: Any detected asset movements during transaction execution. Includes source, destination, mint, and amount. Shows both SOL transfers and token transfers.
• lamport_changes: List of lamport balance changes by address, showing pre and post-execution balances.
• expected_state_changes: Predicted account-level state updates based on simulation. Includes formatted details like assets, human-readable descriptions of changes, and metadata for UI rendering.
• transaction_risk: Comprehensive risk analysis containing:
  • accounts_risk_score: Risk assessment of all addresses involved in the transaction, including:
    • Individual risk scores for each address
    • Proximity to known malicious addresses
    • Summary statistics (total addresses, high/medium/low risk counts)
  • exploit_risks_detected: Detection of exploit behaviors such as address poisoning attacks
  Note: Risk analysis is currently performed on the main transaction level. Embedded transactions and instructions in nested instruction data are not currently included in risk scoring.
• returned_data: Any data returned by programs during execution.
• logs: Complete transaction execution logs from the Solana runtime.
• transaction_summary: A concise overview including:
  • Compute units consumed
  • Fee breakdown (compute fee, prioritization fee, tips)
  • Programs invoked with their instruction types
  • Transaction version
  Fee Confidence: A qualitative indicator of how reliable the fee estimate is:
  • High: Derived from explicit compute budget instructions
  • Medium: Estimated from recent prioritization fees for the locked accounts
  • Low: No data available; fallback logic used
• error: Indicates if the transaction simulation failed, containing the reason for failure (e.g., AccountNotFound, InsufficientFunds, etc.). If present, other fields may be incomplete as execution terminated early.