Wallet Policy Engines in 2025: Rules, Allowlists, and Smart-Account Governance

Summary: In 2025, wallet policy engines matured from “nice-to-have” approval layers into core risk infrastructure that sits across EOAs, smart accounts, and MPC custody. This guide explains exactly what to implement—on-chain modules, off-chain rule engines, allowlists, and session-key permissions—now that Ethereum’s Pectra upgrade (with EIP‑7702) changed what accounts can enforce natively. (blog.ethereum.org)

What changed in 2025 (and why it matters to your wallet roadmap)

Ethereum’s Pectra upgrade went live on mainnet on May 7, 2025 (epoch 364032) and included EIP‑7702. That EIP lets an EOA permanently set a “delegation indicator” so that it executes code from a designated smart contract, unlocking batching, sponsorship, spending controls, and recovery patterns without migrating funds to a new contract account. In short: EOAs can be governed like smart accounts. (blog.ethereum.org)
EIP‑7702 introduces a new transaction type 0x04 (“set code”), with an authorization list that binds chain ID and nonce, and writes a delegation indicator 0xef0100||address to the account’s code. The delegation is persistent (not just temporary), so your policy strategy must assume long-lived code paths and revocation procedures. (eips.ethereum.org)
Account abstraction guardrails tightened: ERC‑7562 formalizes off-chain validation rules (resource bounds, state isolation, staking+reputation) that bundlers will enforce across ERC‑4337/RIP‑7560 pipelines. If your policies rely on paymasters, factories, or complex validation, you must meet these constraints (or stake). (docs.erc4337.io)
Modular smart-account standards (ERC‑6900, ERC‑7579) and registry extensions (ERC‑7484) gained traction, making policy logic more portable across wallet providers. That means you can install “policy modules” (hooks, guards, allowlists) instead of building monolith accounts. (eips.ethereum.org)

Bottom line: wallets you ship in 2025 should treat “policy” as an enforceable capability at the account layer, not just an operational checklist.

Policy engines: two layers you probably need

There are two complementary enforcement layers. High-signal programs use both.

On-chain, programmable policy modules

For smart accounts (4337/7702/7579/6900), install modules/guards that run pre- and post-execution checks (selectors, destinations, spend limits). Safe now supports Module Guards so global rules apply even when modules execute transactions. (docs.safe.global)
Use a module registry (ERC‑7484) to verify you only enable vetted modules—a critical control when your policy is “code as configuration.” (eips.ethereum.org)
Prefer standards-based validation and hooks (ERC‑6900) so you can swap vendors without re-writing policy logic. (eips.ethereum.org)

Off-chain, enterprise policy engines (MPC/custody)

Institutional platforms like Fireblocks, Coinbase Prime, and BitGo expose granular rule engines: user roles, consensus thresholds, value/velocity limits, address allowlists, transaction/message policies, and integrated compliance screening. These run before keys sign and can block non-compliant flows. (fireblocks.com)

Design principle: on-chain modules give cryptographic enforcement at execution; off-chain engines control signing pathways and provide auditability, consensus, and compliance integrations. Ship both.

Precise controls that work in production

Here’s the specific rule surface we see adopted by leading teams, with implementable details you can copy.

