EIP-7702, activated as part of the Pectra upgrade on May 7, 2025, lets any externally owned account temporarily delegate its execution to smart contract code without changing its address or giving up its private key. It is one of the more consequential changes to how Ethereum accounts behave since the network launched, and it has been adopted quickly: MetaMask, Rabby, Trust, and several exchange wallets shipped support within months. It has also, within weeks of going live, become the single most reliable tool for automated wallet draining that Ethereum has ever produced. Wintermute's research team found that more than 97% of observed 7702 delegations in the first month after Pectra pointed to a small number of near-identical "sweeper" contracts, now informally cataloged as CrimeEnjoyor, CrimeEnjoyor2, and AdvancedCrimeEnjoyor. These aren't exotic zero-days. They're delegate contracts doing exactly what 7702 lets any contract do, take control of an EOA's execution, deployed by people counting on the fact that most users and even most wallets have no reliable way to know, before signing an authorization, whether the contract on the other end is safe. This proposal asks Ethereum House to fund and help govern an open, independently maintained **Delegate Contract Security Registry** for EIP-7702: a public dataset and set of tools that lets wallets, dApps, and security researchers check a delegate contract's authorization pattern, ownership, audit status, and behavioral risk signals before a user signs. It is not a replacement for existing module registries like Rhinestone's ERC-7484-based registry, which solves a related but distinct problem for ERC-7579 modular accounts. It is meant to sit one layer below that, at the point where a raw EOA is first asked to authorize *any* code at all, the exact point where the sweeper attacks are happening. I'm asking for a modest initial grant to fund a two-person working group for six months to build the registry schema, seed it with known-malicious and known-safe contracts, and get at least two wallet integrations shipped, with a public dashboard anyone can query. --- ## Where I'm Coming From I want to be upfront about who I am before asking anyone to fund something. I'm a software and smart contract engineer, not someone who's shipped a wallet used by hundreds of thousands of people. My background is closer to systems than to finance. I spend a lot of my time thinking about distributed systems, low-level infrastructure, and how software gets built and secured, and smart contracts specifically are where that interest sharpens into something closer to genuine enthusiasm: the idea that code can hold value and enforce rules without a trusted intermediary is still, to me, one of the more interesting engineering problems out there. Over the last couple of years that curiosity has pulled me toward Ethereum specifically. Not because I think it's the answer to everything, but because it's one of the few places where protocol design, cryptography, economics, and real user harm collide in public, in real time, and where the people making the decisions actually argue about them in the open instead of behind closed doors. I didn't come to this proposal from a top-down "what does Ethereum need" angle. I came to it from reading about the CrimeEnjoyor sweepers and being genuinely unsettled that a protocol upgrade shipped with strong engineering behind it (EIP-7702 replaced an earlier design, EIP-3074, specifically because 3074 gave a single trusted "invoker" contract too much power over user accounts) and within a month of going live, the dominant real-world use case for the exact primitive it introduced was mass wallet draining. That's not a failure of the EIP. It's a failure of the surrounding tooling to catch up to what the EIP made possible. That gap is where I think someone with more time than money and more curiosity than credentials can actually contribute something useful, by doing the unglamorous work of building and maintaining a dataset that wallets can plug into. I'm also aware of the limits of my own standing here. I'm not asking Ethereum House to trust my judgment about which contracts are safe. I'm asking for funding to build a *process* (multi-source data collection, independent verification, clear disclosure of methodology) that doesn't depend on any one person's judgment, mine included. If this proposal has a weakness, it's that I don't yet have the reputation in this specific niche that some registry maintainers do. I think the right response to that is transparency about process, not asking anyone to take it on faith. --- ## Background Ethereum's account model has had exactly two account types since genesis: externally owned accounts (EOAs), controlled by a private key with no programmability, and contract accounts, which can hold arbitrary code but need to be deployed and can't initiate transactions on their own. This split has caused real UX pain for years: no native multi-call, no gas sponsorship, no spending limits, no recoverability. ERC-4337, shipped in 2023, worked around this without a protocol change by introducing UserOperations, an alternate mempool, and bundlers that relay these operations on behalf of smart contract wallets. It works, but it only applies to accounts that are smart contract wallets from the start; it does nothing for the huge number of EOAs already holding funds. EIP-7702 closes that gap at the protocol layer. It introduces a new transaction type (`SET_CODE_TX_TYPE = 0x04`) carrying an authorization list of signed tuples (chain ID, target contract address, and nonce) that let an EOA point its execution at a piece of deployed code for as long as the delegation is active, while keeping the same address and the same private key. The authors are Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett. It replaced EIP-3074, a two-year-old proposal that was ultimately abandoned because its "invoker" model concentrated too much trust in one contract. 7702's design is more flexible and, on paper, safer: the EOA can delegate to any contract, not just one blessed invoker, and can revoke the delegation later. In practice, "can delegate to any contract" is exactly the problem. A delegate contract is, by design, granted the ability to act with the full authority of the EOA. If that contract is malicious, or simply careless about which calls it authenticates, it becomes what one security write-up called "a public power of attorney over the EOA." Since Pectra activated, adoption has been real (industry estimates put smart wallets, across both 4337 and 7702, well over 100 million by 2026), but so has abuse. Wintermute's June 2025 research found that the overwhelming majority of 7702 authorizations on mainnet in the weeks after launch pointed to sweeper bytecode, and by later that summer, individual losses in the seven figures were being reported from single incidents, including one where a user believed they were approving a routine swap. SlowMist later documented the same attack pattern being used against holders of other tokens, combining leaked private keys with automated delegate deployment to drain funds within seconds of a deposit landing. It's worth being precise about what's actually going wrong, because it affects what a fix should look like. Taylor Monahan's observation, which security researchers I trust generally agree with, is that 7702 didn't leak anyone's private keys; the root cause in most sweeper cases is a key that was already compromised through some other channel. What 7702 changed is the economics of exploitation: instead of running a bot that races to front-run every incoming deposit to a compromised address, an attacker can install a standing delegation once and have it sweep automatically, cheaply, and reliably, forever, until revoked. Separately, and just as concerning, phishing sites have started capturing 7702 authorization signatures directly. A user signs what looks like a normal batch transaction (say, a token approval bundled with a swap) and unknowingly authorizes a sweeper contract in the same signature. --- ## Current Problems Three distinct but related problems sit underneath the sweeper epidemic: **1. There's no shared, queryable source of truth about delegate contract safety.** Wintermute's research is excellent but is a point-in-time analysis published as a research note, not a live, queryable dataset. GoPlus Security and others do some of this work commercially, but there's no open, non-proprietary registry a wallet can check against without a paid API relationship, and no standard schema for what "safe" even means in this specific context. **2. Wallets are, individually, reinventing detection.** Each wallet team that wants to warn users about sweeper delegation has to build its own heuristics, usually from scratch, usually without the benefit of what other teams have already learned. This is a classic public-goods underprovision problem: the cost of building good detection is borne per-wallet, but the benefit of a shared dataset would accrue to the whole ecosystem. **3. The authorization-signing UX gives users almost nothing to go on.** Even a careful user, shown a 7702 authorization request in their wallet, typically sees a contract address and not much else: no audit status, no indication of how many other EOAs have delegated to it, no behavioral summary of what the code actually does when invoked. This is a distinct but related UX problem from the widely discussed blind-signing issue with EIP-712 messages generally; 7702 authorizations have their own opaque signing surface that predates any transaction simulation the wallet might do. None of these three problems require a protocol change. They're solvable with better shared infrastructure, which is exactly the kind of thing a public-goods-oriented gathering like Ethereum House can meaningfully fund without needing anyone's mainnet consensus. --- ## Why Existing Solutions Are Not Enough I want to be specific here, because it would be easy to write this proposal as if nothing exists yet, and that isn't true. **Rhinestone's Module Registry and ERC-7484.** ERC-7484 standardizes an interface for module registries so ERC-7579-compliant modular smart accounts can check a module's audit status before installing it, and Rhinestone maintains the largest reference implementation of this, with Safe's official 7579 adapter wired up to use it. This is real, useful infrastructure, and it's a template worth learning from. But it solves a narrower and later-stage problem: it vets *modules* being installed into an *already-existing modular smart account*. It says nothing about the moment an EOA is first asked to sign a raw 7702 authorization tuple pointing at arbitrary bytecode, which is precisely the moment sweeper attacks happen, often before any smart account or module system is ever engaged. A user with a plain MetaMask EOA signing a phishing site's authorization request gets no benefit from ERC-7484 at all. **Wintermute's CrimeEnjoyor research and naming.** This work is genuinely useful. Wintermute even published the decompiled sweeper source with a warning baked into it, which is a clever piece of public education. But it's a research artifact, not infrastructure. It isn't versioned, isn't designed to be queried programmatically by a wallet's signing flow, and isn't something with a commitment to ongoing maintenance as new sweeper variants appear (and they will: CrimeEnjoyor2 and AdvancedCrimeEnjoyor already exist as evolutions of the first pattern). **Commercial transaction-simulation and phishing-detection tools.** Several wallet-security companies do real-time simulation and warn users about suspicious transactions, including delegation requests. These are valuable and I'm not proposing to compete with them. But they're closed-source, proprietary detection pipelines, integrated into specific wallets under specific commercial terms. A smaller wallet team, an open-source wallet, or a dApp that wants to warn users before routing them into a 7702 flow has no equivalent open resource to build on. This is the same pattern Ethereum has solved before in other domains: Gitcoin's Passport and Optimism's public-goods funding models exist precisely because purely commercial solutions to shared ecosystem problems tend to under-serve open-source and smaller players. **Wallet-level heuristics (like flagging first-time delegation targets).** Some wallets have started warning users the first time they see a new delegate contract address, which helps somewhat, but it's a weak signal on its own; a delegate contract can be "new" and safe, or "seen before" and still malicious if it was deployed months before use. It doesn't distinguish audited, well-behaved delegate patterns (batching, session keys, spend limits) from sweeper bytecode dressed up to look similar. What's missing, specifically, is something in between Wintermute's research and a commercial black box: an open, independently governed, continuously updated registry, with a public methodology, that any wallet, commercial or open-source, can query for free or at cost, at the exact moment a 7702 authorization is about to be signed. --- ## Proposed Solution I'm proposing Ethereum House fund the creation of the **EIP-7702 Delegate Contract Registry (DCR)**: an open dataset, a lightweight verification process, and a reference API/SDK that any wallet or dApp can integrate to check a delegate contract before a user signs an authorization. The registry classifies delegate contracts along a small number of axes: - **Known-malicious**: bytecode matching documented sweeper families (CrimeEnjoyor and its variants, plus new families as they're discovered), sourced from Wintermute's published research, SlowMist's incident reports, and independent bytecode-similarity analysis run by the working group. - **Audited / known-safe**: contracts that have passed a defined disclosure and review process, not a full paid audit (that's out of scope for a project this size), but a structured checklist covering the properties that matter specifically for 7702 delegates: does every state-changing call authenticate against nonce, gas, value, and target; does the contract avoid storage layout collisions with common EOA usage patterns; is the source verified and does it match deployed bytecode. - **Unknown**: everything else, which is the honest default for the vast majority of addresses, and is reported as such rather than defaulting to either "safe" or "unsafe." This is deliberately close in spirit to how Rhinestone's ERC-7484 registry works for modules, and to how curated token/contract allowlists like Uniswap's default token list or Etherscan's verified-contract labels work elsewhere in the ecosystem. The novelty isn't the registry pattern itself, it's applying that pattern specifically to the raw 7702 authorization-signing moment, which nothing currently covers. --- ## Technical Design **Data model.** Each entry keys on `(chain_id, delegate_address, code_hash)`. Storing code hash alongside address matters because a delegate address's bytecode can, in principle, change if it's deployed via certain proxy patterns, so the registry needs to invalidate stale classifications rather than trusting an address in perpetuity. **Classification pipeline.** 1. *Bytecode similarity scoring* against a maintained corpus of known sweeper bytecode, using a straightforward opcode-sequence diff rather than anything exotic. This is intentionally simple so it's auditable by anyone, not a black-box model. 2. *Static analysis checks* for the specific failure modes documented by auditors: missing signature commitments to nonce/gas/value/target, unrestricted `SELFDESTRUCT` or arbitrary `DELEGATECALL` targets, and storage slots that collide with common token-approval patterns. 3. *Manual review queue* for anything flagged ambiguous by the first two steps, reviewed by working-group members and, ideally over time, by outside volunteer reviewers with a public changelog of who reviewed what and when. **Distribution.** The registry itself is just data: a versioned, signed JSON dataset published to IPFS with a content hash anchored on-chain (a simple append-only log contract, not a novel primitive) so wallets can verify they're reading unmodified data rather than a compromised mirror. On top of that, a small reference API and a JS/TS SDK let wallets query by address and get back a classification plus the evidence behind it, so a wallet team isn't forced to trust the registry blindly; they can inspect why an address was flagged. **Wallet integration point.** The natural integration point is exactly where a 7702 authorization request is about to be signed, before the signature, not after. A wallet that integrates the SDK can show the classification inline in the signing prompt ("this delegate contract is unrecognized" / "this delegate contract matches a known sweeper pattern, do not sign" / "this delegate contract has passed community review"). This is intentionally a narrow, single-purpose integration, not a general transaction-simulation product, so it's cheap for any wallet to add regardless of what other security tooling they already have. **Relationship to ERC-7484.** Where a wallet or account already uses an ERC-7484-compatible module registry for ERC-7579 modules, the DCR is complementary rather than competing: it can be exposed as an additional registry adapter following the same interface pattern, so infrastructure that already speaks ERC-7484 doesn't need to learn a second protocol to also check 7702 delegate targets. --- ## Security Considerations I don't want to undersell the ways this can go wrong. **False negatives are the biggest risk.** A registry that says "unknown" for a brand-new sweeper variant provides no protection against exactly the attacks that matter most in the first hours after a new pattern is deployed. This is a real limitation, and I don't think there's a way to fully solve it; bytecode similarity scoring will always lag novel obfuscation. The honest framing here is that the registry raises the cost of *reused* attack patterns, which is the overwhelming majority of real-world sweeper activity (Wintermute's own numbers show over 97% of delegations reuse a small number of code families), while doing little against a genuinely novel one-off attack. That's a meaningful but bounded improvement, not a solved problem. **False positives carry real cost too.** Flagging a legitimate, safe delegate contract as risky, say, a new wallet vendor's batching contract that hasn't gone through review yet, could unfairly damage adoption of genuinely good infrastructure. This is why "unknown" has to be a distinct, neutral state from "flagged," communicated clearly in any wallet UI that consumes the registry, rather than collapsing to a binary safe/unsafe. **The registry itself becomes an attack surface.** If the append-only log contract or the IPFS publishing process is compromised, an attacker could poison the dataset wallets are trusting. This is why data integrity anchoring (signed, versioned, on-chain content hash) matters even for a project this small; the registry needs to be at least as hard to tamper with as the thing it's protecting against, or it isn't worth building. **Governance capture of the classification process.** Any curated list creates a target for social engineering; getting a malicious contract "reviewed" and marked safe by compromising or misleading a reviewer is a real threat model, one that commercial audit firms deal with by having liability and reputational skin in the game. A volunteer-driven registry has weaker guarantees here, which is why the manual review queue needs a public changelog and multiple-reviewer sign-off rather than any single person's judgment, mine included. --- ## Governance Considerations I don't think this should be governed by me alone, or informally by whoever happens to be maintaining the GitHub repo at a given time. I'd propose: - A small working group (starting at 2, with room to grow as scope is validated) accountable to Ethereum House for the initial six-month grant period, with monthly public updates. - Classification methodology published openly from day one, so anyone can audit *how* an entry got classified, not just *that* it was classified. - A dispute process: any project whose delegate contract gets flagged can request re-review, with the burden on the working group to publish its reasoning, not on the flagged project to prove innocence in private. - After the initial grant period, a path toward broader multi-stakeholder governance, ideally involving wallet teams who've integrated the registry, since they have the most direct stake in its accuracy, rather than the working group holding indefinite unilateral control. I'd also flag, in the spirit of intellectual honesty this proposal is supposed to have: there's a real argument that this kind of security-classification infrastructure works better as a commercial venture with liability and dedicated headcount than as a volunteer public good, and that Ethereum House funding a version of this might just get outcompeted or superseded by a well-funded commercial player within a year. I think that's a fair critique. My response is that even if it is eventually superseded, an open, freely licensed reference implementation and dataset still has value; it sets a floor of protection that doesn't depend on any wallet's commercial relationships, the way Gitcoin Passport and other open identity/reputation primitives have retained value even as commercial alternatives exist alongside them. --- Implementation Roadmap **Month 1:** Publish the classification schema and methodology document for public comment. Seed the known-malicious list from existing published research (Wintermute, SlowMist, and any other public incident reports) rather than starting from zero. **Month 2:** Ship the append-only on-chain log contract and the first signed dataset publish to IPFS. Publish the reference API. **Month 3:** Ship the JS/TS SDK and integration documentation. Begin outreach to at least three wallet teams (prioritizing open-source wallets, since they have the least access to commercial detection tooling) for pilot integration. **Month 4:** First wallet integration ships, even if behind a feature flag. Open the manual review queue to outside volunteer reviewers with published criteria for who can review. **Month 5:** Second wallet integration. Publish a public retrospective on classification accuracy so far, including known false positives/negatives, rather than only publicizing successes. **Month 6:** Publish a governance transition proposal for how the registry is maintained and funded after the initial grant period, and report back to Ethereum House with a full accounting of the grant and a recommendation on renewal. Expected Impact If even one wallet with meaningful user count integrates this before a user signs a 7702 authorization, and it prevents even a handful of the kind of six- and seven-figure losses that have already been documented, the project pays for itself many times over relative to the grant size. Beyond direct loss prevention, a shared, open dataset lowers the barrier for smaller and open-source wallet teams to offer the same protection commercial wallets are starting to build proprietarily, which matters for keeping the wallet ecosystem competitive rather than consolidating security around whichever teams can afford to build detection in-house. --- ## Risks and Trade-offs The honest risks, stated plainly: the registry could lag novel attacks and give false confidence; a volunteer-governed classification process is a softer target than a commercial audit relationship; and there's a real chance this gets superseded by better-funded commercial tooling before it matters much. I've tried to address each of these above rather than wave them away, because I think a proposal that only lists benefits isn't one that should be taken seriously by people who'll actually have to maintain or rely on this. --- ## Pros - Addresses a documented, ongoing harm (sweeper drains) rather than a hypothetical one. - Complements rather than duplicates existing infrastructure (ERC-7484/Rhinestone, commercial detection tools). - Open data and open methodology lower the barrier for smaller/open-source wallets specifically. - Modest budget and a clear, falsifiable path to showing results within six months. - Doesn't require any protocol change or mainnet consensus; purely additive infrastructure. ## Cons - Bytecode-similarity classification will always lag genuinely novel attacks. - Volunteer governance is a weaker guarantee than a commercial audit relationship with liability. - Real risk of being outcompeted or superseded by better-resourced commercial players. - Requires ongoing maintenance after the grant period ends, with no committed long-term funding source yet. - Misclassification (in either direction) carries real cost to users or to legitimate projects. --- ## Alternatives Considered **Do nothing and rely on wallet teams and commercial vendors to solve this on their own.** This is already happening to some extent, but it leaves open-source and smaller wallets under-protected, which is exactly the kind of gap public-goods funding exists to close. **Push for a protocol-level fix instead (e.g., restricting what delegate contracts are allowed to do).** I don't think this is realistic or desirable. EIP-7702's flexibility is a feature, not a bug, and restricting delegate contract behavior at the protocol level would undo the design decision that made 7702 preferable to EIP-3074's more restrictive invoker model in the first place. **Fund a full commercial-grade audit firm to review every delegate contract before deployment.** This would be far more thorough per-contract but doesn't scale to the volume of delegate contracts being deployed, and doesn't help retroactively with the sweeper contracts already active. A lighter-weight, continuously updated registry can cover more ground even if each individual entry gets less scrutiny than a full audit would provide. --- ## Why This Matters for Ethereum Ethereum's account abstraction roadmap, from ERC-4337 through EIP-7702 to the modular account standards like ERC-7579, represents a genuine, hard-won improvement in what wallets can do for ordinary users: gas sponsorship, batched transactions, passkey-based signing, spending limits, social recovery. All of that work is only worth as much as users' trust that signing something won't instantly empty their wallet. Right now, that trust is being actively eroded by a well-documented, high-volume attack pattern that exploits the exact primitive the ecosystem is betting its UX future on. Closing that gap isn't a nice-to-have alongside the account abstraction roadmap, it's a precondition for that roadmap actually delivering the UX gains it promises, rather than teaching a generation of users that signing a wallet prompt is inherently dangerous. --- ## Concrete Next Steps 1. Gather feedback on this draft from Ethereum House and, ideally, from wallet security researchers directly (Wintermute, SlowMist, and the eth-infinitism/OpenZeppelin communities have all published relevant work and would have real technical objections worth hearing before this goes further). 2. Publish a public classification methodology document for comment, independent of any funding decision. 3. Identify two or three open-source wallet teams willing to pilot an integration, to make sure the technical design reflects what integrators actually need rather than what I assume they need. 4. Return with a firm line-item budget once scope has been stress-tested by this feedback. --- ## Conclusion I don't think this proposal solves account abstraction security. I think it closes one specific, well-documented, currently unaddressed gap: the moment between "a user is about to sign a 7702 authorization" and "the delegate contract does whatever it wants with their account," where right now almost nothing stands between a user and a sweeper contract except vigilance and luck. That gap is closable with unglamorous, maintainable, open infrastructure, and I'd like Ethereum House's help building it.