Transaction Simulation — Move REST API on Movement

Overview

Transaction simulation lets you execute a transaction against the current on-chain state without actually committing it. The simulation returns the full execution result: whether the transaction would succeed, how much gas it would consume, what events it would emit, and what state changes it would produce. This is essential for gas estimation, error debugging, and pre-flight validation before spending real tokens.

Simulation does not submit a transaction to the chain, but the request still needs a structurally valid transaction envelope. In practice, that means the sender and authentication fields must line up with the payload you are simulating. SDK helpers usually build this envelope for you; if you hand-roll the REST request, treat a zero-filled signature as a placeholder rather than a guarantee that any sender will pass validation.

Endpoint

POST /v1/transactions/simulate

Base URL: https://api-movement-mainnet.n.dwellir.com/YOUR_API_KEY/v1

Code Examples

Simulate a Token Transfer

Gas Estimation with Auto-Estimate

Debug a Failing Transaction

Pre-Flight Validation Before Submission

Common Use Cases

Gas Estimation for Wallets

Simulate transactions before showing the user a confirmation dialog. Display the estimated gas cost and warn if the transaction would fail. This is the standard pattern for wallet applications.

Error Debugging During Development

When a transaction fails unexpectedly, simulate it to get detailed error information without spending gas. The vm_status field provides Move abort codes and error messages that help pinpoint the issue.

Batch Transaction Validation

Before submitting a batch of transactions, simulate each one to verify they would all succeed. This is especially important for multi-step workflows where later transactions depend on earlier ones.

Movement-Specific Notes

• Simulation runs against the latest ledger state. If the chain state changes between simulation and submission, the actual result may differ. For volatile state (DEX prices, auction bids), re-simulate immediately before submitting.
• A zero-filled signature is a placeholder for simulation payloads, not a guarantee that any sender/auth-key combination will pass. Keep it for simulation-only requests and do not reuse it for actual submissions.
• Simulation gas usage is a close estimate but may differ slightly from actual execution due to BlockSTM parallel execution dynamics. Add a 10-20% buffer to simulated gas when setting max_gas_amount for the real transaction.
• Use estimate_gas_unit_price=true to get the node's recommended gas price based on current network conditions.

Related Endpoints

• POST /v1/transactions -- Submit the transaction after successful simulation.
• GET /v1/accounts/{address} -- Get the current sequence number for simulation.
• POST /v1/view -- Read state without a transaction (for simpler queries).
• GET /v1/-/health -- Verify the node is healthy before simulating.