They explored the idea of reusing modules, discussed the importance of standardization and compatibility, and shared insights on optimizing gas usage and customizing authorization processes. The conversation also touched on the need for tooling, testing, and establishing standards before considering a new language or DSL.
The developers behind ERC-4337 emphasized maximizing code reuse, collaboration, and the importance of aligning standards and tooling for smart contract wallets.
Read the full conversation below:
Vitalik Buterin:
“Everyone building an ERC-4337 wallet, I am curious what your plans are in terms of the wallet contract. Are you planning to write your own, copy an existing one (the soul wallet one? something from some other team?), do something else?”
Peter | Hexlink:
“Would definitely reuse some of the modules if it’s great, for example dailylimit one”
Vitalik Buterin:
“Why not reuse more?”
kannu:
“you mean reuse more modules?”
Vitalik Buterin:
“Or reuse the core”
Garvit | Proton:
“I think EIP-6900 https://eips.ethereum.org/EIPS/eip-6900 is an effort towards reusability”
Raymond Feng:
“We’re evaluating multiple ERC-4337 compatible wallets – key factors include EIP1271 support, standalone UI (beyond headless), and extensibility.”
Eugene @ wasd3r:
“Some implementations are not working or in a primitive stage. Would be good to have more modules to copy.”
kannu:
“I think mostly everyone might be using simpleAccount as base/core implementation and then adding more plugin/extension to it as per different usecase need”
Raymond Feng:
“I wish there is a curated list of Wallet Factories”
hao:
“Hi, this is Blocto wallet. We started building contract wallet forked from dapper wallet in 2019 with a centralized gas subsidization service. Now based on that, we are adding on new 4337 compatible interface, moving our gas subsidization framework towards decentralized paymaster, and also implementing schnorr signature verification for more compact multi signature bytes.
And our 4337 compatible wallet is now under audit, and will be open sourced soon 🙏”
Jeremy | Fluvi:
“We are writing our own contracts on user wallet contract for these reasons.
1. Optimize gas usage. Since contract wallets are already using up to 7 times compared to EOA wallets we have to optimize on where we could.
2. Customizing the authorization process.
3. Extending the functionalities.
but generally making it compatible with the standard 4337 contracts”
kannu:
“Interesting!!! I think all 22 different AA wallet projects listed on github link above would be doing something similar”
sodii | Fluvi:
“We couldn’t reuse becuase our architecture is somewhat different: our 4337 “wallet” is not a SCA but a user-owned entrypoint that controls multiple SCA.”
kannu:
“is there any specific usecase you guys are supporting which can’t be handle using ERC4337?”
sodii | Fluvi:
“we do support and comply with 4337, in a slightly different way than the intended way though.
We wanted to allow our users to have multiple addresses, with shared authorization.
reusing or modularizing individual wallets sound interesting though”
Jeremy | Fluvi:
“I think each wallet will have different needs: some contract wallets will be based on open source contracts, with extensions to build quickly and focus on the UI while others have their own method.
I wonder if it is possible to have a magic bullet that satisfies everyone’s needs with one contract. But I think everyone would generally agree on the needs for standardization in the interface”
Jayden@soulwallet replied to Vitalik:
“1 Reusable core is crucial, which means the wallet foundation of all wallets should not be lower than the first threshold.
2 Standardized external interfaces are crucial, which means contract wallet contracts can migrate between different frontends.
Of course, there are many challenges that need to be addressed:
1 How wallets utilize modular contracts under the same standardized definition is still a significant challenge, and it may require introducing a standardized Domain Specific Language (DSL).
Having modules within contract wallets with their own independent UI is also a feasible approach, but it needs exploration (which is what we are currently doing).
2 Establishing the challenges of “reusable core” and “standardized external interfaces” will take time. The collective goal is to achieve AA, and in the early stages, there should be more diversified implementations rather than immediately adhering to a single standard. Each team needs to contribute wisdom and experience to improve ERC6900 (which is what we are currently doing)[This also means that the authors of ERC6900 have the responsibility to proactively reach out to everyteam on a monthly basis to gather their thoughts and progress the EIP cc @adam712 ].
Based on this consideration, as an individual, I do not recommend any team directly forking an existing contract wallet. However, it is essential to pay attention to each other, learn from other teams’ experiences, and have a unified space, such as the 4337 Mafia group, where each team can regularly share their design ideas (which is what we are currently doing) [means that 4337 Mafia needs to regularly gather and organize important design ideas from all teams cc @IheartEthereum ].”
Vitalik Buterin:
“Actually I think the idea of making a DSL for wallets is really cool! Definitely worth strongly considering”
Richard | Co-Founder @ Safe:
“I am not sure about this. Normally a new DSL is not compatible with existing tooling. Considering that the current tooling for 4337 is not yet sufficient and many argue the same for Solidity (but here it is already a lot better than for 4337). I do not see it as beneficial to create a “new” language for wallets, right now. It feels like loosing focus. We first should figure out standards we can align on for smart contract wallets.
We see this with the current wallet connect migration, that smart contract wallets are not top of the mind in most flows. Creating standards that are being adapted (also by existing ecosystem players) therefore would be first priority IMO.”
Vitalik Buterin:
“I think my goal is just minimizing the number of lines of code being written
As every line of code is a security bug risk”
Richard | Co-Founder @ Safe:
“That is fair, but I would argue that this is currently not the biggest challenge when writing a smart contract wallet.”
Vitalik Buterin:
“hmm what do you mean
what is the biggest challenge?”
Richard | Co-Founder @ Safe:
“I.e. for 4337 it is not even possible to easily test them in a local environment (i.e. unit tests). You need to spin up docker images and bundlers and so on. So first creating tooling similar to what exists for normals smart contract development would have higher priority.”
Vitalik Buterin:
“right but I feel like we don’t *want* to have lots of teams independently writing complex wallet codewe want to maximize total reuse
and failing that, maximize partial reuse”
Richard | Co-Founder @ Safe:
“I don’t think the complexity lies in the wallet code itself, but rather how to extend them. To create a DSL around it is first necessary to create some alignment here (i.e. what 6900 is doing).
Then we could use a DSL to make it easier to facilitate this flexibility. But for me maximizing on tooling first is more important then creating a new DSL right now.
as a DSL would build on top of this tooling
Also a DSL for security reasons is also just a tradeoff not a mitigation, right? For me it is a similar case as the Solidity Optimizer. It is an additional processing step and any bug in it would affect all contracts using it. Additionally it is not easy to understand all the details of the transformations of the optimizer. That is actually also the reason why we heard from multiple auditing companies that enabling the optimizer should only be done if really necessary. A similar argumentation could be taken for a DSL.
For me once standards are established (multiple teams are collaborating on this right now) and the tooling landscape (including testing) is properly setup, then looking for ways to make this easier accessible and creating frameworks (i.e. DSLs) around them make sense for me.”
Source: The Telegram 4337 Mafia group
Get In Touch:
Website | Twitter | Discord | Github | Telegram
Powered by Etherspot
BUIDLer React Component | TransactionKit | Pillar Wallet | AirdropMe