Transaction safety

Transaction safety answers a narrow question: does the transaction Aomi built stay inside the App’s rules, and what happens when Aomi rehearses it? The checks begin before a transaction is staged. They continue through simulation and commit. Signing remains a separate decision made by your wallet. Read Permission model for that authority boundary.

​

The guarded transaction lifecycle

This lifecycle contains two kinds of protection:

• Enforcement checks reject a call that violates an active guard or changes a recorded batch.
• Execution evidence comes from simulation. A failed rehearsal tells the agent to stop or rebuild, but simulation does not grant permission and does not create a signature.

​

1. Constrain what can be staged

An App can define the outer boundary for every transaction built in that App. An active protocol skill can narrow that boundary further for the workflow it adds. App and skill guards compose restrictively. Every applicable guard must accept the transaction. One guard cannot override another guard’s rejection, and no guard can expand the wallet’s signing authority.

​

Guarded fields

On EVM chains, a guard can restrict:

• the chain;
• the destination contract;
• the function selector; and
• the spender in an ERC-20 approval.

On Solana, a guard can restrict:

• the cluster;
• every program invoked by an instruction; and
• the instruction discriminator.

If a Solana App requires program or discriminator checks, Aomi must be able to inspect the instructions. An opaque venue transaction cannot bypass that rule; the guarded path rejects it and requires inspectable instructions instead. An App can also declare a per-call USD cap. The cap applies only when the tool supplies the staged call’s usd_amount. Builders must include that value for the guard to compare it. A per-call cap is not a daily or account-wide budget. For the complete fields available on each chain, see EVM guards and Solana guards.

​

2. Keep one authoritative payload

After the guards accept a call, Aomi stores the transaction as a staged record with an ID. Simulation and commit resolve that ID from your session state. The agent does not rewrite the calldata or reconstruct the transaction between those steps.

• EVM stages complete calls. An ordered batch keeps the same staged IDs from simulation through commit.
• Solana can stage inspectable instructions or a serialized transaction. The serialized path preserves the exact transaction bytes.

This separation matters. The model can describe a transaction, but the runtime owns the staged record that later steps execute.

​

3. Simulate the staged transaction

Simulation rehearses the staged payload against current chain state without changing the live chain.

​

EVM simulation

Aomi simulates an EVM batch in order on disposable fork state. Each step sees the state produced by the step before it. The result identifies which calls succeeded, which call reverted, and the reason when the chain provides one. This catches failures that isolated call checks can miss. For example, an approval can succeed while the following protocol call still reverts, or an earlier call can change the balance available to a later call.

​

Solana simulation

Aomi simulates either the transaction assembled from staged instructions or the exact serialized transaction that was staged. The result includes the runtime error and program logs needed to understand a failure. Solana simulation evaluates one transaction at a time. Do not read it as proof that a later transaction will observe the same state.

​

4. Apply protocol-aware checks

A generic simulation can tell you that a call succeeded. It cannot always tell you that the call succeeded for the intended recipient or authority. Runtime protocol skills add that context. Their checks run around the tools used to stage and simulate a transaction. Depending on the protocol, a skill can verify details such as:

• a recipient or onBehalfOf address matches your wallet;
• an approval names the expected protocol spender;
• calldata targets the protocol contract selected by the skill; or
• a quoted route stays within the skill’s supported slippage limits.

A pre-call check can block staging immediately. A post-simulation check can turn an otherwise successful rehearsal into a failed result or attach a warning when the decoded outcome conflicts with the skill’s intent. The agent must report the finding and rebuild within the active policy. It must not rephrase the request to evade the guard.

​

5. Preserve what was checked

When the workflow continues, commit resolves the same staged records again. It verifies that they belong to your session and use one expected wallet and chain. If an EVM batch recorded a simulated order, commit rejects a different set or order instead of silently changing the sequence. The result then reaches the wallet-policy boundary. Guards and simulation have constrained and rehearsed the proposal; your configured approval mode still decides whether anyone may sign it.

​

What blocks, fails, or warns

​

What simulation cannot prove

Simulation is evidence about one payload against one view of chain state. It does not prove that:

• chain state will remain unchanged before broadcast;
• an allowed contract is economically safe;
• a route offers the best available price;
• a user-controlled RPC reports honest state; or
• the transaction is authorized to sign.

That is why Aomi combines simulation with static App constraints, protocol-aware skill checks, payload preservation, and a separate wallet permission boundary.