Wallet Spending Policy

What Is a Wallet Spending Policy?

A wallet spending policy is a collection of configurable rules that determine which outgoing transactions a wallet will sign and broadcast. Rather than giving every key holder unlimited authority to move funds, a spending policy imposes guardrails: maximum amounts per transaction, cumulative caps over time windows, restrictions on which addresses can receive funds, and escalation requirements for high-value transfers.

In traditional finance, spending controls are standard: corporate credit cards have daily limits, wire transfers above certain thresholds require dual authorization, and treasury operations follow strict approval workflows. Wallet spending policies bring equivalent controls to cryptocurrency, where the irreversibility of transactions makes prevention far more important than remediation.

The enforcement mechanism varies by wallet type. On Bitcoin, spending conditions can be encoded directly into Script using Miniscript. On Ethereum, account abstraction enables smart contract wallets to validate transactions against arbitrary rules before signing. MPC custody providers enforce policies in their signing infrastructure, blocking unauthorized operations before any key share participates in the signing ceremony.

How It Works

Spending policies operate as a gating layer between transaction initiation and transaction signing. When a user or automated system requests a transfer, the policy engine evaluates the request against its ruleset before allowing the signing process to proceed.

1. A transaction request specifies the destination, amount, asset, and any metadata
2. The policy engine checks the request against all active rules: per-transaction limits, cumulative velocity windows, destination allowlists, time-of-day restrictions, and signer requirements
3. If the request passes all checks, it proceeds to signing (either automatically or after collecting the required approvals)
4. If any rule is violated, the request is rejected, queued for additional approval, or escalated to higher-authority signers

Common Policy Rules

Most policy engines share a common set of rule types, though the specifics of enforcement and configuration differ across implementations:

Miniscript Policies on Bitcoin

Miniscript is a structured subset of Bitcoin Script that makes spending conditions composable and analyzable. Rather than writing raw Script opcodes, developers express policies in a human-readable format that compiles to valid Bitcoin Script.

Bitcoin Core added Miniscript support for P2WSH output descriptors in version 24.0 and extended it to Taproot (P2TR) descriptors in version 26.0. Wallets like Nunchuk and Liana now ship generalized Miniscript support for consumer use.

# Miniscript policy example: tiered spending authority
# Key A can spend alone up to a timelock
# Keys A+B can spend anytime (2-of-2)
# After 90 days, Key C (recovery) can spend alone

thresh(1,
  and(pk(key_A), older(12960)),
  and(pk(key_A), pk(key_B)),
  and(pk(key_C), older(12960))
)

Because Miniscript policies compile to on-chain Script, enforcement is trustless: the Bitcoin network itself validates the conditions. No external server or policy engine can be bypassed. The tradeoff is that policies are fixed at UTXO creation time. Changing a policy requires moving funds to a new address with updated conditions.

Session Keys in ERC-4337 Smart Wallets

ERC-4337 smart wallets on Ethereum enforce spending policies through programmable validation logic. The wallet contract itself decides whether to authorize a transaction, enabling policies that go far beyond what an externally owned account can express.

Session keys are temporary, scoped signing keys that a smart wallet grants to applications or agents. Each session key carries its own spending policy:

• Maximum transfer amount per transaction or per time window (daily, weekly, or monthly resets)
• Allowlisted contract addresses and function selectors the key may call
• Token restrictions limiting which ERC-20 assets the key can move
• Expiry timestamps after which the session key becomes invalid

Enforcement happens on-chain in the smart account's validation logic. A session key that attempts to exceed its scope produces an invalid UserOperation that the bundler rejects before it reaches the blockchain. This makes the policy tamper-proof: even if the session key is compromised, the attacker cannot exceed the granted permissions. For a deeper look at how session keys enable automated wallet interactions, see the research on smart wallet session key payments.

Policy Engines in MPC Custody

MPC wallet providers like Fireblocks, BitGo, and Copper enforce spending policies as a layer between transaction initiation and the threshold signing process. The policy engine evaluates every transaction request before any key share participates in signing.

