Anti-Fraud for Smart Accounts: Detecting Bot Signatures in Delegated Calls

Exciting news, everyone! Smart accounts have officially moved out of pilot mode and are now live in production! We’re rolling out EntryPoint v0. Version 8 is officially up and running on all the main stacks! We're noticing some cool developments with ERC‑7579 modular accounts. Plus, thanks to EIP‑7702, externally owned accounts (EOAs) can now "borrow" features from smart wallets. It's exciting to see how this will change the game! This is definitely exciting and really boosts what we can do! But, it also brings up some tricky issues, especially when it comes to delegated execution and managing signatures. In this post, we’re giving decision-makers a handy playbook that will help them spot bot activity and misuse of signatures in delegated calls before it turns into a bigger issue.

Summary

Check out this quick guide to help you spot bot signatures in delegated calls, especially when it comes to smart accounts like ERC-4337, ERC-7579, and EIP-7702. It’s super useful! We’ve put together some easy-to-follow checks, shared a few sample detectors, and pointed out some new best practices that your engineering team can dive into this quarter. If you want to dig deeper into this topic, be sure to swing by the full article on etherspot.io. You'll find all the juicy details there!

---

The 2025 context: why delegated-call fraud spiked

• EntryPoint v0. 8 has really upped the validation game and introduced some cool features that the leading bundlers are now utilizing. Many teams are currently busy upgrading their systems, and this has created a bit of a disconnect between wallets, paymasters, and bundlers. It’s like everyone’s on a different page right now! This really sets the stage for smart bots to flourish. (etherspot.io).

Hey everyone! Just wanted to share some exciting news--the ERC-4337 Shared Mempool is now live on Ethereum, Arbitrum, and Optimism. How cool is that? So, here's the deal: while the broad spread of UserOps definitely strengthens resilience, it also opens the door for bots to dive into all kinds of annoying spam, like signature-stuffed junk and mempool snooping. The kicker? They can pull this off without breaking the bank. (docs.erc4337.io).

Hey, guess what? With EIP-7702, EOAs can now easily delegate code for a bit! This means you can batch actions with just one click and even sponsor them. How cool is that? But on the flip side, there's a new "authorization list" that we really need to keep an eye on. It’s important to check this list thoroughly to stop any sneaky moves from bad actors trying to pull a fast one. (eips.ethereum.org).

Alright, here’s the scoop: we’ve noticed that delegated execution pathways--think plugins, modules, or those temporary EOA delegations--are where a lot of signature misuse and bot activities are happening. It's definitely a hotspot for shady stuff!

---

Quick glossary (decision‑maker edition)

• Smart Account (ERC-4337): So, basically, this is a type of contract account. It takes a look at a UserOperation (or UserOp for short) and then makes things happen based on what you want through something called EntryPoint. When it comes to signatures, they can really differ because each wallet has its own setup. You might come across signature bytes in a few different forms, like ECDSA, EIP‑1271 contract signatures, aggregates, or even wrappers. Take a look at this: (ercs.ethereum.org). It's worth checking out!
• Delegated Call (like we talked about earlier): Basically, this is when an account passes the reins to some outside code. This could include a bunch of different things, like Safe modules, ERC-7579 plugins, executors, validators, or even EIP-7702 delegated code. Some of these methods go with CALL, but you might find that older systems still prefer DELEGATECALL. If you want to dive deeper into it, check this out: (ercs.ethereum.org).
• Contract Signatures (EIP‑1271): With this feature, contracts can actually "sign" stuff using the isValidSignature function. Pretty neat, right? So, for accounts that are still in the hypothetical stage or haven’t been launched yet, ERC-6492 steps in to lend a hand. It essentially wraps the signature together with the necessary deploy/prepare info. If you’re looking for more info, just check this out: eips.ethereum.org. It’s got all the details you need!

---

Where bot “signatures” actually show up

So, you know, bots usually aren’t out there breaking encryption or anything fancy like that. What they really do is find ways to exploit our verification systems instead. In AA stacks, we tend to notice signature misuse popping up in four main areas:

1. UserOperation.signature
   Sure! So, when we talk about this, we're looking at things like EOA ECDSA, contract signatures (you know, EIP‑1271), aggregated signatures, or even those ERC‑6492 wrappers for accounts that aren't live just yet. Pretty neat, right?
   You’ll frequently come across weak parsers and those “blind pass” verifiers just hanging out. (ercs.ethereum.org).

2. Delegated Modules/Plugins

So, safe modules like execTransactionFromModule are designed to intentionally bypass those wallet-level signature checks. Basically, if a bot can tap into a permissive module, the standard safety features for the main account won't really come into play. So, when it comes to modular ERC-7579 accounts, we're really starting to favor validated CALLs over DELEGATECALLs. But hey, just to keep it real, mixed estates are still around and very much a part of the conversation! If you're curious to learn more, just hop on over to this link. You'll find all the info you need!

3. EIP‑7702 authorization_list

Alright, let’s break it down! When you’re dealing with temporary delegation for those externally owned accounts (EOAs), it really revolves around these key tuples: [chain_id, address, nonce, y_parity, r, s]. That’s the core of it! If you don’t get the binding right on these or make sure that the delegations follow the audited code, you could really be setting yourself up for some major bypass issues. (eips.ethereum.org).

1. Paymaster-sponsored flows
   Signature packing bugs and unreliable validation processes can really put paymasters at risk for things like replay attacks or other kinds of misuse. It's super important to stay on top of the ERC-7562 validation scope and check out the reputation of various entities. This way, you can avoid the risk of unintentionally funding bots. (alchemy.com).

---

Detector 1 -- Identify ERC‑6492 (counterfactual) signatures and pin the factory

Here are a few things to keep in mind: So, ERC-6492 signatures come wrapped up with a little something extra. They have this 32-byte magic suffix that wraps things up with "0x" at the end. Cool, right? 6492. Hackers often catch verifiers off guard by jumbling deploy-time data or bringing in some unexpected factories. It’s pretty sneaky how they exploit these situations! (eips.ethereum.org).

How to Detect:

First, take a look at UserOp.signature and see if it ends with the 6492 suffix. If it does, go ahead and unwrap it and validate it like this:

1. To kick things off, go ahead and try deploying with that factoryCalldata we gave you. You can think of it like making an eth_call. 2. Now, go ahead and call isValidSignature on the target. 3. If it's already up and running, just remember to call isValidSignature to make sure everything stays as it should.

Make sure to add the factory address to a trusted allowlist for every chain you’re working with. It’s an important step you don’t want to overlook! If you want to dive deeper, take a look at the EIP-6492 documentation. It’s got all the info you need!

Implementation Sketch (TypeScript):

Let me give you a quick rundown on how you can get this going in TypeScript!

interface User {
    id: number;
    name: string;
    email: string;
}

class UserManager {
    private users: User[] = [];

    addUser(user: User): void {
        this.users.push(user);
    }

    getUser(id: number): User | undefined {
        return this.users.find(user => user.id === id);
    }

    listUsers(): User[] {
        return this.users;
    }
}

// Example usage:
const userManager = new UserManager();
userManager.addUser({ id: 1, name: 'John Doe', email: 'john.doe@example.com' });
const user = userManager.getUser(1);
console.log(user);

In this section, we’re going to whip up a straightforward user management system. So, we’ve got this User interface that basically outlines what our user objects should look like. Then, we’ve created a UserManager class to take care of all the heavy lifting--like adding new users, fetching their details, and listing everyone out. Pretty neat, right? Here's a cool little trick to help you stay organized!

function isERC6492(sig: Uint8Array) {
  const suffix = "0x6492649264926492649264926492649264926492649264926492649264926492";
  return bytesToHex(sig.slice(-32)) === suffix.toLowerCase();
}

Policy Tips

