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

Smart accounts have moved from pilot to production: EntryPoint v0.8 is live across major stacks, ERC‑7579 modular accounts are maturing, and EIP‑7702 lets EOAs “borrow” smart wallet code. That power also expands the attack surface—especially around delegated execution and signature handling. This post gives decision‑makers a concrete playbook to detect bot activity and signature abuse in delegated calls before it becomes loss.

Summary (meta): A practical, current-state guide to detecting bot signatures in delegated calls for smart accounts (ERC‑4337, ERC‑7579, EIP‑7702), with precise checks, sample detectors, and emerging best practices your engineering team can implement this quarter. (etherspot.io)

---

The 2025 context: why delegated-call fraud spiked

• EntryPoint v0.8 tightened validation and added features adopted by leading bundlers; many teams are mid‑upgrade, which creates mismatched assumptions between wallets, paymasters, and bundlers—fertile ground for clever bots. (etherspot.io)
• The ERC‑4337 Shared Mempool is now running on Ethereum, Arbitrum, and Optimism. Wide UserOp propagation is great for resiliency, but also makes signature‑stuffed spam and mempool probing by bots cheaper. (docs.erc4337.io)
• EOAs can temporarily delegate code via EIP‑7702, enabling one‑click batching and sponsorship—but also introducing a new “authorization list” that must be verified carefully to stop malicious delegations. (eips.ethereum.org)

The net result: delegated execution pathways (plugins, modules, or temporary EOA delegation) are exactly where we see the most signature misuse and bot behaviors.

---

Quick glossary (decision‑maker edition)

• Smart account (ERC‑4337): A contract account that validates a UserOperation (UserOp) and then executes intent via EntryPoint. Signature format is wallet‑defined; signature bytes may be ECDSA, EIP‑1271 contract signatures, aggregates, or wrappers. (ercs.ethereum.org)
• Delegated call (in this post): Any execution path where the account routes control to external code on its behalf: Safe modules, ERC‑7579 plugins/executors/validators, or EIP‑7702 delegated code. Some paths use CALL; older/other systems may rely on DELEGATECALL. (ercs.ethereum.org)
• Contract signatures (EIP‑1271): Contracts “sign” by implementing isValidSignature. For counterfactual (not-yet-deployed) accounts, ERC‑6492 wraps the signature with deploy/prepare data. (eips.ethereum.org)

---

Where bot “signatures” actually show up

Bots rarely break cryptography; they exploit how we verify. In AA stacks, signature misuse concentrates in four surfaces:

1. UserOperation.signature

   • Can contain EOA ECDSA, contract signatures (EIP‑1271), aggregated signatures, or ERC‑6492 wrappers for pre‑deploy accounts. Weak parsers and “blind pass” verifiers are common. (ercs.ethereum.org)

2. Delegated modules/plugins

   • Safe modules (e.g., execTransactionFromModule) bypass wallet‑level signature checks by design; if a bot can invoke a permissive module, the base account’s guardrails won’t trigger. Modular ERC‑7579 accounts move toward validated CALLs (not DELEGATECALL), but mixed estates still exist. (pkqs90.github.io)

3. EIP‑7702 authorization_list

   • Temporary delegation for EOAs is encoded as tuples [chain_id, address, nonce, y_parity, r, s]. Mis‑binding these or failing to pin delegations to audited code creates a high‑impact bypass. (eips.ethereum.org)

4. Paymaster‑sponsored flows

   • Signature packing bugs and unstable validation expose paymasters to replay or mis‑use. Detection must consider ERC‑7562 validation scope and entity reputation to avoid subsidizing bots. (alchemy.com)

---

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

What to catch:

• ERC‑6492 signatures are wrapped and end with a 32‑byte magic suffix 0x...6492. Attackers abuse naive verifiers by mixing deploy‑time data or using unexpected factories. (eips.ethereum.org)

How to detect:

• If UserOp.signature ends with the 6492 suffix, unwrap and validate in order:
  1. Try deploy via provided factoryCalldata (eth_call style), 2) call isValidSignature on the target, 3) if already deployed, still call isValidSignature (to respect live logic). Pin the factory address to a vetted allowlist per chain. (eips.ethereum.org)

Implementation sketch (TypeScript):

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

Policy tips:

• Maintain a “trusted CREATE2 factory” map; drop or hard‑review 6492 signatures from unknown factories.
• Require that the unwrapped signature resolves to ERC‑1271 magic value 0x1626ba7e; reject ecrecover fallbacks for contract accounts. (eips.ethereum.org)

---

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

What to catch:

• EOA transactions with an authorization_list that delegates to arbitrary code. Signs look benign but redirect execution to an attacker’s delegate contract. (eips.ethereum.org)

How to detect (pre‑inclusion or backend):

• Parse every authorization tuple and enforce:
  • chain_id matches current chain (or 0 per the spec), nonce is monotonic per authority, and the y_parity/r/s verify the tuple hash keccak(0x05 || rlp([chain_id, address, nonce])). (eips.ethereum.org)
  • The address points to a code hash on an allowlist (e.g., Simple7702Account reference, audited wallet code) or a denylist (known malicious delegates). EntryPoint v0.8 includes a Simple7702Account as a minimal audited target for safer delegation. (etherspot.io)
• Mempool throttle: only accept one pending tx per EOA with active delegation, as clients may invalidate multiple txs post‑delegation. (eips.ethereum.org)

Signal examples of “botty” 7702 use:

• chain_id = 0 with no business need, delegates to opaque bytecode not present in your allowlist.
• Reused authorization nonces across bursty txs (spam patterns).

---

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

Why it matters:

• Consumer wallets increasingly use passkeys (WebAuthn, P‑256). Bots typically stick to k1 pipelines. With mainnet moving to a P‑256 precompile (EIP‑7951), you can cheaply verify curve type on‑chain or in simulation. (eips.ethereum.org)

How to detect:

• In contract‑signature paths, expose a “signature type” byte and enforce P‑256 vs k1 where appropriate; off‑chain, route ES256 payloads to the P‑256 precompile verifier.
• Flag mismatches: a client claiming passkey authentication but providing k1‑style 65‑byte signatures; or malformed DER→raw conversions frequently seen in bot kits.

Why this helps fraud:

• Session policies that must be bound to a device (e.g., high‑risk payouts) can require P‑256. Most bot farms won’t bother emulating FIDO attestation chains. (eips.ethereum.org)

---

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

Background:

• DELEGATECALL executes callee code in the account’s storage context: one bug and a module can own your account. ERC‑6900 and ERC‑7579 push toward CALL‑based modularity instead; Safe still permits module‑triggered execution that bypasses owner signature checks. This is a prime target for delegated‑call bots. (knauss.dev)

How to detect:

• Trace the simulated UserOp (or raw tx): If any frame under account execution performs DELEGATECALL to a non‑pinned implementation, quarantine it.
• For Safe: alert on execTransactionFromModule(...) with operation == 1 (DELEGATECALL), or modules not in your approved registry. This path bypasses owner sig verification by design. (pkqs90.github.io)
• For ERC‑7579: verify that validators/executors are installed modules (ERC‑165 checks), and that the account uses CALL semantics per the reference. (ercs.ethereum.org)

---

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

Why it matters:

• Smart accounts use multi‑dimensional nonces: 4337 encodes a 192‑bit key + 64‑bit sequence; plugins often encode validator IDs in the high bits; RIP‑7712 generalizes this. Bots exploit teams that assume a single sequential nonce. (eip.info)

How to detect:

• Parse the nonce high bits and map to expected validator/module lanes for your stack; drop UserOps whose nonce key doesn’t map to an installed validator.
• Alert on out‑of‑order sequences for the same key, or repeated use of the same key across incompatible validators (common in copy‑paste botkits). (ercs.ethereum.org)

---

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

What to catch:

• UserOps that get a paymaster signature off‑chain for one intent, then swap initCode or callData before inclusion (“signature packing” class bugs). Also, griefing patterns that exploit shared storage in validation frames. (alchemy.com)

How to detect:

• Enforce ERC‑7562 validation scope rules in simulation (code/storageset stability, staked‑entity storage access only, gas‑bounded) and maintain reputation/throttling for paymasters, factories, and aggregators. Ban entities that invalidate too many ops. (ercs.ethereum.org)
• Require that off‑chain signers hash the fully packed UserOp; run negative tests against known packing pitfalls. (alchemy.com)

---

Bot signature heuristics specific to delegated calls

These are practical, low‑false‑positive signals we use when triaging:

• ERC‑6492 + unknown factory: Magic suffix present, factory not in chain allowlist, and created code hash doesn’t match expected account bytecode. Likely scripted farm or phishing flow. (eips.ethereum.org)
• 7702 burst with opaque delegate: Multiple txs from the same EOA in <2 blocks, all authorizing a non‑allowlisted delegate address; authorization chain_id set to 0 without reason. (eips.ethereum.org)
• Safe module delegatecall: execTransactionFromModule with operation=DELEGATECALL to an unrecognized module; or a fresh module added and immediately used to spend. (pkqs90.github.io)
• Suspicious selector bundles: MultiSend‑style batches that combine 0x095ea7b3 (approve) → DEX swap selectors with no pre‑existing token approvals on the account, repeated across many senders—typical scripted arbitrage or drainer moves. Use with care; require additional signals.
• Reverted‑swap storms on L2: Clusters of reverted swaps at block tops following Dencun-era fee reductions; often bot swarms probing for MEV with spam. Quarantine or score lower. (arxiv.org)

---

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:

• Always prefer live 1271 verification when code exists (even if sig is wrapped).
• Never “accept EOA” for a known contract address. (eips.ethereum.org)

---

Example: Safe module hardening policy

• Maintain an on‑chain registry of permitted modules and allowed operations (CALL-only for most). Block DELEGATECALL unless strictly needed and audited.
• Alert if a new module is installed and used within N blocks.
• For roles/delay modules, require a minimum cooling‑off (e.g., 3 minutes) for large transfers; cancellation window thwarts many scripted drains. (pkqs90.github.io)

---

Example: 7702 authorization verification checklist

Before accepting or relaying a 7702 transaction:

• Verify each authorization tuple signature against the authority (EOA).
• Enforce chain_id == current_chain (or 0 if your policy allows cross‑chain), and that nonce isn’t stale.
• Resolve the delegated address’s code hash and compare to allowlist (e.g., Simple7702Account).
• Enforce local policy: only allow delegations to audited “batch + sponsor” code; decline “free‑form” delegates. (eips.ethereum.org)

---

Observability: what to log to catch bots early

• Full trace summaries for UserOps/tx: per‑frame op (CALL/DELEGATECALL), target, selector, value.
• Signature taxonomy for each op: {k1‑EOA, 1271, 6492‑wrapped, BLS, ES256}.
• Nonce key/sequence decoding and validator ID.
• Entities touched during validation (factory, paymaster, aggregator) + current ERC‑7562 reputation state.
• Inclusion latency and simulate vs on‑chain gas deltas; spikes often precede bot waves. (docs.erc4337.io)

---

Engineering playbook: five concrete controls to ship this quarter

1. Upgrade to EntryPoint v0.8 and run a bundler that passes the official test suite; enable Shared Mempool and ERC‑7562 enforcement. This alone cuts a wide class of griefing and invalidation spam. (bundlers.erc4337.io)
2. Add 6492‑aware signature verification with factory allowlisting for all 1271 flows (auth, login, off‑chain signatures). (eips.ethereum.org)
3. Gate delegated execution:
   • Safe: registry‑gate modules; block DELEGATECALL by default.
   • ERC‑7579 accounts: verify modules via ERC‑165, require CALL semantics, and enforce validator/executor provenance. (ercs.ethereum.org)
4. Validate 7702 authorizations and pin delegates to audited code (or Simple7702Account) until your team has a hardened policy engine. (etherspot.io)
5. Instrument nonce‑lane parsing and policy: reject UserOps whose nonce key doesn’t match an installed validator lane; expose nonce lanes in ops dashboards. (eip.info)

---

Emerging best practices (late‑2025)

• Prefer CALL‑based plugin systems (ERC‑6900/7579) over ad‑hoc DELEGATECALL integrations; when you must use delegatecall, freeze storage layouts and audit as if it were your core wallet. (knauss.dev)
• Treat passkeys as a premium assurance factor: if payout or custodial movements are high‑risk, require ES256 and verify via P‑256 precompile (EIP‑7951). (eips.ethereum.org)
• Enforce ERC‑7562 consistently at ingress (your relayer/bundler) and before bundle submission; keep a shared reputation map for factories/paymasters/aggregators. (ercs.ethereum.org)
• For paymasters, sign the entire packed UserOp and re‑encode locally to avoid packing bugs; throttle users whose sponsored ops drift from simulation. (alchemy.com)

