Content
@
0 reply
0 recast
0 reaction
Dan Finlay 🦊
@danfinlay
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
2 replies
3 recasts
36 reactions
phil
@phil
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?
2 replies
0 recast
0 reaction
Dan Finlay 🦊
@danfinlay
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.
1 reply
0 recast
0 reaction
phil
@phil
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…
1 reply
0 recast
0 reaction
phil
@phil
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 reply
0 recast
0 reaction
phil
@phil
3/ The tradeoff is that we appear to be heading to a more fragmented system. Instead of one seed phrase with many wallets, I now have an EOA, some smart contract wallets with one provider, more with another, etc. These are centralized services and will want to maintain their market share..
1 reply
0 recast
1 reaction
phil
@phil
4/ My concern (and question) is how we can continue to encourage applications to have backwards compatibility for EOAs, when there will be increasing pressure to “just outsource it” to the AA wallet providers. This is exacerbated if there is functionality enabled for AA wallets that EOAs can’t support..
1 reply
0 recast
0 reaction
phil
@phil
5/ I wasn’t familiar with 3074 until recently, and am glad it seems to have support. I also read your proposal and am hopeful that the two account types will maintain parity. But I worry feature drift & natural incentives from AA providers will create a situation like OAuth where a few companies own the gateways.
1 reply
0 recast
0 reaction
