Transaction Policy

A spending limit is a rule that caps the value or quantity of assets that can be transferred in a single transaction or over a defined period (e.g., daily, weekly). This is a fundamental guardrail for risk management.

• Example: A policy could limit withdrawals to 1 ETH per day or $5,000 per transaction.
• Purpose: Mitigates the impact of a compromised key or human error by containing potential losses.

An allowlist (whitelist) specifies a set of pre-approved destination addresses, while a blocklist (blacklist) defines prohibited addresses. Transactions can only be sent to allowlisted addresses or are blocked if the recipient is on a blocklist.

• Use Case: An organization's treasury policy might only allow payments to verified vendor addresses.
• Security Benefit: Prevents funds from being sent to unknown or malicious smart contracts or wallets.

A time lock imposes a mandatory waiting period between when a transaction is proposed and when it can be executed. This creates a cooling-off period for review.

• Implementation: A multi-signature wallet might require a 24-hour delay on any transfer over 10 ETH.
• Security Rationale: Provides a window to detect and cancel unauthorized or erroneous transactions before funds are irreversibly moved.

A multi-signature requirement mandates that a transaction must be approved by a predefined number of authorized signers (m-of-n) before execution. This distributes trust and control.

• Common Configurations: 2-of-3 for a small team, 5-of-9 for a DAO treasury.
• Key Feature: Eliminates single points of failure; no single compromised key can drain funds.

These rules govern the gas parameters of a transaction. A gas limit caps the computational work a transaction can consume, while a max fee or gas price cap limits the price paid per unit of gas.

• Purpose: Prevents transaction failure due to out-of-gas errors and protects against wallet-draining attacks that use excessively high gas prices.
• Example: A policy may reject any transaction with a max fee above 150 Gwei.

This feature controls which smart contracts a wallet or set of keys is permitted to interact with. It can restrict interactions to a specific contract address or a set of verified DeFi protocols.

• Security Imperative: Critical for preventing approval phishing attacks, where a user unknowingly grants a malicious contract unlimited spending access to their tokens.
• Implementation: Often works in tandem with allowlists to only permit interactions with audited, known contracts.

A transaction policy defines the validity conditions for a transaction, replacing the simple requirement of a valid cryptographic signature. This allows for complex logic such as:

• Time-locks: "Execute only after block 15,000,000."
• Multi-signature schemes: "Require 3 of 5 specified signatures."
• Spending limits: "Cannot transfer more than 1 ETH per day."
• Delegated execution: "Only this smart contract can submit transactions for this account."

Policies enable seamless user experiences by abstracting transaction mechanics. Common applications are:

• Gaming Session Keys: A policy grants a game server temporary rights to perform specific actions (e.g., mint an NFT) without requiring a wallet pop-up for each move.
• Sponsored Transactions: A dapp's paymaster policy pays gas fees for users, removing the need to hold the native token.
• Batch Operations: A single policy can validate a bundle of actions, like approving a token and swapping it in one user-approved step.

Enforcing policies shifts security considerations. Critical aspects include:

• Policy Verification: The policy engine (often part of the wallet or a dedicated module) must correctly interpret and enforce rules without introducing vulnerabilities.
• Revocation: Mechanisms for revoking session keys or updating policies are essential.
• Auditability: Policies must be transparent and auditable. Projects like Candide and ZeroDev provide frameworks and SDKs for building secure policy-based smart accounts.

A core function of transaction policies is to restrict asset movement to pre-approved addresses or contracts. This prevents drainer attacks and unauthorized withdrawals even if a private key is compromised. Common implementations include:

• Allowlists/Denylists: Explicitly permitting or blocking specific destination addresses.
• Spending Limits: Capping the maximum value or frequency of transfers within a time window.
• Time Locks: Requiring a mandatory waiting period before a withdrawal is finalized.

Policies can block interactions with known malicious or risky smart contracts. This is a defense against phishing scams and approval exploits. Security mechanisms include:

• Code Hash Verification: Allowing transactions only to contracts with a specific, verified bytecode hash.
• Deployer Allowlisting: Permitting interactions only with contracts from trusted developer addresses.
• Simulation & Pre-flight Checks: Running a transaction simulation to detect potential malicious state changes before signing.

Transaction policies can be designed to protect users from Maximal Extractable Value (MEV) exploitation. By controlling transaction parameters, they reduce the profitability of predatory strategies like sandwich attacks. Key controls are:

• Slippage Limits: Setting a maximum acceptable price impact for swaps.
• Deadline Enforcement: Causing a transaction to fail if not mined within a specified block range, preventing stale orders from being exploited.
• Private Transaction Relays: Routing transactions through services that obscure the mempool to prevent front-running.

Policies enforce complex authorization logic beyond a single private key, distributing trust and preventing single points of failure. This is essential for treasury management and corporate wallets. Standard models include:

• M-of-N Multi-signature (Multisig): Requiring signatures from a threshold of designated signers.
• Hierarchical Approvals: Mandating different approval levels based on transaction value or type.
• Session Keys: Granting limited, time-bound authority to specific applications without exposing the master key.

For institutional users, transaction policies can encode regulatory and internal compliance requirements directly on-chain. This enables programmable compliance and audit trails. Examples include:

• Sanctions Screening: Automatically blocking transactions with addresses on OFAC or other sanctions lists.
• Jurisdictional Gating: Restricting interactions based on geolocation or user verification status (KYC).
• Transaction Memo Requirements: Mandating that certain transfers include specific reference data for accounting and reporting.

A secure policy framework must balance rigidity with the need for emergency intervention. Time-locked upgrades and circuit breakers are critical safety features.

• Policy Upgrade Delay: Enforcing a mandatory waiting period (e.g., 48 hours) before any change to the security policy takes effect, allowing stakeholders to review.
• Emergency Freeze/Halt: A privileged function (often via multisig) to immediately pause all transactions in response to a critical vulnerability or hack.
• Recovery Mechanisms: Pre-defined processes for asset recovery in case of lost keys, without creating a centralized backdoor.