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

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

The Ethereum Pectra upgrade hit the mainnet on May 7, 2025 (epoch 364032), and it brought along EIP‑7702. This cool EIP allows an Externally Owned Account (EOA) to permanently set a “delegation indicator,” letting it run code from a specified smart contract. This opens the door for batching, sponsorship, spending controls, and recovery options--all without needing to shift funds to a new contract account. Basically, EOAs can now be managed like smart accounts. (blog.ethereum.org)
With EIP‑7702, there's a brand-new transaction type: 0x04, called “set code.” This comes with an authorization list that ties together chain ID and nonce, plus it writes a delegation indicator 0xef0100||address into the account’s code. The delegation isn’t just a fleeting thing; it’s persistent, which means you’ll want to think about lasting code paths and the need for revocation procedures. (eips.ethereum.org)
The rules around account abstraction have tightened up a bit. ERC‑7562 lays down some formal off-chain validation rules, including resource limits, state isolation, and staking plus reputation. These are the things bundlers will be keeping an eye on throughout the ERC‑4337/RIP‑7560 pipelines. So if your strategies depend on paymasters, factories, or complex validation, it’s crucial to meet these new constraints--or be ready to stake. (docs.erc4337.io)
We’re seeing some momentum with modular smart-account standards like ERC‑6900 and ERC‑7579, along with registry extensions like ERC‑7484. This growth is making it easier to share policy logic across different wallet providers. In simpler terms, you can now plug in “policy modules” (think hooks, guards, allowlists) instead of having to build everything as one big account. (eips.ethereum.org)

Bottom line: the wallets you roll out in 2025 need to take “policy” seriously as something that’s actually enforceable at the account level, instead of just a box to check off.

Policy engines: two layers you probably need

There are two layers of enforcement that work well together. High-signal programs tap into both of these layers.

On-chain, programmable policy modules

If you’re working with smart accounts (4337/7702/7579/6900), you can set up modules and guards that perform checks before and after transactions (think selectors, destinations, spend limits). Safe is now on board with Module Guards, which means your global rules kick in even while modules are executing transactions. Check it out here: (docs.safe.global)
To make sure you’re only enabling trusted modules, use a module registry (ERC‑7484). This is super important when your approach is “code as configuration.” Dive into the details at (eips.ethereum.org).
It’s best to stick with standards-based validation and hooks (ERC‑6900). This way, you can easily switch vendors without having to rewrite all your policy logic. Get the scoop here: (eips.ethereum.org).

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

Big players in the institutional space like Fireblocks, Coinbase Prime, and BitGo offer some pretty detailed rule engines. They let you set up user roles, consensus thresholds, value/velocity limits, address allowlists, transaction/message policies, and even integrated compliance checks. All of this happens before keys sign off, meaning they can catch and block any non-compliant transactions. Check it out here: (fireblocks.com)

Design Principle

On-chain modules handle cryptographic enforcement when it comes to execution. Meanwhile, off-chain engines manage the signing pathways and offer features like auditability, consensus, and compliance integrations. The goal? Ship both!

Precise controls that work in production

Check out the specific rule surfaces that top teams are using, along with some actionable details you can easily put into practice.

