# 3074 ideas Here's an assortment of ideas Sam, Ansgar and I have had rumbling around for some time. ## EOA 2.0 A nice place to start would be an invoker that just improves the status quo for EOA users. It should add only the most basic functionality: * self-relayed * each authorization only valid once * multiple ops in a single tx * time limited, `validBefore` and `validAfter` support ## I Lost My Ledger Yes 3074 doesn't support *true* account recovery in the sense that you can migrate control of your account to another key. However, losing access to a private key is one major hurdle for EOAs. A simple invoker could be written to accept an authorization from the user and a multi-sig from other keys. If both are valid, the invoker should let the caller make any arbitrary batch call. ## 4337 Trojan Horse The ultimate synergy: 3074x4337. There are a few routes to combine the two. The simplest (but most expensive) route is to deploy a new invoker SCW 1:1 for any EOA that wants to use 4337 tooling. This could be a project. The more complicated route is to find an efficient integration of 3074 in the 4337 ecosystem. Due to the txpool rules, it seems likely the actual 4337 standard will need to be tweaked to support user ops from EOAs. This spec diff would be a great output. ## Passkeys Everywhere Another cool thing about 3074 is how it let's you get your EOA key away from day-to-day operations. An invoker could take an auth message where an EOA delegates control of the account to another key (could be any crypto scheme) and that key could have whatever privileges the EOA decides. ## Sponsorship A larger scale 3074 invoker could look into how sponsorship might work. Given 4337 already has a pretty well set path for decentralized sponsorship, it might be more useful to consider the more basic centralized sponsor case. It will be particularly useful to understand the relationship of trust between the sponsor and sponsee. In general, this should be a trustless relationship, however it will be possible for the sponsee to grief the sponsor to a degree by front running their transaction and sweeping their account before they're forced to pay. ## Synthetic Multi-Sig Similar to counterfactual contract deployment, you could construct an arbitrary signature over an auth message which delegates control to another private key and have a "zero cost" deployment of smart account-like account. ## Send to ENS Address A small project or add-on to a more complicated project above could be to resolve ENS names on-chain so users don't need to rely on off-chain resolvers. To do this, you would just need the calldata to be the actual ENS identifier and then in the invoker you would pass this data to the resolver contract.