Address allowlists and chain scoping
- Use CAIP‑10 account IDs and CAIP‑2 chain IDs to scope policies across multi-chain fleets (e.g., ethereum:1, base:8453; or chain-agnostic patterns). This avoids “address on wrong chain” footguns and makes your allowlist auditable. (chainagnostic.org)
- MPC vendors implement allowlists with pre-signing enforcement; BitGo exposes programmatic whitelist updates and locks after 48 hours to reduce social-engineering risk windows. Include proxy/implementation addresses if calling via upgradeable contracts. (developers.bitgo.com)
Contract/function allowlists (selector ACLs)
- Permit only specific contracts and ABI selectors. Dynamic’s policy engine evaluates all participant addresses touched during execution—including internal calls—so you must list proxies and implementation targets or you’ll get “false negatives” (blocked transactions). This is a best practice even if you simulate off-chain. (dynamic.xyz)
Value and velocity limits
- Enforce per-asset per-tx caps and rolling windows (e.g., daily/monthly) for stablecoins and native assets. Custody engines (e.g., BitGo) support velocity rules out of the box; mirror them on-chain for critical spend paths to ensure cryptographic enforcement. (dashcentral.org)
Risk/sanctions screening at sign time
- Integrate a sanctions oracle or API (Chainalysis Oracle or Sanctions API). On-chain oracles let you block sanctioned EVM addresses in policy code; REST APIs let MPC engines gate before signing. Keep hashes of OFAC list updates in your evidence store to pass audits. (go.chainalysis.com)
Transaction simulation gates
- Require pre-signing simulation (call trace) and drop transactions whose internal call graph touches any non-allowlisted address or exceeds gas/stack/memory limits. This maps cleanly to ERC‑7562 bundler expectations and reduces griefing. (docs.erc4337.io)
Governance-only flows
- Separate rules for “onchain messages” versus “asset transfers.” Coinbase Prime splits policy engines for transactions and messages, so Dao/DeFi governance calls can require different consensus, signers, and time windows than withdrawals. Mirror this pattern in your stack. (help.coinbase.com)
Session-key and spend-permission scopes
- For consumer UX, grant session keys or “spend permissions” that are time-bound, selector-scoped, and limited to specified ERC‑20 amounts. Alchemy and Coinbase expose granular permission types and expiries; implement revocation UIs and fetch-permissions RPC endpoints. (alchemy.com)

Smart-account governance patterns you should adopt

Safe Guards + Module Guards
- Use a Guard to block dangerous opcodes (e.g., delegatecall) and require that module-originated actions also pass global rules via a Module Guard. This closes a classic gap where modules bypass guard checks. (docs.safe.global)
Modular accounts (ERC‑6900/7579)
- Install validation hooks for: selector allowlists, destination ACLs, per-token spend caps, and time windows. Use ERC‑6900’s separation of execution/validation/hooks to keep policy logic audited and swappable. (eips.ethereum.org)
Module registries (ERC‑7484)
- Before enabling any module, require inclusion in a security-reviewed registry adapter to reduce supply-chain risk. Treat registry gating as a policy rule, not just DevRel guidance. (eips.ethereum.org)
Signature hygiene (ERC‑7739)
- To stop cross-account replay of typed data, deploy ERC‑7739-compatible readable typed signatures for ERC‑1271 flows. This is particularly important when the same EOA owns multiple smart accounts. (eips.ethereum.org)

EIP‑7702: how it changes policy enforcement for EOAs

What to actually implement now that EOAs can run delegated code:

Maintain a “delegation policy” for 7702:
- Only allow delegations to audited code templates you control. The final spec uses persistent delegation—not a temporary mode—so treat a setCode authorization like upgrading the wallet, with rollback paths. (eips.ethereum.org)
- Enforce chain-specific and nonce-bound authorizations in your UX (these are built into the spec) and provide a “Replace/Reset Delegation” one-click action as a break‑glass. (blog.ethereum.org)
Expose spending controls and batching only through your audited delegation target, not from arbitrary app prompts. The spec explicitly warns wallets not to surface a generic “delegate to arbitrary code” UX. Policy: deny unknown delegation targets. (eips.ethereum.org)
If you support both 4337 and 7702, align modules/guards and share your policy set so you don’t fork your governance model across account types. Pectra’s write‑up calls out forward-compatibility with “endgame AA.” (blog.ethereum.org)

Session keys and permissions: standardized in 2025

EIP‑5792 added wallet_sendCalls and capabilities discovery; it’s the right way to advertise batching/gas-sponsorship to apps. Pair this with session keys and spend permissions for interactive apps and agents. (dynamic.xyz)
ERC‑7715 adds wallet_grantPermissions so apps can request scoped permissions (key types, call limits, gas limits, ERC‑20 transfer caps). Make this your default flow for “one-click” UX. (eips.ethereum.org)
Coinbase and Alchemy document concrete permission types (expiry, ERC‑20 caps, native spend caps, contract ACLs). Your policy UI should plainly show these scopes and provide revoke+renew flows. (docs.cdp.coinbase.com)
For builders using EOA-backed 7702, prefer “wallet-managed sessions” (7715) that still honor your on-chain module rules; otherwise, your session runner may bypass the guard path. (eips.ethereum.org)