Address allowlists and chain scoping
- It’s a good idea to use CAIP‑10 account IDs and CAIP‑2 chain IDs for scoping your policies across multi-chain setups. For instance, think along the lines of ethereum:1 or base:8453, or you could even go with chain-agnostic patterns. This strategy helps steer clear of those pesky “address on wrong chain” pitfalls and keeps your allowlist nice and auditable. Check it out for more details at (chainagnostic.org).
- When it comes to implementing allowlists, MPC vendors have got you covered with their pre-signing enforcement. BitGo makes things easy by allowing programmatic whitelist updates and puts a lock on them after 48 hours, which helps cut down the risk of social engineering attacks. Don’t forget to include proxy or implementation addresses if you’re calling through upgradeable contracts. You can learn more about that here: (developers.bitgo.com).
Contract/function allowlists (selector ACLs)
- You can set it up to only allow certain contracts and ABI selectors. Dynamic’s policy engine keeps an eye on all participant addresses involved during execution, which includes internal calls. So, it’s super important to list out any proxies and implementation targets; otherwise, you might run into “false negatives” where transactions get blocked. Even if you're simulating off-chain, this is a solid best practice. (dynamic.xyz)
Value and Velocity Limits
- Set specific caps for each asset on a per-transaction basis and implement rolling windows (like daily or monthly limits) for stablecoins and native assets. Custody engines such as BitGo already have velocity rules built in, so it's a good idea to reflect those on-chain for key spending paths to make sure everything is cryptographically enforced. Check it out here: (dashcentral.org)
Risk/sanctions screening when signing
- Consider integrating a sanctions oracle or API like Chainalysis Oracle or the Sanctions API. On-chain oracles allow you to block sanctioned EVM addresses directly in your policy code, while REST APIs give your MPC engines a chance to check things out before signing. Remember to keep hashes of any updates to the OFAC list in your evidence store for audit purposes. (go.chainalysis.com)
Transaction simulation gates
- These need a pre-signing simulation (think call trace) and will throw out any transactions that hit non-allowlisted addresses or go over gas, stack, or memory limits. This aligns perfectly with what ERC‑7562 bundlers expect and helps cut down on griefing. (docs.erc4337.io)
Governance-only flows
- There are different rules for “onchain messages” compared to “asset transfers.” Coinbase Prime actually divides its policy engines for transactions and messages. This means that governance calls in Dao/DeFi can ask for varying consensus, signers, and time frames compared to regular withdrawals. Try to implement a similar setup in your own stack. (help.coinbase.com)
Session-key and spend-permission scopes
- When it comes to consumer experience, it’s a good idea to give out session keys or “spend permissions” that are limited by time, specific selectors, and capped at certain ERC‑20 amounts. Both Alchemy and Coinbase provide detailed permission types and expiration times. Make sure to set up user-friendly revocation interfaces and fetch-permissions RPC endpoints. Check it out here: (alchemy.com)

Smart-account governance patterns you should adopt

Safe Guards + Module Guards
- Implement a Guard to block risky opcodes (like delegatecall) and make sure any actions coming from modules also meet global rules through a Module Guard. This helps seal up a common loophole where modules could skip over guard checks. Check out more about it here: (docs.safe.global)
Modular accounts (ERC‑6900/7579)
- Set up validation hooks for things like selector allowlists, destination ACLs, per-token spend caps, and time windows. Thanks to ERC‑6900's way of separating execution, validation, and hooks, you can keep your policy logic easy to audit and swap out when needed. (eips.ethereum.org)
Module Registries (ERC‑7484)
- Before you start using any module, make sure it’s included in a security-reviewed registry adapter. This helps minimize supply-chain risks. Think of registry gating as a necessary policy rule, not just some advice from DevRel. (eips.ethereum.org)
Signature hygiene (ERC‑7739)
- To prevent cross-account replay of typed data, make sure to use ERC‑7739-compatible readable typed signatures for ERC‑1271 flows. This really matters when a single EOA has 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

With the exciting news that Externally Owned Accounts (EOAs) can now run delegated code, it opens up a ton of new possibilities for developers and users alike. Here’s a breakdown of what you can do next:

1. Create More Dynamic Transactions

Now that EOAs can invoke delegated calls, you can build more complex transaction flows. This means you might want to:

Design smart contracts that can automate certain processes based on user actions or conditions.
Implement batch transactions for users to execute multiple actions in one go, saving them time and gas fees.

2. Enhance Security Features

Security is always a concern, and delegated code can help bolster that. You could:

Set up multi-signature wallets that allow multiple EOAs to approve a transaction before it’s executed.
Develop time-lock contracts where users can delegate their transactions to be executed after a specific time frame, adding an extra layer of security.

3. Build User-Friendly Applications

With the ability to run delegated code, there’s a huge opportunity to enhance user interfaces and experiences. You can consider:

Crafting decentralized applications (dApps) that simplify complex transactions, making them more accessible to everyday users.
Creating interactive tutorials that guide users through the transaction processes, utilizing the new delegated functionality.

