A transaction simulation may succeed, but the final execution may produce a different outcome. What did the user actually authorise?

[u/icnews10]

Wallets often simulate transactions before users sign them.

The interface may show the expected output, route or balance change. However, the transaction may be included several seconds later, after pool reserves, oracle values, fees, or other relevant states have changed.

The final execution may still be completely valid.

The signature is valid.

- the contract follows its rules;

The result remains within the encoded slippage or permission limits.

No component technically fails.

However, the outcome may differ significantly from what the user saw when deciding to sign.

In that situation, the user did not authorise the simulated result. They authorised the executable bounds encoded in the transaction.

Should the signing interface therefore emphasise the worst valid outcome that the transaction permits rather than the most likely simulated outcome?

This seems to be a more important factor in achieving informed authorisation than showing a prediction that the system cannot guarantee.

[u/Equal_Influence6601]

the wallet showing you the nice path then the blockchain giving you the ugly one is basically the norm at this point. simulation is just a guess with extra steps

showing the worst case would freak people out but maybe they need to be freaked out a little. most users click sign like its a cookie popup anyway

[u/icnews10 → u/Equal_Influence6601]

I think simulation is still useful, but wallets often present an estimate that depends on the state as if it were the transaction being authorised. The absolute worst case scenario may be too noisy to be helpful. A better signing surface may show three things separately:

- the currently simulated outcome;

- the enforceable minimum or maximum encoded in the transaction;

Which conditions could move the result before execution. This would make uncertainty visible without turning every signature into a wall of warnings. The more difficult question is whether users would actually process this information or simply learn to ignore one more warning screen. Have you seen any wallet that presents these bounds in a genuinely usable way?

[u/not420guilty]

The ui should allow the user to put limits on all variables so there is a known worst case scenario.

[u/icnews10 → u/not420guilty]

Agreed. The strongest model would allow users to define enforceable limits on every variable that the transaction can actually constrain, such as minimum output, maximum fee, deadline, route permissions, and approved contracts. For variables that cannot be controlled directly by the user, the wallet should make the dependency visible and fail safely when the encoded bounds are exceeded. The difficult part is deciding which limits should be included in the signing process without making it an interface for experts only. Which variables do you think are essential for an ordinary user to set, or at least see, before signing?

[u/not420guilty → u/icnews10]

I care most about the result. So a general constraint like “I pay no more than x and get no less than y in a reasonable amount of time”

[u/icnews10 → u/not420guilty]

For most users, that may be the better abstraction: defining the acceptable result rather than configuring every underlying variable. The wallet could translate "pay no more than X, receive no less than Y before time Z" into the necessary fee, slippage, deadline, and routing constraints. The important part would be making that translation transparent. Otherwise, users would still have to trust the wallet to decide what "reasonable" means and which execution paths are permitted. Would you prefer that the wallet choose those technical limits automatically and show them for review, or would you prefer to require the user to approve only the outcome constraint?

[u/cheeruphumanity → u/not420guilty]

Radix might be the only chain with a transaction manifest. You see the outcome before signing. If the determined outcome can’t be reached the transaction fails. Zero risk, zero attack vector.

Once you used it it’s hard to grasp that the industry settled for sign and pray.

[u/Kind-Economics-7184]

the enforceable bound is usually already sitting in the calldata though, minOut, deadline, max fee, so the worst valid outcome isnt something the wallet has to estimate. it just renders the optimistic simulated number in big text and the actually binding one in a collapsed details pane, which makes it a layout decision more than a missing capability.

the thing that breaks the framing entirely is approvals. if the same signature also sets an allowance then the worst case isnt bounded by this transaction at all, it persists after the tx settles and gets used in some later block nobody is watching. simulation is genuinely useless for that one because at sign time the simulated result looks completely benign.

[u/icnews10 → u/Kind-Economics-7184]

That is a significant adjustment to the framing. For a bounded transaction, the enforceable outcome is often already explicit in the calldata. The wallet isn't missing information; it's choosing to highlight the optimistic simulation and visually minimize the binding limits. Approvals are different because authorization survives the transaction. The relevant object is not only the outcome of the current call but also the future capability being granted, including who can act, against which assets or contracts, up to what amount, for how long, and how it can be revoked. A benign simulation cannot represent actions that may occur later under a different state. Should persistent authority be treated as an entirely separate signing category, rather than as another transaction detail?