This proposal sketches out how Working Groups might work within the Ethereum Improvement Proposal ecosystem. It is frozen in time and is not updated, so it may not represent the current Working Group structure. Working Groups Definition Generally, a working group is a group of experts working together to achieve specified goals.^1 Here, the experts are people intimately familiar with a domain (like wallets, clients, DeFi, etc.) and the goals common to all of them include publishing and maintaining quality documents, and facilitating technical review/discussion. EIP Working Groups can be long-lived ("standing") or temporary ("ad hoc"). Standing Working Groups deal with broad categories of proposals, while each ad hoc Working Group deals with a more specific topic and only exists until its stated goals (such as a specific set of proposals or outputs) are accomplished. Responsibilities Upfront

This is a list of people/groups that have volunteered to be pinged on EIP discussion threads for specific topics. Forum Post There are four placeholders in the following template: As part of our process to encourage peer review, we assign a volunteer peer reviewer to read through your proposal and post any feedback here. Your peer reviewer is @<!-- TODO -->! Please note that this review **is NOT required** to move your EIP through the process. When you&mdash;the authors&mdash;feel ready, just open a pull request. If any of this EIP's authors would like to participate in the volunteer peer review process, [shoot Sam a message](https://ethereum-magicians.org/new-message?username=SamWilsn&title=Peer+Review+Volunteer)! ---

These things need to be implemented before the core spec code can be frozen: Issues in https://github.com/ethereum/execution-specs/milestone/14 [x] London [ ] The Merge [x] Opcode Refac [ ] Documentation Rendering [ ] https://github.com/ethereum/execution-specs/issues/590 [x] https://github.com/ethereum/execution-specs/issues/591

Discussion link https://ethereum-magicians.org/t/core-eips-in-an-executable-spec-world/8640 Contents [toc] Context Today, Core EIPs are used to specify changes affecting the execution layer (EL) which need to be activated through coordinated network upgrades (a.k.a. soft/hard forks). Core EIPs currently serve two purposes: explaining the motivation/rationale/security implications of the change and formally specifying it. While the former is very useful, and helps the Ethereum community understand and debate changes, the latter isn't ideal for a few reasons:

This is the second of two posts describing account abstraction. You can find the first post here. Special thanks to @adietrichs and the rest of the Quilt team for review, content, and editing! More Account Abstraction? If you haven't yet, read EIP-2938 Account Abstraction Explained for some background on account abstraction (AA) and how EIP-2938 implements it. To quickly summarize it here, EIP-2938 implements just enough AA to support single-tenant applications, with minimal consensus changes and some new transaction propagation rules. While the EIP lays the groundwork for AA and does provide a compelling solution for single-tenant use cases, like smart contract wallets, several use cases are not satisfied and require new features to be fully realized. Features Beyond EIP-2938

This is the first of two posts describing account abstraction. You can find the second post here. What is Account Abstraction As of the Muir Glacier hard-fork, out of Ethereum's two kinds of accounts—externally owned accounts (EOAs, like your MetaMask wallet) and smart contracts—only EOAs may pay gas fees for transactions. Lifting that restriction and allowing custom validity logic is, at an extremely high level, Account Abstraction (AA). In this article, we want to give a brief and understandable explanation of EIP-2938, our proposal to bring AA to Ethereum. A Concrete Example The best way to explore AA is to see what you can build with it! So without further ado, here's a 2-of-2 multisig wallet that pays for its own transactions:

The (currently incomplete) implementation of this case study can be found here: UTXO relayer. This case study is built on Quilt's proof of concept implementation of account abstraction, which differs slightly from the EIP. Introduction To explore the features, limitations, and peculiarities of our proposed account abstraction approach, Quilt has built an example application on top of our geth fork. The system we've chosen is a toy UTXO implementation that supports deposits to and withdrawals from regular Ethereum externally owned accounts (EOAs), and internal transfers within the contract. The Utxo contract itself pays for transactions using its internal balances, so once funds are deposited in the contract, no external gas is required. Overview