4. Experiment with Game Mechanics

If you’re into gaming or gamification, the new capabilities allow for innovative mechanics. Think about:

Developing play-to-earn models where players can delegate actions to automate their earnings.
Introducing in-game economies where players can delegate transactions for trading or crafting without the need for constant manual input.

5. Explore Innovative DAO Structures

Decentralized Autonomous Organizations (DAOs) can leverage this new feature to improve their governance models. You might look into:

Enabling delegated voting where EOAs can delegate their voting power to representatives, making participation easier.
Creating incentive structures that reward users for participating in governance activities through delegated actions.

6. Generate New Revenue Streams

With the expanded capabilities, there’s potential to tap into new business models. For instance, you could:

Offer delegation services that allow users to delegate their transactions to trusted entities for a fee.
Set up subscription models where users can pay for premium delegated transaction services.

Conclusion

The ability for EOAs to run delegated code is a game-changer! Whether you're looking to enhance security, create user-friendly apps, or explore new business models, there’s plenty of room to innovate. So, get started and see where this exciting feature can take you!

Keep a clear “delegation policy” for 7702:
- Make sure to allow delegations only to audited code templates that you have control over. Since the final spec goes with persistent delegation--it's not a temporary thing--think of a setCode authorization like upgrading your wallet, complete with rollback options. Check out the details here: (eips.ethereum.org).
- Make sure your user experience (UX) enforces chain-specific and nonce-bound authorizations (these are already part of the spec). Also, it’s a good idea to have a “Replace/Reset Delegation” one-click option as a safety net. You can find more info about this at (blog.ethereum.org).
Only show spending controls and batching through your audited delegation target, not through random app prompts. The spec is pretty clear on this one--wallets should steer clear of offering a generic “delegate to arbitrary code” UX. So, your policy should be to deny any unknown delegation targets. More on that here: (eips.ethereum.org).
If you’re supporting both 4337 and 7702, make sure to align your modules and guards, and share your policy set. This way, you won’t split your governance model across the different account types. Pectra’s write-up specifically mentions forward-compatibility with “endgame AA.” You can read about it at (blog.ethereum.org).

Session keys and permissions: standardized in 2025

EIP‑5792 introduced wallet_sendCalls along with some cool capabilities for discovering features. This is a smart way to let apps know about batching and gas sponsorship options. If you mix this with session keys and permission settings for interactive apps and agents, you’re all set! Check it out here: (dynamic.xyz).
With ERC‑7715, we now have wallet_grantPermissions, so apps can ask for specific permissions like key types, call limits, gas limits, and ERC‑20 transfer caps. Make this your go-to approach to achieve that “one-click” user experience everyone loves. More details can be found at: (eips.ethereum.org).
Coinbase and Alchemy have laid out some solid permission types, including expiry options, ERC‑20 caps, native spend caps, and contract ACLs. It’s a good idea to design your policy UI to clearly present these scopes and offer easy revoke and renew options. Dive deeper here: (docs.cdp.coinbase.com).
For those building with EOA-backed 7702, it’s best to opt for “wallet-managed sessions” (7715) that still respect your on-chain module rules. If not, your session runner might skip over the guard path, which isn’t ideal. Get more insights here: (eips.ethereum.org).

Compliance-grade screening without killing UX

Check out Chainalysis Oracle for instant blocking of sanctioned addresses right on the blockchain; it pairs perfectly with their Sanctions API off-chain to help you pre-screen beneficiaries and log those SDN evidence hashes (you know, the ones OFAC publishes for audit verifiability). You can find more info here.
If you're looking for even better accuracy, consider integrating commercial risk scoring solutions like TRM, Elliptic, or Scorechain into your off-chain policy engine. You should only escalate to a human when those risk-out-of-band thresholds go off. Don’t forget to log the rule that triggered the alert, the version of the list used, and make sure you have a replayable call trace. Check out additional details here.

Concrete architectures you can ship this quarter

1) Consumer App with Smart Accounts (4337/7702) and One-Click UX

