The idea with ERC 4337 is to have a public decentralized mempool that serves all contract wallets, so that centralized relayers are no longer used. If you rely on your own relayer, your users could be censored by someone DoSing it, or by legal action forcing you to censor a specific user or a specific destination (e.g. any user attempting to use TornadoCash).
You probably don’t maintain an Ethereum node which your users must use, and they’re free to use any node. For the same reason, they shouldn’t have to use a specific relayer to interact with their wallet.
We are aware of this and we are planning on supporting 4337 once the infrastructure is in place. We’re also in touch with Kristof who co-authored ERC4337 so we can see if it’s possible to modify/extend it so that already deployed immutable wallets can support, rather than having to migrate users to add the extra function
Only the relayer is not open-source at the moment. But it’s important to note that you can use Ambire without the Relayer, but you won’t have stablecoin fee payments.
The mobile apps will be open-source
We seriously aimed for 420,069 but guys at Rainbow were faster… Seriously, we thought about few different incentives:
Incentive for “discovering” Optimism on Ambire
Incentive for swapping
Incentive for holding
Incentive for developers
With acquisition of new users we aimed at up to $30 acquisition cost per user; incentives for swapping are meant to encourage people to diversify their portfolio on Optimism; incentives for holding were calculated so that they are lucrative enough for users to hold; incentives for developers are ~ up to $2000 per integration which should be enough to cover development and marketing costs ( shout outs, announcements, co-marketing with developers).
We read that shorter periods are preferred when applying for OP grants, so we tried to fit most of the incentives in 3 months. However, we agree that 6 months periods increase chances to meet the targets and create sustainable traction. We are willing to change periods to 6 months for all incentives.
At first glance it seems like adding the required functionality to Identity is not too complicated. However, wrapping the deployed wallet with 4337 functionality will be more challenging since your fallback function doesn’t implement external “fallback handlers”. Gnosis Safe was able to add the functionality through wrapping, but adding a module and a fallback handler that implements the validation function. Without this, it can be a challenge.
IMHO this increases the urgency of adding at least a stub for future support, so less users will need to migrate.
If the relayer is just for stablecoin payments, how are ETH gas payments handled without it? Doesn’t it require the user to maintain an additional funded EOA and act as a self-relayer?
Adding the function to Identity would be easy but as you’ve figured out we cannot add it for existing users without a migration. We will consider a Safe-like approach but generally we avoid fallback function modules for simplicity and security reasons (eg an exception or extra gas usage in the fallback function would render the wallet unable to receive ETH)
Indeed, you need to have an EOA funded with ETH and you act as a self-relayer in relayerless mode.
Generally, we believe the dependence on a proprietary relayer to be an important issue to solve but not the biggest blocker for smart wallet adoption, which would currently be the fact that many web3 applications do not implement EIP1271. To address this we are working on a pull request to ethers.js to add a built-in function for message validation that is EIP1271 compliant
Indeed, not the biggest blocker, but censorship resistance can suddenly become important when you least expect it, and then you need it the most. We’d like to solve it for everyone well before it becomes an issue.
I hope that any functionality in your relayer can be implemented as an ERC-4337 paymaster. E.g. pay gas with a stablecoin is possible. If you have any functionality that cannot be addressed with the current design, we’d like to learn about it and see how we best serve your wallet.
Definitely, that’s the biggest adoption blocker. It’s great that you’re working on a PR for ethers.js for this. One thing to keep in mind when implementing this, is to check for EIP1271 before checking the signature. Right now the order doesn’t matter but we’re working on an EIP to add code to existing accounts. When EOA can be converted to a contract, it’s important to invalidate its old ECDSA key. Hence, if the account has code, the module should refrain from ecrecover.
No one has yet completely eradicated sybil exploits and probably neither will we, but we believe that we can mitigate it to some extent:
We won’t limit people to claim only once per account, but introduce a conscious multimple claims during a longer period. This will probably incentivize people to use the accounts over time and stick to them. This will be combined with:
If you know that you will get even more OP if you use the wallet often, you will probably try to optimize how you are using it and invest your time to create the optimal allocation of your funds.
This doesn’t mean there won’t be any wash trading or sybillers, but being a wallet we believe that we are in a good position to have people stick to one account and get more OP on one place instead of wasting time to create more accounts.
Of course additionally we can analyze on-chain activity and make it harder for wallets to be eligible for OP incentives - set minimum amount of transactions to be made or detect if wallets are just moving the same tokens between each other to simulate activity.
What all three have in common is that they mean to incentivize wallet users to use Optimism (with the given wallet) and perform some special actions like swapping tokens or holding OP for a specific period of time.
However, all of them lack detailed plans on how they are supposed to distribute funds to the users. The Rainbow team mentioned that they are already working with some people from Optimism Foundation in order to come up with some incentive structure.
I believe that all wallets should have the same incentives structure or at least that their incentive structures should not be competitive - it wouldn’t make sense for Optimism to pay more for swapping tokens in one wallet than in another wallet (of course each wallet is free to additionally reward users for those actions apart from OP rewards). Moreover, Rainbow proposal introduces KPI milestone that needs to be achieved before releasing additional funds (only 30% of the requested amount is released upfront), I believe that the other proposals should also include similar KPI requirements. Given that I believe that a common incentive structure should be obtained before proceeding further with such proposals.
Furthermore, both TallyHo and Ambire proposals include using ~25% of the allocated funds in order to incentivize dApp developers to integrate with their wallets. I believe this part of the proposal should be excluded to a separate one so that community would be able to decide if OP should directly fund this (as this benefits more the wallet itself and not OP ecosystem) and those grants if separated would be substantial by themselves (~100k OP). To be clear - I’m not against OP funding this, just would like to see it separated from the grants to incentivize using Optimism with the given wallet (also to be able to compare those grants as apples to apples).
Moreover, it might be worth considering making sure that OP is not rewarding the same wallet for using Optimism across different wallets. Right now it feels like overkill to me, but from OP perspective it’s quite possible that a single user will farm OP rewards for the same Optimism activity in every wallet with an incentive structure (yet I’m not sure if that’s necessarily bad).
To summarise, what I propose would be to:
Separate wallet integration into separate proposals.
Streamline the work on incentive structure between Rainbow, Tally Ho, and Ambire to have a common incentive schema between wallets (or at least make sure that common parts between wallets are not competitive).
Wait before proceeding with any additional grants related to incentivizing using Optimism in wallets until the common incentive structure is obtained.
Of course, in order for this plan to work it would be necessary to effectively work on the common incentive structure, but each of the projects needs to figure it out before implementing anything anyway, so it seems like a good milestone whatsoever.
I’ve posted a similar comment in the other mentioned thread.
About the developer grants - yes, they might have more obvious benefit for Ambire/the wallet, but overall a wider adoption of these dapps in wallets means wider adoption of Optimism as well, because users will have more things they can do on Optimism, so I don’t think that’s bad. However, we are okay to separate those two types of grants from the rest as another proposal.
About the common incentive schema between wallets - By no means we want to compete with other wallets solely by the amount of OP distributed to users. We believe that competition should be on the field of user experience and features and equal compensation standard for users is a great idea in this sense.
That being said we will be very happy to work together on such schema with the Rainbow, Tally Ho and Optimism foundation teams.
It would be good to see more specific and measurable OP growth-focused plans for the grant. In its current form, this proposal seems to favour Ambire mostly.
Paying people to hold OP in your wallet is like offering staking rewards for self-custody.
We are an officially recognized Tooling Governance Committee, responsible for assessing proposals related to tooling and infrastructure (wallets, bridges etc.).
2- About the project
Ambire is an open-source smart wallet that has Optimism support since May 2022.
3- About the following
The proposal was published on October 25th asking for 425k OP tokens.
As a Tooling committee, the project was recently catalogued as “Tooling” in the Grant category, and so we’ve taken on the responsibility of issuing a recommendation.
4- About the proposal valuation
Added value (good to bad): average. Ambire is an opensource and really interesting project. But the added value to optimism is small since the incentives are mostly to using Ambire in optimism.
Impact or expected usage (high to low): medium. Ambire is free to use and all optimism users can try it. The proposal would probably increase Ambire usage in optimism but not sure if this will help Optimism itself in some way.
Current Status [Development stage/Open Source?] (early to ready): ready. The wallet is ready and
Expenditure plan and distribution (appropriate to inappropriate): reasonable. The incentivization distribution plan is reasonable though there is very strong sybil concerns.
Amount requested (high to low): medium. The requested amount is reasonable compared to other projects but bordering on the high side. The fact that they are willing to start a governance proposal to introduce matching with their $WALLET token is favorable.
5. KPIs and impact tracking
It would probably make sense to have a dune dashboard or some other kind of way to track how many users bridged to Optimism to use Ambire and how many devs built on Ambire compatible dapps, how many users held $OP for the duration of the incentives program (and how many dumped right afterwards).
6- FINAL RECOMMENDATION: Abstain
The final recommendation comes from the fact, that as has been pointed out on the forum - there are many proposals approaching user incentivisation using OP rewards, but there is no common framework for user rewards structure across different projects. It would be unfair if the reward structure differed between projects, so we suggest delaying any further grants toward user incentivisation in wallets until such a framework is formed. After that, each wallet asking for a grant toward user incentivisation should follow this framework of rewards structure.
Furthermore, we recommend separating the work for integrating the wallet with specific dapps into another proposal, so that this aspect can be voted separately.
Once that’s done we would be more inclined to suggest a yes.
I voted abstain on this proposal consistent with the Tooling committee recommendation. I like that this is an open source wallet but I didn’t have a strong enough conviction to go against the committee recommendation and vote yes on this proposal (whereas I have worked with a Tally Ho team member on a prior project so there was significantly more for me to go off of in their wallet proposal).