---

Red flags your SOC should alert on

• UserOp.signature ends with 0x…6492 but the provided factory is unknown on this chain. (eips.ethereum.org)
• Safe execTransactionFromModule delegatecall to a new module within the same block as installation. (pkqs90.github.io)
• EIP‑7702 authorization_list delegates to bytecode not in your allowlist or with changing code hash (proxy‑flip). (eips.ethereum.org)
• Rapid‑fire failed swaps on L2 tops; tie back to accounts hitting your contracts to preempt bot drains. (arxiv.org)

---

Brief, in‑depth details for architects

• ERC‑4337’s nonce is split into key (192‑bit) and sequence (64‑bit). Successful designs encode the validator/module ID in key and use sequence as a monotonic counter per validator. Enforcing this mapping eliminates many “replay across lanes” tricks. (eip.info)
• ERC‑6492 verification order matters: check magic bytes, try the deploy path in a side‑effect‑free eth_call, then always prefer live 1271 checks when code exists. This prevents accepting EOA‑style sigs for contract signers. (eips.ethereum.org)
• EntryPoint v0.8 ships quality‑of‑life fixes (e.g., gas penalty tweaks) and a Simple7702Account. Aligning your code to v0.8 reduces “unknown behavior” when interacting with 7702 authorizations. (etherspot.io)
• ERC‑7562 formalizes validation‑stage isolation and reputation; don’t reinvent this. Your bundler should trace validation, enforce storage/code immutability, and ban entities that invalidate too many ops. (ercs.ethereum.org)

---

Implementation checklist (copy/paste to your issue tracker)

• Signature layer
  • Add ERC‑6492 parsing; factory allowlist per network; 1271 magic value check. (eips.ethereum.org)
  • Add signature taxonomy labels in logs: {EOA‑k1, 1271, 6492, P‑256, aggregated}. (eips.ethereum.org)
• Delegated code
  • Safe: module registry + DELEGATECALL blocklist; alert on new‑module‑then‑spend. (pkqs90.github.io)
  • ERC‑7579: enforce ERC‑165 checks for validators/executors; CALL‑only policy. (ercs.ethereum.org)
• 7702
  • Verify authorization_list tuples; delegate allowlist; single pending tx per delegated EOA. (eips.ethereum.org)
• Bundler/paymaster
  • Enforce ERC‑7562; track entity reputation; integrate bundler conformance tests (v0.8). (ercs.ethereum.org)
  • Re‑encode and hash fully packed UserOps before signing paymaster approvals. (alchemy.com)
• Observability
  • Store per‑frame CALL/DELEGATECALL traces for every executed UserOp; emit anomaly events for DELEGATECALL to non‑pinned code.
  • Nonce lane dashboards (key→validator mapping, gaps, out‑of‑order). (eip.info)

---

Final thought

Account abstraction’s superpower is programmability—so use it defensively. By verifying 6492 wrappers, pinning 7702 delegates, preferring CALL‑based modules, enforcing ERC‑7562, and logging nonce‑lane intent, you’ll catch bot signatures where they hide: inside delegated calls.

If you need a fast audit of your delegated‑execution paths or help moving to EntryPoint v0.8 with ERC‑7562 enforcement, 7Block Labs can deliver playbooks and reference code your engineers can ship in weeks—not quarters.

---

References (selected)

• ERC‑4337 core spec and docs; UserOp structure, bundlers, EntryPoint, and monitoring. (ercs.ethereum.org)
• EntryPoint v0.8 updates and Simple7702Account (Etherspot summary). (etherspot.io)
• ERC‑7562 validation scope rules (entity reputation, storage/code constraints). (ercs.ethereum.org)
• EIP‑7702: EOA delegation and authorization_list. (eips.ethereum.org)
• ERC‑6492: pre‑deploy contract signatures and verification order. (eips.ethereum.org)
• ERC‑7579 minimal modular accounts (modules, validators, executors). (ercs.ethereum.org)
• Safe module execution semantics (execTransactionFromModule; signature bypass). (pkqs90.github.io)
• Passkeys and P‑256 precompile (EIP‑7951) for strong device‑bound signatures. (eips.ethereum.org)
• MEV spam patterns on fast‑finality chains (bot storm signal for 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.