Make sure to keep a list of “trusted CREATE2 factories.” It's important to either ignore or dig a little deeper into those 6492 signatures that are coming from unknown factories. Here's the deal: if you come across any unwrapped signatures, they should definitely match up with the ERC-1271 magic value, which is 0x1626ba7e. Just keep that in mind! Oh, and let's make sure we don't let ecrecover fallbacks happen for contract accounts, okay? For more details, you can take a look here.

---

Detector 2 -- Validate EIP‑7702 authorization tuples and verify delegated code

What to look for:

• EOA transactions can use an authorization_list to reference any code you want. At first, these might look pretty innocent, but they have the potential to reroute execution to a sketchy delegate contract. (eips.ethereum.org).

How to Detect (Pre-Inclusion or Backend):

Alright, let’s dive in! Here’s a quick guide on how to spot things efficiently:

• Authorization Check: Take a look at each authorization tuple and double-check a few key things:
• The chain_id matches up with the current chain, or it could just be 0 as per the specs. Make sure to keep tabs on the nonce so that it's always increasing for each authority. Also, double-check that the y_parity/r/s align with the tuple hash by using keccak(0x05 || rlp([chain_id, address, nonce])). It’s a good practice to stay on top of these details to keep everything running smoothly! If you're curious to dive deeper into this topic, check out EIP-7702. It's got all the details you might need! So, when you're dealing with the address, it should either link to a code hash on a trusted list (kind of like checking out a reliable source, similar to the Simple7702Account reference or some verified wallet code) or it should be on a denylist. The denylist is basically where you’ll find all those delegates you definitely want to steer clear of. With EntryPoint v0. So, there's actually a Simple7702Account you can check out. It's a straightforward option that's been audited, making it a safer choice for delegating your tasks. If you want to dive deeper, head over to Etherspot's blog for all the juicy details!
• Mempool Throttle: Just a heads-up--be sure to only take on one pending transaction for each externally owned account (EOA) that has active delegation. This is super important because clients often end up canceling a bunch of transactions right after they give the go-ahead. Just a little heads-up to keep in mind so you don't run into any problems down the line! If you're curious to learn more about this, check out EIP-7702. There's a lot of great info there!

Signal Examples of “botty” 7702 Use

• Chain ID = 0: Honestly, there's not much of a reason to use this one. It's just pointing to some unclear bytecode that isn't on your allowlist.
• Reused Authorization Nonces: If you see these popping up during those quick, bursty transactions, it’s a pretty strong indicator that something spammy is going on.

---

Detector 3 -- Distinguish passkey (P‑256) signatures from secp256k1 bots

Why it matters:

Lately, we're seeing a growing trend with consumer wallets adopting passkeys like WebAuthn and P‑256. It's pretty cool to witness how technology is evolving, right? In the meantime, bots generally stick to the k1 pipelines. So, with the mainnet moving to that P‑256 precompile (you can read more about it in EIP‑7951), you can now verify the curve type pretty easily and without breaking the bank, whether you're doing it on-chain or just testing things out in a simulation.

How to Detect:

When you're working on those contract-signature paths, just make sure to include a “signature type” byte. And remember, let's stick with P-256 instead of k1 when it’s appropriate. For any off-chain stuff, just send those ES256 payloads over to the P-256 precompile verifier.

• Watch for any inconsistencies: if a client says they’re using passkey authentication but then gives you those k1-style 65-byte signatures, that’s a red flag. Also, keep an eye out for those odd DER-to-raw conversions you often see in bot kits.

Why This Helps Fraud:

So, for those session policies that need to be linked to a specific device--like those high-risk payouts--you usually have to go with P-256. Most bot farms usually don’t bother with the hassle of mimicking FIDO attestation chains. (eips.ethereum.org).

---

Detector 4 -- Catch DELEGATECALL in module paths; prefer ERC‑6900/7579 “CALL”

Background

So, DELEGATECALL lets one contract execute the code of another contract, but it does so while keeping everything tied to the storage of the calling contract. It's like borrowing someone else's recipe but cooking it in your own kitchen! So, here's the deal: if there's a glitch, a module could actually take over your account! On the bright side, we've got ERC‑6900 and ERC‑7579 guiding us towards a cooler, more CALL-based way to handle modularity. It's definitely a step in a better direction! Just a heads up, even with Safe, there are still ways for modules to get around those owner signature checks. So keep that in mind! That definitely puts it right in the crosshairs for those sneaky delegated-call bots! (knauss.dev).

