When you run sui client dev-inspect, you’re basically simulating a transaction in a sandbox so you don’t spend gas or mutate global state, and the output gives you snapshots of what would happen if the transaction were real. You’ll see sections for effects, events, return values, and sometimes object changes. To debug, you should look at return values first—these show what your Move function produced, often in JSON-encoded form, so you can verify logic without waiting for finality. Next, check the object changes: even though they’re not actually committed, dev-inspect lists how ownership, balances, or fields would be updated, which helps confirm if your transfer, mut, or move_to calls are correct. Events are especially useful for tracing custom debug logs—design your modules to emit structured events so you can trace state transitions without clutter. If you see an Abort code, cross-reference it with your module’s defined error codes (or abort values) to know exactly which condition triggered the failure. Here’s a simple example:

sui client dev-inspect --gas-budget 10000000 \
  --module my_module --function transfer_token \
  --args <sender_id> <receiver_id> <amount>

This would output something like:

{
  "effects": { "status": "success" },
  "events": [{ "event_type": "TokenTransferred", "amount": 100 }],
  "return_values": ["true"]
}

Think of dev-inspect as a “dry run” of your transaction. It simulates the call, shows you what would happen, but never commits changes or burns gas. The output usually has three key parts:

1. Effects → What objects or states would be created, mutated, or deleted.
2. Events → Any Move events your code emits.
3. Execution status / errors → Whether the transaction would succeed or fail, and why.

To debug, focus first on the execution status—if there’s an error, the stack trace points you to the failing Move function. Then check effects to see if objects updated the way you expected. If something looks off, use the event logs and returned values to trace the logic.

When you run sui client dev-inspect, you’re basically simulating a transaction without committing it on-chain or paying gas, so you can see exactly how your Move function behaves. To make sense of the output, focus on three main sections. The effects show you how objects would be created, updated, or deleted if the transaction were real, which helps you confirm state changes. The events display any logs you emitted from Move using event::emit, which are great for tracing logic step-by-step. The return values give you the data returned from the function call, which you can use to check if arguments and computations are working as expected. One common confusion is mixing object IDs and package IDs, so always double-check that you’re passing the right object reference into the call. For example:

sui client dev-inspect \
  --package 0x123...abc \
  --module my_module \
  --function my_function \
  --args 0x456...def 1000

When you use sui client dev-inspect, you are simulating a transaction to see what would happen on-chain without actually paying gas or committing changes. The output gives you a breakdown of execution effects, return values, and any state changes that would occur if the transaction went through. To read it properly, first look at the effects section, which shows what objects were read, written, mutated, or deleted — this helps you confirm whether the correct assets or states are being touched. Then check the return values, which come from the Move function you called, to ensure the logic returns what you expected. Pay attention to any events emitted, since these are often how dApps signal key actions like transfers or swaps. If the simulation shows an error or abort, the logs will include the specific Move abort code, which you can cross-reference in your module to pinpoint what went wrong. Since dev-inspect doesn’t advance object versions, you should not confuse it with a real transaction — it’s just a safe way to test and debug.