Compliance-grade screening without killing UX

Use Chainalysis Oracle on-chain for instant block of sanctioned addresses; pair with their Sanctions API off-chain to pre-screen beneficiaries and log SDN evidence hashes (OFAC publishes file hashes for audit verifiability). (go.chainalysis.com)
For higher fidelity, integrate commercial risk scoring (TRM, Elliptic, Scorechain) in the off-chain policy engine and only escalate to humans when risk-out-of-band thresholds trip. Ensure your engine logs the rule that fired, the list version, and a replayable call trace. (scorechain.com)

Concrete architectures you can ship this quarter

Consumer app with smart accounts (4337/7702) and one‑click UX

Account: ERC‑7579 modular account with a “Policy Module” that enforces selector+destination ACLs, ERC‑20 daily caps, and time windows; module installed via ERC‑6900 manifest. (eips.ethereum.org)
Permissions: wallet_grantPermissions (ERC‑7715) for a session key limited to: specific staking contract, two function selectors, 100 USDC/day, 7‑day expiry; show revoke in Settings. (eips.ethereum.org)
Batching: Advertise capabilities via wallet_getCapabilities (EIP‑5792), allow batch swap+stake in one call. (dynamic.xyz)
Bundler safety: ensure your userops pass ERC‑7562 (no deep call stacks or shared mutable state unless staked). Monitor reputation to avoid throttling. (docs.erc4337.io)

Enterprise treasury with MPC custody + DeFi access

MPC policy engine: set per‑desk velocity limits, address-group allowlists per protocol, and separate rules for onchain messages (gov votes) vs asset transfers (withdrawals). Enforce YubiKey‑gated consensus. (help.coinbase.com)
On-chain guard: when interacting with DeFi from a Safe, deploy a Guard that blocks delegatecall and enforces a max slippage parameter encoded in calldata for swaps. Add a Module Guard so all module-originated actions still pass the guard. (docs.safe.global)
Compliance: use sanctions oracle on-chain and API off-chain; store OFAC hash values with each approval artifact. (go.chainalysis.com)

Hybrid EOA → smart‑account migration with 7702

Phase 1 (week 1): ship a “Delegation Check” screen; if no delegation present, offer upgrade to your audited delegation target that adds batching and spending controls. Provide a one‑tap revoke/replace. (eips.ethereum.org)
Phase 2 (week 2–3): install a policy module (ERC‑6900/7579) with the same ACLs used by your custody engine; enable session keys for trusted apps through 7715. (eips.ethereum.org)
Phase 3 (week 4–6): activate on-chain sanctions checks and selector allowlists; deploy monitoring to flag any transaction that touches a non-allowlisted implementation during a proxy hop. (dynamic.xyz)

Emerging best practices (specifics that save you rework)

Make allowlists chain-aware using CAIP‑10; explicitly deny wildcard chains in production. For multi-chain teams, maintain separate lists for “L2-native AA” (RIP‑7560) networks vs. 4337. (chainagnostic.org)
Treat proxies seriously: include both proxy and implementation addresses in allowlists, and revalidate after upgrades; otherwise your policy will block legitimate calls or, worse, allow upgraded logic you didn’t audit. (dynamic.xyz)
Default‑deny module installs unless the module is in an ERC‑7484 registry. Build a small internal registry if your vendor landscape is narrow. (eips.ethereum.org)
Prefer on-chain enforcement for critical invariants (e.g., “never send to non‑allowlisted”) and off-chain for operational gates (e.g., “require 2 of N approvers after 5pm”). Use both. (fireblocks.com)
For typed-data signing, adopt ERC‑7739 defensively in your smart accounts to block cross-account replays while keeping signatures human-readable. (eips.ethereum.org)
If you rely on Defender‑style operational policies, note that OpenZeppelin announced a phased sunset of Defender (new signups disabled June 30, 2025; shutdown July 1, 2026). Plan migrations to open-source relayers/monitors plus on-chain modules. (blog.openzeppelin.com)