Account: We're using an ERC‑7579 modular account that comes with a cool “Policy Module.” This module keeps things in check by enforcing selector+destination ACLs, daily caps for ERC‑20 tokens, and time windows. Plus, it’s super easy to set up through the ERC‑6900 manifest. Check it out here.
Permissions: For permissions, we’ve got wallet_grantPermissions (ERC‑7715) that lets you use a session key. This key is set up specifically for a particular staking contract, two function selectors, and a $100 USDC daily cap, with a 7-day expiry. You can even revoke these permissions right in the Settings. More details are available here.
Batching: To make your life easier, we advertise capabilities through wallet_getCapabilities (EIP‑5792). This lets you batch swap and stake all in one go. Learn more about it here.
Bundler Safety: When it comes to bundler safety, it’s crucial that your user operations pass ERC‑7562. That means no deep call stacks or shared mutable states unless they’re staked. Keep an eye on your reputation to dodge any throttling issues. You can read up on that here.

2) Enterprise Treasury with MPC Custody + DeFi Access

MPC Policy Engine: You can set specific velocity limits for each desk, create allowlists for address groups per protocol, and implement different rules for on-chain messages (like governance votes) compared to asset transfers (such as withdrawals). Plus, you can enforce consensus with YubiKey gating. Learn more here.
On-Chain Guard: When you're diving into DeFi using a Safe, make sure to deploy a Guard that blocks delegate calls and enforces a maximum slippage limit for swaps, all neatly encoded in the calldata. Don't forget to add a Module Guard, so that any actions initiated by modules can still pass the guard checks. Check out the tutorial!
Compliance: Keep your operations in check by using a sanctions oracle on-chain and an API for off-chain compliance. It's a good idea to store OFAC hash values with each approval artifact to ensure you're covered. Get the details here.

3) Hybrid EOA → Smart Account Migration with 7702

Phase 1 (Week 1): Roll out a “Delegation Check” screen. If there’s no delegation set up, suggest an upgrade to your audited delegation target. This upgrade will let users enjoy batching and spending controls, plus a handy one-tap revoke/replace option. Check out the details here.
Phase 2 (Weeks 2-3): Set up a policy module (ERC-6900/7579) using the same ACLs as your custody engine. Also, enable session keys for trusted apps via 7715. More info can be found here.
Phase 3 (Weeks 4-6): Get on-chain sanctions checks and selector allowlists up and running. Also, implement monitoring to flag any transactions that hit a non-allowlisted implementation during a proxy hop. For more on this, check out Dynamic.

Emerging best practices (specifics that save you rework)

Make those allowlists chain-aware with CAIP‑10, and be sure to avoid wildcard chains in production. If you’re part of a multi-chain team, it’s a good idea to keep separate lists for “L2-native AA” (RIP‑7560) networks and 4337. (chainagnostic.org)
Don’t underestimate the importance of proxies: always include both proxy and implementation addresses in your allowlists, and make sure to revalidate them after upgrades. If you skip this, your policy might block legitimate requests or worse, let in upgraded logic that hasn’t been audited. (dynamic.xyz)
Set a default deny for module installs unless the module is listed in an ERC‑7484 registry. If you're working with a limited number of vendors, consider building a small internal registry. (eips.ethereum.org)
Go for on-chain enforcement for critical things like “never send to non‑allowlisted” and use off-chain for operational gates, such as “require 2 of N approvers after 5pm.” It’s best to use both approaches. (fireblocks.com)
For typed-data signing, it’s wise to adopt ERC‑7739 in your smart accounts to prevent cross-account replays while keeping those signatures easy to read. (eips.ethereum.org)
If you lean on Defender‑style operational policies, take note: OpenZeppelin has announced they’ll be gradually shutting down Defender (no new signups after June 30, 2025; complete shutdown on July 1, 2026). It’s time to start planning your migration to open-source relayers/monitors and on-chain modules. (blog.openzeppelin.com)

Pitfalls we keep seeing (and how to fix them)