How to Detect:

• Check out the simulated UserOp (or raw tx): If you spot any frame under account execution that’s doing a DELEGATECALL to an implementation that isn’t pinned, it’s a good idea to isolate it for safety. You know what they say, better to be safe than sorry!
• For Safety: Make sure to watch out for `execTransactionFromModule(.” So, when you're dealing with that operation, it wraps up as a 1 (and yep, that's what we call DELEGATECALL). Keep an eye out for any modules that aren't listed in your approved registry. This is key because this route intentionally bypasses the owner signature verification. If you want to dive deeper into this topic, just click here for all the details!
• For ERC‑7579: Just a heads up, you’ll want to double-check that the validators and executors are genuine installed modules. A quick way to do this is by running some ERC‑165 checks. Also, be sure that the account is following the CALL semantics as outlined in the reference. Take a look at the details here. You’ll find all the info you need!

---

Detector 5 -- Nonce‑lane anomalies (4337, 7579, 7582, 7712)

Why it matters:

Smart accounts make use of multi-dimensional nonces. EIP-4337 brings together a 192-bit key and a 64-bit sequence, which is pretty cool. On the flip side, a lot of plugins usually pack validator IDs into the upper bits. RIP-7712 really builds on this idea by expanding the concept. This opens the door for bots to exploit teams that accidentally depend on just one sequential nonce. (eip.info).

How to Detect:

First off, check out the higher bits of the nonce. You'll want to line those up with the validator or module lanes that work best for your setup. If the nonce key for a UserOp doesn’t match any of the validators you’ve got set up, just go ahead and ignore it.

• Make sure to look out for any sequences that seem out of whack for the same key. Just a heads up--be careful if you notice the same key popping up over and over with different validators that don't really play nice together. This kind of thing usually comes from those annoying copy-paste botkits. Take a look at this: (ercs.ethereum.org). It’s worth checking out!

---

Detector 6 -- Paymaster signature misuse and entity reputation (ERC‑7562)

Here's a quick rundown of what to keep an eye on: So, we've got UserOps that manage to get a paymaster's signature off the chain for one specific purpose. But then, they flip the script and change the initCode or callData before it actually gets included. These are those classic "signature packing" bugs. Watch out for those griefing patterns that pop up when people exploit shared storage in validation frames. Just keep an eye on that! If you want to dive deeper into it, check out alchemy.com for more details!

How to Detect:

Hey, just a quick reminder to keep an eye on the ERC-7562 validation scope rules while you're running simulations. It’s important! So basically, you’ll want to keep an eye on a few key things: making sure the code and storage are stable, verifying that staked entities can only access their own storage, and monitoring those gas limits. Also, it’s super important to keep your reputation intact, especially when it comes to paymasters, factories, and aggregators. A solid standing with them can really make a difference! If any groups start invalidating way too many operations, it's definitely time to kick them out. If you want to dive deeper into this, check it out here.

Hey, just a quick reminder: make sure to get the off-chain signers to hash the fully packed UserOp. It's an important step! Running negative tests on issues we've already identified with packing is definitely a smart move to ensure everything stays safe. If you want to dive deeper into this topic, you can check out more details here. It's a great read!

---

Bot signature heuristics specific to delegated calls

Here are some useful signals we use during our triaging process that usually have low false-positive rates:

• ERC‑6492 + an unknown factory: We’re working with a special suffix here, but the factory isn’t on the chain allowlist. Plus, the code hash we generated doesn’t match up with the account bytecode we were expecting. This one definitely gives off the vibe of a scripted farming operation or maybe even a phishing scam. If you want to dive deeper into the details, just click here. It's all laid out for you!
• 7702 burst with an opaque delegate: We’ve spotted a bunch of transactions coming from the same EOA in less than 2 blocks. They’re all approving a delegate address that isn’t on the allowlist. Also, I noticed that the authorization chain_id is just set to 0, and there's no clear explanation for why that’s the case. If you're looking for more details, just check this link here. You'll find plenty of info!
• Safe module delegatecall: So, there's this call happening with execTransactionFromModule, and it's using operation=DELEGATECALL. The thing is, it's linked to a module that we don't really know much about. It seems like a new module was just added and someone jumped in to use it for spending right away. If you're looking for all the details, check it out here. You won't want to miss it!
• Watch out for shady selector bundles: We've noticed some batches that look a lot like MultiSend. They’re mixing in the 0x095ea7b3 (approve) selector with DEX swap selectors, but here's the kicker -- there haven’t been any token approvals on those accounts beforehand. What’s interesting is this pattern is showing up with a lot of different senders. So, it's definitely something to keep an eye on! These are pretty classic indicators of scripted arbitrage or drainer tactics at play. Be careful with these--they really need some extra attention.
• Reverted Swap Storms on L2: We've seen a pretty significant uptick in those clusters of reverted swaps happening at the top of blocks since the fee cuts from the Dencun era. It's definitely something to keep an eye on! You usually see this kind of thing when bot swarms are out there trying to grab MEV by flooding the network with requests. It could be worth considering setting these aside for now or maybe giving them a lower score. What do you think? If you're curious and want to dive deeper, you can check it out here. Happy reading!

---

Example: minimal ERC‑6492 + 1271 verification flow (pseudocode)

function verifyContractSig(address signer, bytes32 digest, bytes sig) returns (bool) {
  if (has6492Suffix(sig)) {
    (addr factory, bytes fcdata, bytes inner) = decode6492(sig);
    // 1) simulate deployment if needed
    if (signer.code.length == 0) {
      bool ok = simulate(factory, fcdata); // eth_call; no state changes
      if (!ok) return false;
    }
    // 2) check live contract 1271
    return IERC1271(signer).isValidSignature(digest, inner) == 0x1626ba7e;
  } else {
    // fall through to 1271 or EOA flow
    if (signer.code.length > 0) {
      return IERC1271(signer).isValidSignature(digest, sig) == 0x1626ba7e;
    }
    // EOA: ecrecover check with low‑s enforcement
    return ecrecover(digest, sig) == signer;
  }
}

Key Points:

Hey, just a quick tip: whenever you have access to the code, definitely opt for live 1271 verification. It’s the way to go, even if the signature is all wrapped up. Trust me on this one!

• If you come across any contract address that you're familiar with, steer clear of accepting EOA. If you want to dive deeper into this topic, just click here for more details!

---

Example: Safe module hardening policy

• Make sure to maintain a list on the blockchain of all the approved modules and what they’re capable of doing, which is mainly just CALL. Only use DELEGATECALL when you really need it, and make sure it’s been thoroughly audited before doing so. It’s best to play it safe!
• Go ahead and shoot out an alert whenever we add a new module that's up and running in the next N blocks. Hey, for those roles and delay modules, let's try setting a minimum cooling-off period--maybe around 3 minutes--for those larger transfers. This little cancellation window can really help us avoid a bunch of those annoying scripted drain attacks. It’s a simple tweak that could make a big difference! (pkqs90.github.io).

---

Example: 7702 authorization verification checklist

Before accepting or relaying a 7702 transaction:

• Take a moment to review the definitions: Just ensure you really understand what 7702 is all about and what it entails. The IRS has some pretty clear guidelines, so it’s really important for us to stay aligned and in sync.
• Check out what the client needs: Take a moment to consider the client’s financial goals and see how a 7702 transaction can play a role in their overall strategy. Is this a good fit?
• Check for compliance: Make sure everything lines up with IRS rules and regulations. You really don’t want to run into any problems later on.
• Think about what it means: Take a moment to wrap your head around the tax perks you might get from this deal, but also keep an eye out for any potential downsides that could pop up. Staying in the know is definitely a smart move!
• Don't skip the paperwork: It's super important to get all your forms filled out correctly. Double-checking can save you a lot of headaches later on! For a hassle-free transaction, having solid documentation is key.
• Don’t be afraid to ask for help: If you’re feeling a bit lost or confused about something, just reach out to a financial advisor or tax expert. They’re there to help you out! Hey, you know what they say: better safe than sorry!

If you follow these steps, you'll make sure your 7702 transactions run like a well-oiled machine!

• Go ahead and verify the signature of each authorization tuple to ensure it's legit according to the authority (EOA).
• Just double-check that the chain_id is in sync with the current_chain (or set to 0 if your policy allows you to move across chains). Also, make sure that the nonce isn’t old news! Check out the code hash for the delegated address and see if it lines up with anything on your allowlist, like Simple7702Account.
• Make sure to follow your local policy: only allow delegations for the audited “batch + sponsor” code, and don’t accept any “free-form” delegates. (eips.ethereum.org).

---

Observability: what to log to catch bots early

You’ll receive complete trace summaries for UserOps/tx that break down everything for you. This includes cool details like the individual frame operations (think CALL/DELEGATECALL), along with info about the target, selector, and value. Hey there! Just wanted to let you know that we've got a distinct taxonomy for every operation we handle. It includes these key elements: {k1-EOA, 1271, 6492-wrapped, BLS, ES256}.

• We've got the nonce key and sequence decoding in the mix, plus the validator ID too. You'll get to check out all the players involved in the validation process. This includes the factory, paymaster, aggregator, and you’ll also see the current status of the ERC-7562 reputation. Hey, just a quick reminder to keep an eye on inclusion latency and to compare those simulated gas deltas with what’s happening in the real world on-chain. You’ll often see those spikes pop up right before the bot waves hit! Take a look for more info here: (docs.erc4337.io).

---

Engineering playbook: five concrete controls to ship this quarter

1. Hey there! Just a quick heads-up: be sure to upgrade to EntryPoint v0. You won't want to miss out on the latest features! You’ll need to get version 8 up and running with a bundler that can manage the official test suite. Hey, just a quick reminder! Make sure to turn on Shared Mempool and enforce ERC‑7562. Trust me, doing this will help you deal with a ton of griefing and invalidation spam. It makes a real difference! Take a look at this: bundlers.erc4337.io. You might find it really interesting!

2. Alright, so next on the agenda is to implement some signature verification that's aware of the 6492 standard. We’re going to include factory allowlisting for all 1271 flows. This will cover everything from authentication and login to off-chain signatures. Let’s make sure everything runs smoothly! If you’re looking for all the info, you can check it out here: eips.ethereum.org.

3. Looks like it’s time to dive into delegated execution! To keep things secure, make sure to configure the registry-gate modules and, by default, block DELEGATECALL. If you're working with ERC‑7579 accounts, make sure to check the modules using ERC‑165. It's important to stick to CALL semantics and verify where the validator or executor is coming from. If you're looking for more details, check this out: (ercs.ethereum.org). It's a great resource!

4. Hey, just a quick reminder to double-check those 7702 authorizations and link your pin delegates to the audited code (or Simple7702Account). It’s a good idea to do this until your team has a reliable policy engine set up. Check it out here for all the details: (etherspot.io). You won’t want to miss this!

5. And hey, just a quick reminder: make sure to set up nonce-lane parsing and policy properly. If a UserOp's nonce key doesn't line up with an installed validator lane, let's reject it. Oh, and don’t forget to display those nonce lanes on the ops dashboards. It’ll help keep everything nice and organized! For more details, feel free to take a look right here: (eip.info).

---

Emerging best practices (late‑2025)

• It's a good idea to stick with CALL-based plugin systems like ERC-6900 or ERC-7579 rather than using those makeshift DELEGATECALL setups. Trust me, you'll thank yourself later! If you find yourself needing to use delegatecall, just ensure you lock down those storage layouts and treat them with the same care as you would your main wallet. A thorough audit is a must! Check it out here.

Think of passkeys like your ultimate security blanket. If you're handling anything risky, like big payouts or moving assets around, definitely make ES256 your go-to. And don’t forget to double-check it with the P-256 precompile (EIP-7951) for that extra layer of protection! If you want to dive deeper into the details, you can check it out here.

Make sure to keep that ERC-7562 enforcement super tight at the entry point, like when your relayer or bundler is kicking things off, and just before you actually hit the button to submit the bundle. Keeping a shared reputation map for your factories, paymasters, and aggregators is definitely a smart move. It helps everyone stay in the loop and makes sure that you’re all on the same page when it comes to how things are going. Check it out here.

So, when you're dealing with paymasters, just remember to sign the whole packed UserOp. After that, go ahead and re-encode it on your end to avoid any pesky packing problems. Make sure to keep an eye on users whose sponsored operations start to stray from what we simulated. It’s important to throttle them when that happens. If you want to dive deeper into this topic, check it out here. You'll find some great info!

---

Red flags your SOC should alert on

Hey! So, I noticed that the UserOp.signature wraps up with 0x…6492. The thing is, the factory you're trying to use just isn’t recognized on this chain. If you want to dive deeper into the details, just head over here. Hey there! Just a quick tip for working with Safe's execTransactionFromModule: make sure to use delegatecall for that new module right in the same block when you’re installing it. It’ll save you some hassle down the line! If you're looking for more details, you can check it out here! Hey, just a heads up--there’s a problem with the EIP-7702 authorization list. It looks like you're dealing with some bytecode that either isn't on your allowlist or has a code hash that's changing (we call that a proxy-flip). If you want to dive deeper into that topic, you can check it out here.

• Make sure to watch out for those quick failed swaps happening on Layer 2. They're popping up pretty fast! It could be connected to accounts that are engaging with your contracts, aiming to tackle any bot issues before they escalate. If you're curious about the details, you can take a look here!

---

Brief, in‑depth details for architects

Alright, so when it comes to ERC‑4337, the nonce is split into two parts: you've got a key that’s 192 bits, and then there’s a 64-bit sequence. So, here's a cool thing about smart designs: they actually include the validator or module ID in the key. Plus, they use the sequence like a counting system for each validator, which makes it all pretty neat! This smart mapping really helps to dodge all those frustrating “replay across lanes” moves. If you want to dive deeper into the details, check it out here.

So, here’s the deal with ERC-6492: the order in which you verify things really matters. First things first, you'll definitely want to take a look at those magic bytes. After that, give the deploy path a shot using a side-effect-free eth_call. And hey, if there’s code out there, don't forget to run those live 1271 checks! It’s always a good idea to stay on top of things. This approach really helps to avoid accepting EOA-style signatures for contract signers. Hey! If you want to dive into the specifics, just head over here. You’ll find all the info you need!

• EntryPoint v0. Version 8 is bringing some really useful updates, like adjustments to gas penalties that should make things smoother for everyone. Plus, it’s also rolling out the new Simple7702Account feature. Hey, if you tweak your code to match up with v0, that'd be great! By diving into those 7702 authorizations, you’ll really help reduce those pesky “unknown behavior” issues that can pop up. If you're looking for more details, you can check it out here.

ERC-7562 is really focused on making sure that validation-stage isolation and reputation are formalized. So, there’s no need for you to stress about coming up with something totally original here! Your bundler really needs to prioritize tracing validation. It's super important to ensure that both your storage and code stay immutable. Plus, any entities that cause a lot of issues should be removed from the mix. If you're interested in exploring this topic further, check it out here! You'll find some really useful info that dives into the details.

---

Implementation checklist (copy/paste to your issue tracker)

• Signature layer Sure thing! How about we add some ERC‑6492 parsing into the mix? We should also create a factory allowlist for each network. Oh, and don’t forget to check for that 1271 magic value while we’re at it! (eips.ethereum.org). Hey, let’s not forget to toss in some of those signature taxonomy labels into our logs. You know, like {EOA‑k1, 1271, 6492, P‑256, aggregated}. It’ll help keep everything organized! (eips.ethereum.org).
• Delegated code Alright, so for the Safe, let’s go ahead and set up a module registry. We also need to create a DELEGATECALL blocklist. Oh, and it’d be super helpful to get an alert whenever a new module pops up, especially right before we go ahead and spend. Sound good? (pkqs90.github.io). Alright, so with ERC‑7579, we really need to make sure we’re doing those ERC‑165 checks for validators and executors. We’re going to keep it simple with a CALL-only approach. (ercs.ethereum.org).
• 7702 Hey, just a quick reminder: make sure to double-check those authorization list tuples. It’s also a good idea to set up a delegate allowlist and keep an eye on things to ensure there’s only one pending transaction for each delegated EOA. (eips.ethereum.org).
• Bundler/paymaster
• Hey team, let's make sure we're on top of enforcing ERC-7562. We should also keep an eye on how entities are doing in terms of reputation. Plus, don’t forget about those bundler conformance tests (v0) that we need to integrate! 8). (ercs.ethereum.org). Hey, just a quick reminder! Before we wrap up those paymaster approvals, make sure to re-encode and hash all the packed UserOps. Thanks! (alchemy.com).
• Observability Alright, here’s the plan: we’ll keep a record of the CALL and DELEGATECALL traces for each UserOp we run. Plus, we’ll make sure to trigger some alerts whenever there’s a DELEGATECALL to anything that isn’t pinned code. Sound good?
• Let's get some nonce lane dashboards going to keep an eye on the key-to-validator mapping, spot any gaps, and catch any out-of-order problems. It'll really help us stay on top of things! (eip.info).

---

Final thought

The real magic of account abstraction comes from its programmability, so let’s be smart about how we use it! To make sure everything's secure, double-check those 6492 wrappers, get those 7702 delegates sorted out, focus on using CALL-based modules, stick to the ERC-7562 standard, and don't forget to log that nonce-lane intent. This way, you'll be able to spot those sneaky bot signatures hiding out in delegated calls.

If you need a quick rundown on your delegated-execution paths or could use a bit of help with transitioning to EntryPoint v0, just let me know! I'm here to help you out. With the enforcement of ERC-7562 in place, 7Block Labs is here to support you every step of the way! We’ve got playbooks and reference code ready to go! Your engineers can have everything up and running in just a few weeks--much faster than the usual wait times.

---

References (selected)

Hey, make sure to take a look at the ERC‑4337 core spec and docs! They’ve got all the juicy details about UserOp structure, bundlers, EntryPoint, and how to keep an eye on everything. It's definitely worth your time! (ercs.ethereum.org). Hey there! So, let’s dive into what EntryPoint v0 is all about. Here’s a quick summary of 8 updates and the Simple7702Account from Etherspot that you’ll find super helpful! (etherspot.io). Let’s take a look at the ERC-7562 validation scope rules! We'll cover everything from how entity reputation works to the ins and outs of storage and code limitations. (ercs.ethereum.org).

• Check out EIP-7702! It dives into some cool stuff about EOA delegation and the whole authorization list thing. (eips.ethereum.org).
• Here’s the lowdown on ERC‑6492 and how it handles pre-deploy contract signatures and the order in which they get verified. (eips.ethereum.org). Hey, if you’re curious about minimal modular accounts, definitely take a look at ERC‑7579! It covers some really interesting stuff like modules, validators, and executors. Happy reading! (ercs.ethereum.org). Make sure you get how the Safe module execution works. This includes diving into things like execTransactionFromModule and the whole signature bypass concept. It’s important to wrap your head around these details! (pkqs90.github.io). Check out how Passkeys and the P‑256 precompile (EIP‑7951) can provide some seriously solid device-bound signatures! (eips.ethereum.org).
• Take a closer look at MEV spam patterns on fast-finality chains. These patterns can really hint at when bot storms are happening, especially around reverted swaps. (arxiv.org).

A practical, current-state guide to detecting bot signatures in delegated calls for smart accounts (ERC‑4337, ERC‑7579, EIP‑7702), with detector patterns, sample policies, and upgrade advice you can implement this quarter.