These engines typically support the full range of rule types: amount limits, velocity controls, destination allowlists and blocklists, time-based restrictions, and tiered approval workflows. A transaction that violates any rule is blocked before signing begins, so the funds never leave the wallet.

The key difference from on-chain enforcement is trust: MPC policy engines run on the provider's infrastructure. The organization trusts the provider to faithfully execute the rules. In exchange, MPC policies are far more flexible: they can be updated instantly, apply across multiple blockchains, integrate with sanctions screening services, and route approvals to specific individuals based on role.

Use Cases

Institutional Treasury Management

Corporate treasuries holding cryptocurrency face the same governance requirements as traditional finance: segregation of duties, dual authorization for large transfers, and audit trails. Spending policies formalize these controls.

A typical institutional setup layers multiple rules: routine payments below a threshold (such as payroll or vendor payments) auto-approve with a single signer, mid-range transfers require two authorized signers, and large movements require a quorum of executives plus a time delay that allows cancellation. Destination allowlists ensure funds can only move to pre-approved counterparties.

Agentic Wallets and AI Automation

As AI agents increasingly interact with blockchain systems, spending policies become the safety layer that constrains autonomous behavior. An agentic wallet might grant a trading bot a session key with a daily spending cap, a restricted set of allowed protocols, and a maximum trade size: enough authority to operate but not enough to drain the wallet if compromised or misconfigured.

For a comprehensive look at how policy architectures protect AI-managed wallets, see the research on AI agent wallet policy architecture.

Progressive Custody and Parental Controls

Spending policies enable progressive custody models where a user's authority grows over time. A custodian might start a new user with low daily limits and a restricted destination list, then gradually increase authority as trust is established.

The same pattern works for parental controls on family wallets: children receive a key with strict per-transaction and daily limits, a parent key can override or adjust policies, and a timelocked recovery key provides a safety net if primary keys are lost.

Operational Security for DAOs

DAOs use spending policies to limit the authority of operational multisig wallets. A grants committee might have a monthly spending cap and an allowlist of approved grant recipients, while the full treasury requires a governance vote. Tiered policies let DAOs operate efficiently at small scale while maintaining community oversight for large expenditures.

Comparing Enforcement Approaches

Risks and Considerations

Policy Misconfiguration

The most common cause of spending policy failures is misconfiguration, not infrastructure compromise. An overly permissive policy (high limits, broad allowlists, few required signers) provides little protection. An overly restrictive policy blocks legitimate operations and may pressure operators to bypass controls entirely.

Getting policies right requires understanding the organization's actual transaction patterns: typical amounts, frequency, and destinations. Policies should be tested against historical transactions before deployment, and adjusted as operational needs change.

Recovery and Lockout

On-chain policies (Miniscript, smart wallet validation) cannot be overridden without the keys and conditions specified in the policy itself. If a policy requires two keys and one is lost, funds may be inaccessible unless a recovery path was included in the original policy design. This makes careful planning of recovery conditions essential before committing funds to a policy-governed address.

Off-Chain Enforcement Risks

MPC policy engines depend on the provider's infrastructure being available and honest. If the provider experiences an outage, policy evaluation (and therefore signing) stops. If the provider is compromised, policies could theoretically be modified or bypassed. Organizations using MPC custody should evaluate the provider's security architecture, audit practices, and business continuity guarantees.

Policy Drift

Spending policies require ongoing maintenance. As an organization grows, adds new counterparties, or changes its operational patterns, policies must be updated to match. Stale policies: either too loose because new risks were not accounted for, or too tight because legitimate new workflows were not added: create operational friction and security gaps. Regular policy reviews (quarterly at minimum) are a standard practice in institutional custody.

Complexity vs. Security Tradeoff

More granular policies provide tighter control but increase complexity. A policy with dozens of rules, tiered thresholds, and time-based exceptions is harder to audit, harder to maintain, and more likely to contain unintended interactions between rules. The goal is the simplest policy that adequately constrains risk, not the most elaborate one possible.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.