Simulation versus mainnet: what a dry run can tell you

A dry run can answer “does this logic fit the inputs?” It cannot answer “did the mainnet ledger record this activity?” That difference is the whole point of separating simulation from Points.

Four signals that look similar

Consider a proposed swap with four possible outputs:

Output	What it means
Constructed route	The inputs were shaped into a possible action
Simulation result	The chosen test environment or local logic produced a result
Wallet approval	A person authorized the transaction shown in the wallet
Confirmed digest	The network and service can read a settled, verified event

The first two are useful before signing. They can reveal an invalid asset type, a missing amount, a malformed schema, or a route that cannot be assembled. They do not create a mainnet event and they do not make Points appear.

What to test in a dry run

Use a simulation to test one narrow question at a time. For a review-only assistant flow, that might be whether a wallet string is canonical, whether two coin types are different, whether the requested action maps to #pit, or whether a response parser keeps unavailable separate from an empty result. For a transaction builder, it might be whether the supplied inputs form a valid shape in the chosen environment.

An invalid asset is a useful negative case: the tool or application should reject it and tell you what to correct. A successful dry run is a useful positive case: it shows that the test path handled those supplied inputs. Neither outcome says that a wallet has signed, that the network accepted a transaction, or that a service ledger verified activity.

The local participant boundary

The SUI BROKERS participant kit is intentionally review-only. Its five read tools perform bounded GET requests, while suibrokers_prepare_action creates a plan with an app route and no prefilled transaction parameters. The plan explicitly prohibits quoting, building, signing, sending, wallet boot, referral activation, and NFT minting.

That design makes a simulation or plan easy to describe: it is an input to a later human review. If a host displays a green tool result, keep the word “plan” or “simulation” in the explanation. Do not call it a confirmed trade.

Mainnet proof comes later

If you choose to continue, open the app, connect the intended wallet explicitly, inspect the current asset and amount, and read the final transaction in the wallet. Only after signing and confirmation should you look for a service row with its digest, status, verification state, verified volume, and Points. A copied digest without a service readback is still incomplete evidence.

The current rule credits one Point per $4 of verified Swap volume. If a later verified record contains $80 of eligible volume, the arithmetic is 20 Points. That example is about interpreting a confirmed record; it does not turn a simulation into a reward or predict an allocation. The AI-assisted swap guide traces the same handoff in detail.

When an assistant compares the two phases, ask it to label its evidence: test input, simulated output, wallet decision, network digest, and ledger readback. A clear label is more useful than a confident sentence that collapses all five into “success.”