Skip to main content
POST
/
v1
/
simulate
/
solana
/
transaction
Simulate Solana Transaction
curl --request POST \
  --url https://api.range.org/v1/simulate/solana/transaction \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "tx": "AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAMFEJeb5qTc67efsgZI7ONZ7zVxpO4dt1RQdJUXALHbMrqWD8daOMRtjpRGL/NJrFK4+dloWCuEb9yNAU0iiTXfswbd9uHXZaGT2cvhRs7reawctIXtX1s3kTqM9YV+/wCpHONZ7VoBLgT6FCucdRocXofP0KAWG5yF/9MbeM382PbG+nrzvtutOj1l82qryXQxsbvkwtL24OR8pgIDRS9dYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwIDAQMACQQA5AtUAgAAAAIEAQQDAAoNAOQLVAIAAAAGAgIBAAEF",
  "encoding_type": "base64"
}
'
{}
Simulate a Solana transaction to analyze its effects and risks before broadcasting it to the network. Returns detailed instruction parsing, asset transfers, balance changes, state predictions, and account risk scoring.

​
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.

​
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 POST request with header Content-Type: application/json and this JSON body:
{
  "payload": "<ENCODED_TRANSACTION>",
  "encoding_type": "base64"
}
3

Analyze the Response

Review instruction_groups, asset_transfers, lamport_changes, expected_state_changes, transaction_risk, transaction_summary, and error to understand effects and risks.
Cluster support: devnet, testnet, mainnet-beta

​
Key Features

  • Instruction Parsing — Automatic parsing for all programs with public IDLs. For programs without public IDLs, we reverse-engineer the instruction format (marked with "reverse_engineered": true).
  • Nested Transaction Decoding — Squads v4 embedded transaction messages and Squads v3 addInstruction operations are automatically decoded and parsed.
  • State Change Predictions — Predicted account and token updates based on simulation.
  • Asset Movement Analysis — Detects token and SOL transfers with source, destination, mint, and amount.
  • Account Risk Scoring — Risk assessment of all involved addresses, including malicious address proximity analysis.
  • Exploit Risk Detection — Identifies potential exploit behaviors such as address poisoning attacks.

​
Response Breakdown

FieldDescription
instruction_groupsHierarchical view of all instructions with parsed data, program IDs, and stack depth.
asset_transfersDetected asset movements (SOL and token transfers) with source, destination, mint, and amount.
lamport_changesBalance changes by address showing pre and post-execution balances.
expected_state_changesPredicted account-level state updates with formatted details and metadata for UI rendering.
transaction_riskRisk analysis containing accounts_risk_score (per-address risk with summary statistics) and exploit_risks_detected.
returned_dataData returned by programs during execution.
logsComplete transaction execution logs from the Solana runtime.
transaction_summaryCompute units consumed, fee breakdown (compute fee, prioritization fee, tips), programs invoked, and transaction version.
errorFailure reason if simulation failed. Other fields may be incomplete when present.

​
Fee Confidence

The transaction_summary includes a fee confidence indicator:
LevelMeaning
HighDerived from explicit compute budget instructions
MediumEstimated from recent prioritization fees for the locked accounts
LowNo data available; fallback logic used
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.
We continuously add support for new program parsers. If there is a specific program you’d like included, contact us with the request.

Authorizations

​
Authorization
string
header
required

Use Authorization: Bearer

Body

application/json
​
tx
string
required

Encoded raw transaction (base64 or base58)

Minimum string length: 1
Example:

"AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAMFEJeb5qTc67efsgZI7ONZ7zVxpO4dt1RQdJUXALHbMrqWD8daOMRtjpRGL/NJrFK4+dloWCuEb9yNAU0iiTXfswbd9uHXZaGT2cvhRs7reawctIXtX1s3kTqM9YV+/wCpHONZ7VoBLgT6FCucdRocXofP0KAWG5yF/9MbeM382PbG+nrzvtutOj1l82qryXQxsbvkwtL24OR8pgIDRS9dYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwIDAQMACQQA5AtUAgAAAAIEAQQDAAoNAOQLVAIAAAAGAgIBAAEF"

​
encoding_type
enum<string>
required

Encoding type of the transaction

Available options:
base64,
base58
Example:

"base64"

Response

201 - application/json

The response is of type object.

Last modified on March 2, 2026