PIP-22: add EIP-3074 style account abstraction

While there is extensive discussion around EIP-4337 style account abstraction, there is another extensively developed account abstraction proposal that can be adopted by the Polygon ecosystem: EIP-3074

To be clear, this is not a competing proposal to 4337, both have strengths, and can even unlock additional possibilities when both are implemented.

3074 as a proposal is nearly three years old, and in that time has seen strong support from various parties, including developer suites from Quilt, sample repositories demonstrating capabilities, and more.

Whereas 4337 focuses on a system of account abstraction that does not require a hardfork, instead relying on smart contracts and new JSON-RPC methods, 3074 adds two new opcodes to the EVM: AUTH and AUTHCALL. This is likely the major part of the reason 3074 has not yet been included in Ethereum; it necessitates a hardfork change for application-layer functionality, and as such, tends to fall by the wayside.

This is potentially a reason why 3074 is an attractive target for alternative ecosystems such as Polygon. The coordination costs of hardforking are significantly lower, and 3074 is a fairly simple EIP, necessitating only the addition of the two opcodes, which are specified clearly in the EIP. If there is support for this proposal, making a Polygon chain 3074-compliant should be straightforward.

As with any account abstraction proposal, aside from the on-chain implementation, there is great need for proper tooling for interaction. Fortunately, 3074 is well-recognized, and it is likely that many wallets already have familiarity with the project.

A PIP PR has been opened here proposing the adoption of EIP-3074: added acct abstraction pip by wschwab · Pull Request #85 · maticnetwork/Polygon-Improvement-Proposals · GitHub

This post invites discussion around the merits or deficiencies of adopting 3074.


This raises a larger question on should Polygon PoS be EVM equivalent or EVM+, would love to see the community weigh in on this question as it represents a big change in philosophy for the chain.


I wouldn’t mind seeing Polygon delivering EVM+ capabilities as long as these are clearly earmarked as add-ons to the origin EVM. Innovation should work both ways EVM<->Polygon EVM+.

idk - even as of now, Polygon POS does not follow strict EVM equivalency since it doesn’t have a beacon chain, and therefore doesn’t have PREVRANDAO

Is there anything specific gained by not having an EIP like 3074? I agree that there should be full compatibility with Ethereum’s execution environment, ensuring that tooling for Ethereum works for Polygon POS, but what reason is there for not including additional opcodes?

Again, especially in light of the fact that for any other L1/L2 protocol there have been divergences for Ethereum’s protocol. Polygon POS uses a dPOS system, which was different than Ethereum’s POW at its inception, and is different than Ethereum’s post-Merge POS. Why would the line be drawn at specific opcodes?

1 Like