# Summary AA Event May 24 Berlin ## EIP Specifics went through the dimensions of the eip where alternative approaches have been proposed. for now, consensus seems to mostly be around following the pr by matt: https://github.com/ethereum/EIPs/pull/8561 list of specifics: ### how to specify target - address in tx, not code - more efficient than min proxy - sign over address, not code - signing over code could protect against replay on chains with different code at same address - requires code lookup to derive signer address. makes it impossibly to statelessly reason about which accounts can send out ETH within tx - alternative would be to also add signer address to tx, but very inefficient - don't run initcode - initcode could prevent griefing / censorship attacks where user signed a 7702 delegation to smart contract that doesn't support some interface (e.g. 1155) necessary for some passive interactions (e.g. receiving funds) - alternative mitigations preferable, initcode too heavy a solution ### replay protection caveat: still some contention around these - chainid: optional - desire to have ability to limit to one chain - but also, desire for ability to delegate once for all chains - solution: optional chainid (0 for all chains) - leave it up to EOA wallets whether to expose 0 (see wallet guidance section) - nonce: optional - desire to have revocability - but also: desire to have permanently valid delegations - nonce simplest, but overloaded (sending txs, deploying contracts). so using strict nonce signing would prevent permanent delegations - solution: optional nonce (rlp null for no nonce) ### restrictions storage behavior identified as biggest open question, see section below - no storage restrictions - persistent storage creates danger of problems when moving from one smart account implementation to another - storage could be banned for 7702 accounts to avoid this - downside: breaks with existing smart account ecosystem - existing smart accounts with proxy pattern have same issue - solution: leave it up to smart account ecosystem to figure out best practices - no selfdestruct ban - selfdestruct ban desirable, but too much overhead if only opcode with modified behavior ### forward compatibility - no permanent upgrade flag - flag desirable so that we don't need to wait for future hard fork to unlock permanent migration - but: temporary nature of 7702 sidesteps questions around permanent EOA upgrades (e.g. ecrecover / permit) - shipping without permanent upgrade capabilities gives us time to figure these questions out - decision: ship without permanent upgrade capabilities ## Open Topics ### storage pattern - where is smart account ecosystem going? what is best storage pattern to ensure upgradability? candidates: - solidity support for storage offsets - separate storage contracts - 7702 decision will have a lot of weight, many more EOA users than existing smart account users - if storage allowed, will make safe storage patterns important - if storage banned, will establish external storage accounts (maybe reuse proxy?) as upgrade-proof pattern - how to get to high confidence on this over the next ~month? ### wallet guidance - lesson from 1559: important to give clear guidance to wallets how to implement complex new features - 7702 in particular has many nuances around wallet behavior - not all of these are currently even agreed upon! - mostly around whitelisting: - what to whitelist? - maybe ecosystem-wide list? - only 4337? - one standardized proxy only? (see section below) - override possible? - maybe only in most restrictive mode (nonce and chainid commitment)? - how to expose different replay protection modes? ### proxy pattern / security - standardize around one proxy contract? - how to handle upgradability of target? - if current smart account has upgrade rights, this completely sidesteps the 7702 whitelisting protections - alternatives? maybe always require EOA signature for upgrade?