How it works
The propose, simulate, check, sign or reject flow that enforces every action on a Botanary account.
Whether it's the owner sending money, a device co-signing, or a delegated agent acting under a mandate, every action that touches a Botanary account follows the same shape: build an unsigned operation, preview it, enforce the rules that actually bind it, and only then sign - or reject it outright.
The flow
Simulate before you sign
Before anyone is ever asked to sign, the action is previewed: an advisory rules check runs alongside a real simulated call, and both must pass for the preview to say the action will succeed. This preview is fail-closed - if the simulator is unreachable or a check can't be completed, the preview reports failure rather than silently passing. A transaction that can't be previewed is never presented for signature.
Simulation is advisory. It tells you what the chain is expected to do - it never authorizes anything by itself.
The chain is the actual authority
The preview is a courtesy; the enforcement that matters happens on-chain, at one of two points:
- In validation, before the operation is even accepted - this is where a delegated session's own policy (its budget, its allowed recipients, its allowed contracts) is checked. An out-of-scope call here is dropped before inclusion: no on-chain trace at all.
- In execution, after the operation is accepted - this is where the account's own rules (AgentGuard) run: frozen check, then denied contracts, then denied recipients, then allow-lists, then spending caps. A decline here still lands on-chain as an included-but-reverted operation - real evidence that something was attempted and stopped.
Either way, nothing signed off-scope ever moves funds. A 4xx response with a decline reason means the account's own rules refused the action at build time, before any operation reaches the chain - not an on-chain revert; the server never overrides what's actually enforced on-chain.
Sign, relay, and only then it's real
The backend never holds a signing key and never signs on the owner's behalf. It builds the unsigned operation; the owner, a device, or an authorized session key signs it client-side; only the signed operation is relayed to the bundler. Relaying is availability, never authority - the server cannot alter what a signed operation does.
Once relayed, an operation settles into one of a few outcomes: mined (included and succeeded), reverted (included, but execution failed - still a real, evidence-bearing transaction), rejected (the bundler never accepted it - no on-chain trace at all), or pending.
Every outcome is logged
The moment an operation reaches a terminal outcome, it's reconciled into the account's audit log exactly once - an append-only, tamper-evident record the owner can review at any time. This is what makes the account auditable: not just what was granted, but what was actually attempted and what actually happened.