Pitfalls we keep seeing (and how to fix them)

“Temporary 7702 delegation” assumptions: the final spec uses persistent delegation. Implement explicit replace/revoke flows and warn users that delegations outlive a single transaction. (eips.ethereum.org)
Session keys without selector scoping: grant only the minimal contract+function set; Alchemy’s permission types and Coinbase spend permissions model are good references for tight scoping. (alchemy.com)
Not simulating internal calls: policies must evaluate the whole call graph; Dynamic evaluates participant addresses across internal calls—mirror that behavior even if you don’t use their stack. (dynamic.xyz)
Ignoring bundler rules: complex validation without staking/reputation may be throttled by ERC‑7562-aware bundlers, breaking UX. Keep validation deterministic and resource-bounded. (docs.erc4337.io)

KPIs your leadership should track

Policy coverage: % of volume executed under on-chain enforced rules (vs. off-chain only)
Blocked risk: $ value and count of transactions blocked by policy (sanctions, ACL, exceed caps), with false-positive rate under 1%
Time‑to‑revocation: P95 time to revoke a session key or 7702 delegation
Module provenance: % of enabled modules present in an ERC‑7484 registry; number of out-of-registry exceptions with risk sign-off (eips.ethereum.org)
Bundler health: inclusion rate for userops and staked-entity reputation incidents (ERC‑7562) (ercs.ethereum.org)

Implementation checklist (copy/paste for your backlog)

Accounts
- Safe with Guard + Module Guard; or ERC‑7579 account with validation hooks (6900). (docs.safe.global)
- 7702 delegation to audited template; UI for replace/revoke. (eips.ethereum.org)
Policies
- Destination and selector allowlists (include proxies+implementations); CAIP‑10/CAIP‑2 IDs. (dynamic.xyz)
- ERC‑20/native caps and velocity windows.
- Pre-signing simulation with internal call graph evaluation; fail-closed. (docs.erc4337.io)
Permissions
- ERC‑7715 wallet_grantPermissions flow; revoke/fetch endpoints; display expiry and limits. (eips.ethereum.org)
- EIP‑5792 capabilities surfaced to apps (batching, sponsorship). (dynamic.xyz)
Compliance
- Sanctions Oracle on-chain + API off-chain; store OFAC hash evidence with approvals. (go.chainalysis.com)
Ops
- Custody policy engine rules: onchain messages vs asset transfers; consensus + YubiKey gating. (help.coinbase.com)
- Defender migration plan if applicable. (blog.openzeppelin.com)

The 90‑day rollout plan

Weeks 1–2: Inventory all spend flows; implement sanctions checks; turn on pre‑sign simulation with internal-call allowlist validation; ship session key revocation UI. (go.chainalysis.com)
Weeks 3–6: Enable Safe Guard/Module Guard or 7579 validation hooks; define ERC‑20 caps; roll out wallet_grantPermissions for top 3 user flows. (docs.safe.global)
Weeks 7–10: Offer 7702 delegation upgrade path; migrate critical modules to be registry-gated; publish your policy spec (selectors, addresses, limits) and run chaos tests (random proxy upgrades, reorg simulations) to validate fail‑closed behavior. (eips.ethereum.org)

Final take

With Pectra’s EIP‑7702, EOAs can finally live under the same governance and policy discipline as smart accounts. Combine on-chain enforcement (guards/modules/registries) with enterprise off-chain engines (consensus, simulation, compliance) and standardize permissions via 5792/7715. Teams that ship these specifics—not just “we have a multisig”—see fewer incidents, faster approvals, and better UX.

If you want a side-by-side gap analysis of your current wallet policies against the controls above, 7Block Labs can deliver a two-week assessment and a ready-to-ship policy spec.