TransactionGuard (policy checks before transaction execution)

[Dominik1999]

Feature description

The transaction guard

Introduce a TransactionGuard mechanism that lets an account enforce programmable pre-execution policy checks on a transaction. The guard is implemented as a second smart contract that the primary account (mutlisig) calls via Foreign Procedure Invocation (FPI) with the TransactionSummary as input. If the guard deems the transaction invalid (e.g., violates spending limits, touches a blacklisted address/asset, etc.), it returns a failure code that causes the transaction to abort.

We should ship pre-coded, configurable guard templates (spending limits, allow/deny lists, allowed assets) and wallet UX to attach/configure a guard without writing code.

Goals

• Allow an account A to register a guard account G and a target guard procedure (e.g., G::check_tx).
• Pass a TransactionSummary (or digest + Summary via advice map) to G::check_tx via FPI.
• Abort the transaction if G::check_tx returns failure (boolean false or error code).
• Provide pre-coded guard templates with configurable:
  • Spending limits (per-tx, daily, rolling window)
  • Whitelist/blacklist of counterparties (account IDs)
  • Allowed assets (by faucet ID)
• Expose a UI to attach a guard and configure parameters (no code needed).

Technical implementation idea

The multisig contract could store the AccountID of the guard in a defined storage slot. That way we can change it later without changing the actual account code. The procedure to change the guard should require n/m signatures.

Before any transaction gets finally executed, after signature verification, the guard contract should be called via an FPI-call. We can call the foreign procedure with the Digest of the TransactionSummary.

The Guard contract would now re-hash the provided TransactionSummary and compare it with the Digest that it was called with.

After a successful check, the TransactionSummary can be read and the contents can be checked against user-defined checks.

If any check fails, the whole transaction errors out.

Why is this feature needed?

• Security & governance: Projects and institutions need defense-in-depth beyond signature checks (limits, whitelists, compliance rules).
• Composability: Guards should be reusable, upgradeable components callable via FPI, preserving Miden’s modular account model.
• UX parity with EVM multisigs: Safe-like policy controls are a widely adopted pattern; bringing this natively to Miden reduces adoption friction.
• Determinism & privacy: Policy checks run client-side / verifiably within Miden’s model; no reliance on off-chain oracles for basic policies.