Ethereum

3074 couldn’t come at a better time: There’s momentum to define an onchain permissions system for smart contract accounts, and 3074 can allow EOAs to still enjoy some of its benefits.

My latest draft:

3074 couldn’t come at a better time: There’s momentum to define an onchain permissions system for smart contract accounts, and 3074 can allow EOAs to still enjoy some of its benefits.

My latest draft: https://metamask-consensys.notion.site/Permissions-Standard-2-DApp-Signing-Flow-ae9bc05b38624bc09484a23ec94f70b5

co founder of @metamask . Making computers behave for us.

It feels like there are now two parallel tracks to the same objective.

How can we ensure these two standards interoperate without creating a headache for applications?

Elevating onchain creators 

@nodefoundation @brightmoments 
@ampsfun

2/ This has kicked off a flurry of developer activity that is impacting applications.

Most notably, the opportunity to allow users to onboard with email, social, etc.

This in turn creates an opportunity for third parties to provide these services so every app doesn’t need to reinvent the wheel..

1/ Got it. Let me try to more clearly articulate my question (although it may take more than one cast):

4337 enabled smart accounts as an alternative account type to EOAs. 

This had the benefit of allowing more granular permissions without requiring a consensus-level change to implement…

I have to guess you mean 4337? I think they’re more complementary than many people initially assume.

The linked post you’re replying to is an example of an interface that both can implement, allowing app developers to not care which kind of account the user has.