Automate any transaction from your backend

A wallet policy is a rule-based authorization control that decides whether a wallet may perform a signing operation, evaluated on every request before any signature is produced. Each policy holds an ordered list of rules, and each rule pairs one operation with an action — accept or reject — and a list of criteria that must all match.

Spending policies, transaction limits and the signed audit trail are the wallet-layer primitives that compliance and monitoring programs are built on. They are not a KYC/AML product. Openfort integrates with identity-verification and transaction-screening vendors; it does not provide KYC, AML or sanctions screening itself.

Enforceable control types

• Spending limits. Per-transaction value caps on native transfers (ethValue, solValue) and token transfers (splValue), plus caps on decoded ERC-20 arguments such as a transfer amount. Rolling per-period totals are not aggregated by the policy engine.
• Allowlists and denylists. Recipient addresses matched with in or not in, up to 100 addresses per criterion.
• Contract and method restrictions. Calldata matched against a contract ABI by function name, with constraints on the decoded arguments by name or position.
• Network restrictions. Chain ID allowlists and denylists, and Solana program ID and mint address restrictions.
• Message and typed-data controls. Regex matching on personal-sign messages, EIP-712 verifying contract and field constraints, and outright rejection of raw hash signing.
• Session keys. Scoped signers registered on the smart account with a contract whitelist, a maximum number of operations, and single-call revocation.
• Time bounds. Session-key validity windows set by validAfter and validUntil, enforced by the account contract.
• Per-agent policy scoping. A policy scoped to one backend wallet by account ID, so each agent carries its own rules on top of the project-wide baseline.
• Approval thresholds. The engine has two actions, accept and reject. A rule that rejects above a threshold stops the transaction; routing it to a human approver and resubmitting is handled in your own workflow.

Where enforcement happens

Enforcement sits in two places, and neither is your application code.

• API-side, before signing. The policy engine evaluates every request before key shares are assembled, so a rejected request produces no signature and burns no gas. Policies are ordered by priority, criteria within a rule use AND logic, the first matching rule wins, and the engine fails closed — once a project has one policy, any operation that matches no rule is rejected. policies.evaluate() returns the same decision without performing the operation.
• On-chain, in the smart account. Session-key permissions — contract whitelist, validity window, operation count — are checked by the account contract during execution, so they hold even if the API-side layer is bypassed.

This is the difference from enforcing limits in application code. An application-layer rule only applies on the paths your application controls; a signer-side rule applies to every request that reaches the signer, and an on-chain rule applies to every transaction the account executes.

What the audit trail records

Each transaction record carries:

• the transaction ID, creation and update timestamps, and status
• the chain ID, the account that executed it, the wallet that owns the account, and the fee sponsorship that paid for gas
• every call the transaction executes — destination, value, and either raw calldata or the contract and function name with its arguments
• how it executed: an ERC-4337 user operation (including EIP-7702 delegated accounts) or a plain transaction
• once terminal, a receipt with the transaction hash, block number, gas used, gas fee, cost in USD, and the revert reason when it failed

Policy decisions are recorded separately: policies.evaluate() returns whether the operation was allowed, the reason, and the IDs of the policy and rule that matched.

How the audit trail is retrieved

• API. GET /v2/transactions returns transactions most recent first, filtered by account, user, wallet, chain, fee sponsorship, or status. expand=timeline adds the ordered lifecycle history with timestamps; expand=logs adds the receipt event logs.
• Webhooks. Transaction events (broadcast, successful, failed, cancelled) and balance-threshold events are pushed as HTTPS POSTs signed with an HMAC-SHA256 digest in the openfort-signature header, so the receiving system can verify the payload was not altered in transit.
• Delivery logs. The dashboard records every webhook delivery attempt with its status, response code, and payload.

The full rule model, criteria types and operators are in the policies documentation. For how these primitives map onto an enterprise controls review, see AI agent wallet compliance: custody and control requirements and wallet policy engines compared across five vendors.