Temporary 7702 delegation assumptions: the final specification actually goes for persistent delegation. Make sure to implement clear replace/revoke flows and give users a heads-up that delegations stick around beyond just one transaction. (eips.ethereum.org)
Session keys without selector scoping: only provide the bare minimum of contract and function access. Check out Alchemy’s permission types and Coinbase's spend permissions model--they're great examples of how to keep things tight and secure. (alchemy.com)
Not simulating internal calls: make sure your policies take the entire call graph into account. Dynamic runs evaluations on participant addresses throughout internal calls--try to replicate that behavior even if you're not relying on their stack. (dynamic.xyz)
Ignoring bundler rules: if you're trying to do complex validation without using staking or a reputation system, you might run into issues with ERC‑7562-aware bundlers, which could mess with the user experience. Keep your validation consistent and make sure it doesn't overextend resource limits. (docs.erc4337.io)

KPIs your leadership should track

Policy coverage: This measures the percentage of transactions that follow rules enforced on-chain compared to those that rely solely on off-chain methods.
Blocked risk: Here, we look at the dollar amount and the number of transactions that got blocked by policies--like sanctions, access control lists (ACL), and going over caps--while keeping the false-positive rate below 1%.
Time-to-revocation: We’re tracking the 95th percentile of how long it takes to revoke a session key or a 7702 delegation.
Module provenance: This indicates the percentage of enabled modules that show up in the ERC-7484 registry, along with the count of exceptions that aren't in the registry but have gone through risk sign-off (eips.ethereum.org).
Bundler health: We’re measuring the inclusion rate for user operations and incidents involving staked-entity reputations as per ERC-7562 (ercs.ethereum.org).

Implementation checklist (copy/paste for your backlog)

Accounts
- Use Safe with Guard + Module Guard, or go for an ERC‑7579 account that has validation hooks (6900). Check it out here.
- Set up 7702 delegation to an audited template; make sure you have a UI ready for replacing or revoking. More info can be found here.
Policies
- Create destination and selector allowlists (don’t forget to include proxies and implementations); also, keep track of CAIP‑10/CAIP‑2 IDs. You can find details here.
- Implement ERC‑20/native caps and velocity windows.
- Run pre-signing simulations with internal call graph evaluation; ensure it fails safely. Check the requirements here.
Permissions
- Set up the ERC‑7715 wallet_grantPermissions flow; don’t forget the revoke/fetch endpoints, plus display expiry and limits. More info is available here.
- Make sure EIP‑5792 capabilities are visible to apps (like batching and sponsorship). You can get more details here.
Compliance
- Implement an on-chain Sanctions Oracle along with an off-chain API; remember to store OFAC hash evidence with approvals. Check it out here.
Ops
- Establish rules for the custody policy engine: differentiate between on-chain messages and asset transfers, plus set up consensus and YubiKey gating. More information can be found here.
- Plan for Defender migration if it’s needed. You can read more about it here.

The 90‑day rollout plan

Weeks 1-2: Start by taking stock of all your spending flows. Don't forget to implement sanctions checks, and get that pre-sign simulation up and running with internal-call allowlist validation. Also, roll out the UI for session key revocation. (go.chainalysis.com)
Weeks 3-6: Next up, enable Safe Guard/Module Guard or add those 7579 validation hooks. Set the ERC-20 caps and roll out wallet_grantPermissions for your top three user flows. (docs.safe.global)
Weeks 7-10: After that, give folks the option to upgrade via the 7702 delegation path. Migrate any critical modules to be registry-gated. Finally, publish your policy spec (that includes your selectors, addresses, and limits) and run some chaos tests--think random proxy upgrades and reorg simulations--to ensure everything's working as it should in fail-closed scenarios. (eips.ethereum.org)

Final take

With Pectra’s EIP‑7702, regular EOAs can finally play by the same rules as smart accounts when it comes to governance and policy. By blending on-chain enforcement (think guards, modules, and registries) with enterprise off-chain solutions (like consensus, simulation, and compliance), we can create standardized permissions through 5792/7715. Teams that nail down these specifics--not just saying “we have a multisig”--tend to experience fewer incidents, quicker approvals, and an overall better user experience.

If you're looking to compare your current wallet policies with the controls we just talked about, 7Block Labs has got you covered! They can whip up a detailed assessment in just two weeks and provide you with a ready-to-go policy spec.