:fire: Optimistic Ambire OP Incentive Proposal :fire:
Project name: Ambire Wallet
Author name and contact info (please provide a reliable point of contact for the project): Ivan Manchev, vanzoo.eth on Twitter, ivan@ambire.com
I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant: Yes
L 2 recipient address: 0 xa 07 D 75 aacEFd 11 b 425 AF 7181958 F 0 F 85 c 312 f 143
Which Voting Cycle are you applying for?: Cycle 8
Grant category: Tooling
Is this proposal applicable to a specific committee? (If so, please link to committee): Yes. This falls under the Optimism Tooling/Infrastructure Committee - [DRAFT] S 02 Committee Proposal: Tooling Governance Committee 5
Project description (please explain how your project works):
Ambire wallet is an open-source smart wallet focusing on security and UX. Fully self-custodial, it offers custom dApp interaction and gas optimisation solutions, features email/pass access, upgradable security (including multisig) and native swap, cross-chain and earning functions. Community ownership and governance is ensured through a native token.
Project links:
Website: https://www.ambire.com/
Twitter: https://twitter.com/AmbireWallet
Ambire GitHub: https://github.com/AmbireTech
Discord/Discourse/Community: https://discord.gg/nMBGJsb
The Ambire Blog: https://blog.ambire.com/
Ambire Wallet Whitepaper: https://ambire.notion.site/Ambire-Wallet-Whitepaper-d 502 e 54 caf 584 fe 7 a 67 f 9 b 0 a 018 cd 10 f
Ambire FAQ: https://help.ambire.com/hc/en-us/categories/ 4404980091538 -Ambire-Wallet
Ambire Security Model: https://gist.github.com/Ivshti/fe 86 f 13 c 3 adff 3404 a 1 f 5 ce 1 e 364304 c
Additional team member info (please link): Check Team Members here.
Please link to any previous projects the team has meaningfully contributed to: Before Ambire Wallet, the Ambire team developed AdEx Network, the first decentralized ad network built on Ethereum and the biggest payment channels network on Ethereum.
Relevant usage metrics (TVL, transactions, volume, unique addresses, etc. Optimism metrics preferred; please link to public sources such as Dune Analytics, etc.):
Currently there are more than 92 , 000 registered wallets, 12 , 000 of which hold funds. Most used chains on Ambire are Ethereum, Polygon and BSC. At the moment Ambire wallets volume on Optimism is modest, but it has a good potential, so an OP incentive will help us promote Optimism among Ambire users and increase Optimism TVL.
stats- 11283 × 238 19 . 1 KB
stats- 21824 × 338 76 . 6 KB
Competitors, peers, or similar projects (please link):
Smart contract wallets:
Safe (focused more on company multisigs rather than individuals, peers)
Argent (not available on Optimism)
EOA wallets:
Rainbow
Metamask
TallyHo
Is/will this project be open sourced? Yes, all major components are open-sourced already
Optimism native?: EVM native
Date of deployment/expected deployment on Optimism: May 13 th, 2022 (Announcement)
Ecosystem Value Proposition:
What is the problem statement this proposal hopes to solve for the Optimism ecosystem?
The EVM ecosystem, including Optimism has always been particularly challenging to build a wallet for, due to a few underlying characteristics that ultimately lead to user inconveniences:
It’s complicated to create a wallet and learn the importance of protecting a seed phrase; this requires 5 x more time than creating an account on any web 2 app.
Most desktop wallets require installing an extension, which is a not a natural flow for web 2 users.
Multiple transactions needed to deposit into DeFi protocols, stuck transactions due to gas fees; you also need ETH or the chain’s native currency to transact.
Generally bad and overcomplicated UX - most wallets don’t parse transaction data in human readable way which paves a way for scams, social engineering attacks and user errors.
How does your proposal offer a value proposition solving the above problem?
desktop 1903 × 968 127 KB
Ambire Wallet is an open-source smart contract wallet and has been built with security and ease of use in mind. It is designed to satisfy and improve the user experience of both newcomers and degens in ways impossible for existing EOA wallets.
Ambire Wallet started as a web app, but soon native iOS and Android apps will be released, together with Chrome extension. The web app is mobile-friendly and 100 % usable on mobile browse.
Some of Ambire’s game-changing features:
Sign up with an email/password without compromising the self-custodial nature of Ambire Wallet (*how it works*);
Paying transaction fees in stablecoins;
Transaction preview: before signing a transaction, we show a human-friendly description of what it does, step by step;
Automatic transaction fee management, automatic front-running/sandwiching protection via Flashbots;
Transaction batching: ability to do multiple actions in one transaction (e.g. combining token approval and swap on Uniswap in the same transaction, instead of signing two);
Multiple signers (keys) can be used to control the same account: e.g. a hardware wallet (Trezor, Ledger and Grid+ Lattice 1 support) AND a software wallet; those can be easily enabled or disabled;
Connect to any dApp through WalletConnect, built-in dApp plugin system for a secure and faster connection with a curated set of dApps (new ones being added gradually);
Available on Optimism and 11 more EVM chains, built-in cross-chain aggregator for a seamless transfers between L 1 and L 2 .
You can create a wallet with email and password only, or if you prefer use hardware wallet or Metamask as a signer:
login 1073 × 749 230 KB
Find the best routes for bridging between L 1 and L 2 :
routes-bridge 753 × 448 18 . 8 KB
Human-friendly transaction parsing, pay for network fees in stablecoins and other ERC- 20 tokens, automated gas management:
transaction-screen 1434 × 855 66 . 9 KB
The Ambire dApp catalog:
dapp-catalog-optimism 1908 × 969 191 KB
Why will this solution be a source of growth for the Optimism ecosystem?
Ambire Wallet is on a quest to solve important UX problems of EVM wallets that prevent wider adoption. We believe that we are very well positioned to do it with account abstraction and the benefits of smart contracts over EOAs.
The Optimism ecosystem will benefit from a wider adoption of Ambire Wallet, as it will reduce friction both for novice and experienced users, bringing UX improvements and smart wallet features that currently no other wallet solution on Optimism can offer.
Ambire’s dramatically improved UX, combined with Optimism’s high performance and scalability can pave the way to onboarding the next billion users to crypto.
Has your project previously applied for an OP grant? No
Number of OP tokens requested: 425 , 000
Did the project apply for or receive OP tokens through the Foundation Partner Fund?: No
If OP tokens were requested from the Foundation Partner Fund, what was the amount?: N/A
How much will your project match in co-incentives?: We will run a governance proposal on our end to introduce a limited-time (while OP is distributed) $WALLET multiplier for Optimism users to support the incentive.
TLDR: The $WALLET token is distributed to Ambire Wallet users based on the amount of funds they are holding in their wallets. There are several multipliers of these rewards that some users are eligible for, e.g. early users; users who transact often, etc.
We will introduce a 1 . 25 x $WALLET multiplier for users who really use Optimism often (more than 10 transactions in 30 days). The introduction of the multiplier will add $WALLET tokens to the OP allocation, so it will be an additional incentive on our side.
Proposal for token distribution:
All of the $OP allocation will be distributed as an incentive:
I. For users to explore and use Optimism with Ambire Wallet, to bridge assets to Optimism within Ambire Wallet
17 % $OP will be distributed as an incentive for users to bridge funds onto Optimism with Ambire
12 % $OP will be distributed as an incentive for users to swap on Optimism inside Ambire Wallet
23 , 5 % $OP will be distributed as an incentive for users to hold OP in their wallets instead of dumping
23 , 5 % OP will be distributed as an incentive to complete OP quests using Ambire Wallet
II. For developers to integrate Optimism-native dАpps into Ambire Wallet and direct Ambire Wallet connection
12 % OP wil be distributed as an incentive for dАpps to create Ambire dApp catalog compatible dApps
Ambire dApp catalog main page:
dapp-catalog-optimism 1908 × 969 191 KB
Lido Staking dApp loaded in the dApp catalog:
lido-dapp-catalog 1891 × 975 103 KB
12 % $OP will be distributed as an incentive for Optimism-native dApps to integrate direct Ambire connection (connect with Ambire) and skip the WalletConnect modal on Optimism, e.g. Lido (Ethereum):
walletconnect-modal 448 × 578 27 KB
Allocations and Targets
Incentive
For
OP
Allocation
Period
Target
Bridge funds
Users
75 , 000
Proportional to bridged sum (capped to prevent :whale: draining the whole allocation). Each account will be eligible for one allocation per month ( to reduce sybil).
3 months
3 , 000 addresses with bridged funds from all EVM networks to Optimism for 3 months
Swap
Users
50 , 000
Proportional to swapped sum (capped to prevent :whale: draining the whole allocation). Each account will be eligible for one allocation per month ( to reduce sybil).
3 months
Volume swapped more than $ 100 , 000
Hold
Users
100 , 000
Proportional to OP held and gradually unlocked if users hold OP in their Ambire wallets for a longer period
6 months
TVL OP held on Optimism ~ $ 1 m
OP Quests
Users
100 , 000
Reward users who complete all 18 Op quests using Ambire wallet
3 months
3 , 000 Ambire users to complete all 18 OP quests
Integrate into dApp catalog
Devs
50 , 000
Reward/incentivize developers who integrate their protocols in the Ambire dapp catalog - targeted for all native Optimism dapps
3 months
25 dApps added to the Ambire dapp catalog
Integrate direct Ambire connection
Devs
50 , 000
Incentive for Optimism-native dApps to integrate direct Ambire connection (connect with Ambire) on Optimism, e.g. Lido (Ethereum):
3 months
25 dApps with direct Ambire connection
Sybil-resistance
We will apply all standard practices like on-chain behaviour analysis to prevent sybil manipulation. Additionally we will simply try to incentivise users to stick to 1 - 2 wallets, instead of creating additional ones:
Introduce a limitation of rewards per account that still allows users to get the same reward multiple times if they continually and reasonably use the wallet on Optimism - e.g. get rewards for bridging and swapping every month
Stimulate users to hold OP in their wallets and reduce dumping of the OP tokens and incentivize long term usage of both Ambire and Optimism
Introduce $WALLET reward multipliers for frequent use of wallets on Optimism, additionally incentivizing people to stick to one wallet
Please provide any additional information that will facilitate accountability:(smart contracts addresses relevant to the proposal, relevant organizational wallet addresses, etc.)
All Ambire Wallets have the same bytecode (you can find the bytecode here) and are minimal proxies with this contract as base: 0 x 2 a 2 b 85 eb 1054 d 6 f 0 c 6 c 2 e 37 da 05 ed 3 e 5 fea 684 ef
This method of facilitating accountability is unique for Ambire Wallet and not possible with regular EOA wallets.
This post outlines a proposal for rewarding users of the Ambire Wallet on Optimism with an OP incentive. The Ambire Wallet aims to address user inconveniences in the EVM ecosystem by providing security and enhanced user experience features, like transaction preview and automatic fee management. The proposal includes a detailed breakdown of how the OP tokens will be allocated to incentivize user activities like bridging funds, swapping, holding OP tokens, completing quests, and integrating with dApps. Various measures are highlighted to prevent sybil manipulation and encourage long-term user engagement. The aim is to enhance the user experience and adoption of the Ambire Wallet on Optimism.
vanzoo: lefterisjp:
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiting per account what stops me from making as many accounts as I want?
No one has yet completely eradicated sybil exploits and probably neither will we, but we believe that we can mitigate it to some extent:
vanzoo:
Introduce a limitation of rewards per account that still allows users to get the same reward multiple times if they continually and reasonably use the wallet on Optimism - e.g. get rewards for bridging and swapping every month
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:
vanzoo:
Introduce $WALLET reward multipliers for frequent use of wallets on Optimism, additionally incentivizing people to stick to one wallet
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.
Summoning all developers with 0 . 5 % delegation to see if anyone can give their approval:
@lefter…
Summoning all developers with 0 . 5 % delegation to see if anyone can give their approval:
@lefterisjp Delegate Commitments - # 9 by lefterisjp
@ceresstation Delegate Commitments - # 33 by ceresstation
@jackanorak Delegate Commitments - # 136 by jackanorak
@krzkaczor Delegate Commitments - # 47 by krzkaczor
@david Delegate Commitments - # 7 by david
@mjs Delegate Commitments - # 53 by mjs 1
@jacob Delegate Commitments - # 57 by jacob
@yoavw Delegate Commitments - # 40 by yoavw
@pseudotheos Delegate Commitments - # 5 by pseudotheos
@DanieleSalatti Delegate Commitments - # 51 by DanieleSalatti
If you like this proposals please reply:
”I am an Optimism delegate [link to your delegate commitment] with sufficient voting power and I believe this proposal is ready to move to a vote."
I gathered every delegate commitment link so you don’t have to, it is next to your tag. Thank you for your time.
Gonna.eth: I’ll start to ask for tips for the copy/paste hahah jk, I’m glad to see others using this, I’m tempted to make the whole delegate list.
About the proposal I like it but as @kaereste said I feel all wallets should be treated equally, given the same amount, and set up the same compensations to users.
I’m tempted to even cross reference addresses to avoid the same address to get the compensation from all 3 wallets.
:fire: Optimistic Ambire OP Incentive Proposal :fire: Project name: Ambire Wallet Author name and…
:fire: Optimistic Ambire OP Incentive Proposal :fire: Project name: Ambire Wallet Author name and contact info (please provide a reliable point of contact for the project): Ivan Manchev, vanzoo.eth on Twitter 5 , ivan@ambire.com I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant: Yes L 2 recipient address: 0 xa 07 D 75 aacEFd 11 b 425 AF 7181958 F 0 F 85 c 312 f 143 Which Voting Cycle are you applying for?: Cycle 8 Grant category: Tooling Is this proposal applicable to a specific committee? (If so, please link to committee): Yes. This falls under the Optimism Tooling/Infrastructure Committee - [DRAFT] S 02 Committee Proposal: Tooling Governance Committee 5 3 Project description (please explain how your project works): Ambire wallet is an open-source smart wallet focusing on security and UX. Fully self-custodial, it offers custom dApp interaction and gas optimisation solutions, features email/pass access, upgradable security (including multisig) and native swap, cross-chain and earning functions. Community ownership and governance is ensured through a native token. Project links: Website: https://www.ambire.com/ 14 Twitter: https://twitter.com/AmbireWallet 1 Ambire GitHub: https://github.com/AmbireTech 2 Discord/Discourse/Community: https://discord.gg/nMBGJsb 1 The Ambire Blog: https://blog.ambire.com/ Ambire Wallet Whitepaper: https://ambire.notion.site/Ambire-Wallet-Whitepaper-d 502 e 54 caf 584 fe 7 a 67 f 9 b 0 a 018 cd 10 f 1 Ambire FAQ: https://help.ambire.com/hc/en-us/categories/ 4404980091538 -Ambire-Wallet Ambire Security Model: https://gist.github.com/Ivshti/fe 86 f 13 c 3 adff 3404 a 1 f 5 ce 1 e 364304 c 2 Additional team member info (please link): Check Team Members here 2 . Please link to any previous projects the team has meaningfully contributed to: Before Ambire Wallet, the Ambire team developed AdEx Network, the first decentralized ad network built on Ethereum and the biggest payment channels network on Ethereum. Relevant usage metrics (TVL, transactions, volume, unique addresses, etc. Optimism metrics preferred; please link to public sources such as Dune Analytics, etc.): Currently there are more than 92 , 000 registered wallets, 12 , 000 of which hold funds. Most used chains on Ambire are Ethereum, Polygon and BSC. At the moment Ambire wallets volume on Optimism is modest, but it has a good potential, so an OP incentive will help us promote Optimism among Ambire users and increase Optimism TVL. stats- 11283 × 238 19 . 1 KB stats- 21824 × 338 76 . 6 KB Competitors, peers, or similar projects (please link): Smart contract wallets: Safe (focused more on company multisigs rather than individuals, peers) Argent (not available on Optimism) EOA wallets: Rainbow Metamask TallyHo Is/will this project be open sourced? Yes, all major components are open-sourced already Optimism native?: EVM native Date of deployment/expected deployment on Optimism: May 13 th, 2022 (Announcement 1 ) Ecosystem Value Proposition: What is the problem statement this proposal hopes to solve for the Optimism ecosystem? The EVM ecosystem, including Optimism has always been particularly challenging to build a wallet for, due to a few underlying characteristics that ultimately lead to user inconveniences: It’s complicated to create a wallet and learn the importance of protecting a seed phrase; this requires 5 x more time than creating an account on any web 2 app. Most desktop wallets require installing an extension, which is a not a natural flow for web 2 users. Multiple transactions needed to deposit into DeFi protocols, stuck transactions due to gas fees; you also need ETH or the chain’s native currency to transact. Generally bad and overcomplicated UX - most wallets don’t parse transaction data in human readable way which paves a way for scams, social engineering attacks and user errors. How does your proposal offer a value proposition solving the above problem? desktop 1903 × 968 127 KB Ambire Wallet is an open-source 1 smart contract wallet and has been built with security and ease of use in mind. It is designed to satisfy and improve the user experience of both newcomers and degens in ways impossible for existing EOA wallets. Ambire Wallet started as a web app, but soon native iOS and Android apps will be released, together with Chrome extension. The web app is mobile-friendly and 100 % usable on mobile browse. Some of Ambire’s game-changing features: Sign up with an email/password without compromising the self-custodial nature of Ambire Wallet (*how 2 it works*); Paying transaction fees in stablecoins; Transaction preview: before signing a transaction, we show a human-friendly description of what it does, step by step; Automatic transaction fee management, automatic front-running/sandwiching protection via Flashbots; Transaction batching: ability to do multiple actions in one transaction (e.g. combining token approval and swap on Uniswap in the same transaction, instead of signing two); Multiple signers (keys) can be used to control the same account: e.g. a hardware wallet (Trezor, Ledger and Grid+ Lattice 1 support) AND a software wallet; those can be easily enabled or disabled; Connect to any dApp through WalletConnect, built-in dApp plugin system for a secure and faster connection with a curated set of dApps (new ones being added gradually); Available on Optimism and 11 more EVM chains, built-in cross-chain aggregator for a seamless transfers between L 1 and L 2 . You can create a wallet with email and password only, or if you prefer use hardware wallet or Metamask as a signer: login 1073 × 749 230 KB Find the best routes for bridging between L 1 and L 2 : routes-bridge 753 × 448 18 . 8 KB Human-friendly transaction parsing, pay for network fees in stablecoins and other ERC- 20 tokens, automated gas management: transaction-screen 1434 × 855 66 . 9 KB The Ambire dApp catalog: dapp-catalog-optimism 1908 × 969 191 KB Why will this solution be a source of growth for the Optimism ecosystem? Ambire Wallet is on a quest to solve important UX problems of EVM wallets that prevent wider adoption. We believe that we are very well positioned to do it with account abstraction and the benefits of smart contracts over EOAs. The Optimism ecosystem will benefit from a wider adoption of Ambire Wallet, as it will reduce friction both for novice and experienced users, bringing UX improvements and smart wallet features that currently no other wallet solution on Optimism can offer. Ambire’s dramatically improved UX, combined with Optimism’s high performance and scalability can pave the way to onboarding the next billion users to crypto. Has your project previously applied for an OP grant? No Number of OP tokens requested: 425 , 000 Did the project apply for or receive OP tokens through the Foundation Partner Fund?: No If OP tokens were requested from the Foundation Partner Fund, what was the amount?: N/A How much will your project match in co-incentives?: We will run a governance proposal on our end to introduce a limited-time (while OP is distributed) $WALLET multiplier for Optimism users to support the incentive. TLDR: The $WALLET token is distributed to Ambire Wallet users based on the amount of funds they are holding in their wallets. There are several multipliers of these rewards that some users are eligible for, e.g. early users; users who transact often, etc. We will introduce a 1 . 25 x $WALLET multiplier for users who really use Optimism often (more than 10 transactions in 30 days). The introduction of the multiplier will add $WALLET tokens to the OP allocation, so it will be an additional incentive on our side. Proposal for token distribution: All of the $OP allocation will be distributed as an incentive: I. For users to explore and use Optimism with Ambire Wallet, to bridge assets to Optimism within Ambire Wallet 17 % $OP will be distributed as an incentive for users to bridge funds onto Optimism with Ambire 12 % $OP will be distributed as an incentive for users to swap on Optimism inside Ambire Wallet 23 , 5 % $OP will be distributed as an incentive for users to hold OP in their wallets instead of dumping 23 , 5 % OP will be distributed as an incentive to complete OP quests using Ambire Wallet II. For developers to integrate Optimism-native dАpps into Ambire Wallet and direct Ambire Wallet connection 12 % OP wil be distributed as an incentive for dАpps to create Ambire dApp catalog compatible dApps Ambire dApp catalog main page: dapp-catalog-optimism 1908 × 969 191 KB Lido Staking dApp loaded in the dApp catalog: lido-dapp-catalog 1891 × 975 103 KB 12 % $OP will be distributed as an incentive for Optimism-native dApps to integrate direct Ambire connection (connect with Ambire) and skip the WalletConnect modal on Optimism, e.g. Lido (Ethereum): walletconnect-modal 448 × 578 27 KB Allocations and Targets Incentive For OP Allocation Period Target Bridge funds Users 75 , 000 Proportional to bridged sum (capped to prevent :whale: draining the whole allocation). Each account will be eligible for one allocation per month ( to reduce sybil). 3 months 3 , 000 addresses with bridged funds from all EVM networks to Optimism for 3 months Swap Users 50 , 000 Proportional to swapped sum (capped to prevent :whale: draining the whole allocation). Each account will be eligible for one allocation per month ( to reduce sybil). 3 months Volume swapped more than $ 100 , 000 Hold Users 100 , 000 Proportional to OP held and gradually unlocked if users hold OP in their Ambire wallets for a longer period 6 months TVL OP held on Optimism ~ $ 1 m OP Quests Users 100 , 000 Reward users who complete all 18 Op quests using Ambire wallet 3 months 3 , 000 Ambire users to complete all 18 OP quests Integrate into dApp catalog Devs 50 , 000 Reward/incentivize developers who integrate their protocols in the Ambire dapp catalog - targeted for all native Optimism dapps 3 months 25 dApps added to the Ambire dapp catalog Integrate direct Ambire connection Devs 50 , 000 Incentive for Optimism-native dApps to integrate direct Ambire connection (connect with Ambire) on Optimism, e.g. Lido (Ethereum): 3 months 25 dApps with direct Ambire connection Sybil-resistance We will apply all standard practices like on-chain behaviour analysis to prevent sybil manipulation. Additionally we will simply try to incentivise users to stick to 1 - 2 wallets, instead of creating additional ones: Introduce a limitation of rewards per account that still allows users to get the same reward multiple times if they continually and reasonably use the wallet on Optimism - e.g. get rewards for bridging and swapping every month Stimulate users to hold OP in their wallets and reduce dumping of the OP tokens and incentivize long term usage of both Ambire and Optimism Introduce $WALLET reward multipliers for frequent use of wallets on Optimism, additionally incentivizing people to stick to one wallet Please provide any additional information that will facilitate accountability:(smart contracts addresses relevant to the proposal, relevant organizational wallet addresses, etc.) All Ambire Wallets have the same bytecode (you can find the bytecode here 1 ) and are minimal proxies with this contract as base: 0 x 2 a 2 b 85 eb 1054 d 6 f 0 c 6 c 2 e 37 da 05 ed 3 e 5 fea 684 ef This method of facilitating accountability is unique for Ambire Wallet and not possible with regular EOA wallets.
vanzoo: lefterisjp:
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiting per account what stops me from making as many accounts as I want?
No one has yet completely eradicated sybil exploits and probably neither will we, but we believe that we can mitigate it to some extent:
vanzoo:
Introduce a limitation of rewards per account that still allows users to get the same reward multiple times if they continually and reasonably use the wallet on Optimism - e.g. get rewards for bridging and swapping every month
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:
vanzoo:
Introduce $WALLET reward multipliers for frequent use of wallets on Optimism, additionally incentivizing people to stick to one wallet
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.
Summoning all developers with 0 . 5 % delegation to see if anyone can give their approval: @lefter…
Summoning all developers with 0 . 5 % delegation to see if anyone can give their approval: @lefterisjp Delegate Commitments - # 9 by lefterisjp @ceresstation Delegate Commitments - # 33 by ceresstation @jackanorak Delegate Commitments - # 136 by jackanorak 1 @krzkaczor Delegate Commitments - # 47 by krzkaczor @david Delegate Commitments - # 7 by david 1 @mjs Delegate Commitments - # 53 by mjs 1 1 @jacob Delegate Commitments - # 57 by jacob @yoavw Delegate Commitments - # 40 by yoavw @pseudotheos Delegate Commitments - # 5 by pseudotheos @DanieleSalatti Delegate Commitments - # 51 by DanieleSalatti If you like this proposals please reply: ”I am an Optimism delegate [link to your delegate commitment] with sufficient voting power and I believe this proposal is ready to move to a vote." I gathered every delegate commitment link so you don’t have to, it is next to your tag. Thank you for your time.
Gonna.eth: I’ll start to ask for tips for the copy/paste hahah jk, I’m glad to see others using this, I’m tempted to make the whole delegate list.
About the proposal I like it but as @kaereste said I feel all wallets should be treated equally, given the same amount, and set up the same compensations to users.
I’m tempted to even cross reference addresses to avoid the same address to get the compensation from all 3 wallets.
I’m a delegate with enough voting power and i think this is ready for a vote!
I’m a delegate with enough voting power and i think this is ready for a vote!
I’m a delegate with enough voting power and i think this is ready for a vote!
I’m a delegate with enough voting power and i think this is ready for a vote!
This project looks amazing for helping with adoption. I look forward to see how it goes.
Best wishes
This project looks amazing for helping with adoption. I look forward to see how it goes.
Best wishes
This project looks amazing for helping with adoption. I look forward to see how it goes. Best wishes
This project looks amazing for helping with adoption. I look forward to see how it goes. Best wishes
I am an Optimism delegate [Delegate Commitments - # 40 by yoavw] with sufficient voting power and …
I am an Optimism delegate [Delegate Commitments - # 40 by yoavw] with sufficient voting power and I believe this proposal is ready to move to a vote.
@vanzoo do you plan to add ERC- 4337 account abstraction support in the near future?
vanzoo: We already support account abstractions as we’re a smart contract wallet. It’s possible to support ERC 4337 too in the future but for now it’s not needed as we use our own relayer.
I am an Optimism delegate [Delegate Commitments - # 40 by yoavw 1 ] with sufficient voting power …
I am an Optimism delegate [Delegate Commitments - # 40 by yoavw 1 ] with sufficient voting power and I believe this proposal is ready to move to a vote. @vanzoo do you plan to add ERC- 4337 account abstraction support in the near future?
vanzoo: We already support account abstractions as we’re a smart contract wallet. It’s possible to support ERC 4337 too in the future but for now it’s not needed as we use our own relayer.
We already support account abstractions as we’re a smart contract wallet. It’s possible to support …
We already support account abstractions as we’re a smart contract wallet. It’s possible to support ERC 4337 too in the future but for now it’s not needed as we use our own relayer.
We already support account abstractions as we’re a smart contract wallet. It’s possible to support …
We already support account abstractions as we’re a smart contract wallet. It’s possible to support ERC 4337 too in the future but for now it’s not needed as we use our own relayer.
vanzoo:
It’s possible to support ERC 4337 too in the future but for now it’s not needed as w…
vanzoo:
It’s possible to support ERC 4337 too in the future but for now it’s not needed as we use our own relayer.
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.
vanzoo: It’s possible to support ERC 4337 too in the future but for now it’s not needed as w…
vanzoo: It’s possible to support ERC 4337 too in the future but for now it’s not needed as we use our own relayer. 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 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 ERC 4337 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
yoavw: vanzoo:
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
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.
vanzoo:
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.
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?
We are aware of this and we are planning on supporting 4337 once the infrastructure is in place. …
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 ERC 4337 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
yoavw: vanzoo:
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
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.
vanzoo:
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.
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?
When you say most of the code is opensource what do you mean? What is not opensource? Will the new …
When you say most of the code is opensource what do you mean? What is not opensource? Will the new mobile apps you mentioned be opensource?
How did you arrive on the 425 , 000 OP tokens number? Isn’t 3 months too small a period for this amount of tokens? Wouldn’t it make sense to push it all to at least 6 months?
Only the relayer is not open-source at the moment. But it’s important to note that you can use Am…
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 :fire:
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.
yoavw: vanzoo:
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
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.
vanzoo:
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.
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?
vanzoo:
we can see if it’s possible to modify/extend it so that already deployed immutable wal…
vanzoo:
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
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.
vanzoo:
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.
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 existi…
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 web 3 applications do not implement EIP 1271 . To address this we are working on a pull request to ethers.js to add a built-in function for message validation that is EIP 1271 compliant
When you say most of the code is opensource what do you mean? What is not opensource? Will the new …
When you say most of the code is opensource what do you mean? What is not opensource? Will the new mobile apps you mentioned be opensource? How did you arrive on the 425 , 000 OP tokens number? Isn’t 3 months too small a period for this amount of tokens? Wouldn’t it make sense to push it all to at least 6 months?
vanzoo:
Generally, we believe the dependence on a proprietary relayer to be an important issue…
vanzoo:
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
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.
vanzoo:
currently be the fact that many web 3 applications do not implement EIP 1271 . To address this we are working on a pull request to ethers.js to add a built-in function for message validation that is EIP 1271 compliant
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 EIP 1271 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.
Only the relayer is not open-source at the moment. But it’s important to note that you can use Am…
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 :fire: 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.
yoavw: vanzoo:
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
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.
vanzoo:
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.
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?
vanzoo: we can see if it’s possible to modify/extend it so that already deployed immutable wal…
vanzoo: 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 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. vanzoo: 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. 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 existi…
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 web 3 applications do not implement EIP 1271 . To address this we are working on a pull request to ethers.js to add a built-in function for message validation that is EIP 1271 compliant
vanzoo: Generally, we believe the dependence on a proprietary relayer to be an important issue…
vanzoo: 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 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. vanzoo: currently be the fact that many web 3 applications do not implement EIP 1271 . To address this we are working on a pull request to ethers.js to add a built-in function for message validation that is EIP 1271 compliant 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 EIP 1271 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.
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiti…
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiting per account what stops me from making as many accounts as I want?
lefterisjp:
Regarding the sybil resistance for the incentives how do you plan to make it work?…
lefterisjp:
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiting per account what stops me from making as many accounts as I want?
No one has yet completely eradicated sybil exploits and probably neither will we, but we believe that we can mitigate it to some extent:
vanzoo:
Introduce a limitation of rewards per account that still allows users to get the same reward multiple times if they continually and reasonably use the wallet on Optimism - e.g. get rewards for bridging and swapping every month
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:
vanzoo:
Introduce $WALLET reward multipliers for frequent use of wallets on Optimism, additionally incentivizing people to stick to one wallet
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.
There are two other proposals quite similar to this one:
[Review][GF Phase 1 Proposal] Optimism…
There are two other proposals quite similar to this one:
[Review][GF Phase 1 Proposal] Optimism ? Rainbow (already passed)
[REVIEW][GF Phase 1 Proposal] Optimism ? Tally Ho - # 36 by FilterBySpam
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 (~ 100 k 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.
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiti…
Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiting per account what stops me from making as many accounts as I want?
I’ll start to ask for tips for the copy/paste hahah jk, I’m glad to see others using this, I’m temp…
I’ll start to ask for tips for the copy/paste hahah jk, I’m glad to see others using this, I’m tempted to make the whole delegate list.
About the proposal I like it but as @kaereste said I feel all wallets should be treated equally, given the same amount, and set up the same compensations to users.
I’m tempted to even cross reference addresses to avoid the same address to get the compensation from all 3 wallets.
lefterisjp: Regarding the sybil resistance for the incentives how do you plan to make it work?…
lefterisjp: Regarding the sybil resistance for the incentives how do you plan to make it work? Even with limiting per account what stops me from making as many accounts as I want? No one has yet completely eradicated sybil exploits and probably neither will we, but we believe that we can mitigate it to some extent: vanzoo: Introduce a limitation of rewards per account that still allows users to get the same reward multiple times if they continually and reasonably use the wallet on Optimism - e.g. get rewards for bridging and swapping every month 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: vanzoo: Introduce $WALLET reward multipliers for frequent use of wallets on Optimism, additionally incentivizing people to stick to one wallet 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.
Hey @kaereste & @Gonna.eth thank you for your comments - very valid points in there.
About the dev…
Hey @kaereste & @Gonna.eth thank you for your comments - very valid points in there.
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.
:fire:
There are two other proposals quite similar to this one: [Review][GF Phase 1 Proposal] Optimism…
There are two other proposals quite similar to this one: [Review][GF Phase 1 Proposal] Optimism ? Rainbow 4 (already passed) [REVIEW][GF Phase 1 Proposal] Optimism ? Tally Ho - # 36 by FilterBySpam 3 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 (~ 100 k 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.
I’ll start to ask for tips for the copy/paste hahah jk, I’m glad to see others using this, I’m temp…
I’ll start to ask for tips for the copy/paste hahah jk, I’m glad to see others using this, I’m tempted to make the whole delegate list. About the proposal I like it but as @kaereste said I feel all wallets should be treated equally, given the same amount, and set up the same compensations to users. I’m tempted to even cross reference addresses to avoid the same address to get the compensation from all 3 wallets.
Hey @kaereste & @Gonna.eth thank you for your comments - very valid points in there. About the dev…
Hey @kaereste & @Gonna.eth thank you for your comments - very valid points in there. 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. :fire:
It would be good to see more specific and measurable OP growth-focused plans for the grant. In its …
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.
1 . Presentation We are an officially recognized Tooling Governance Committee, responsible for a…
1 . Presentation 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 25 th asking for 425 k 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.
lefterisjp: The committee recommendation of the tooling committee of which I am a member is to abstain and leave it up to each delegate.
I will be voting against the proposal at this point though I am a fan of Ambire wallet. The reason is stated in the committee review.
krzkaczor:
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 strongly urge them to reapply next round taking that feedback into account and would be glad to consider the amended proposal and with the user incentivisation framework figured out.
I voted abstain on this proposal consistent with the Tooling committee recommendation. I like that …
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).
The committee recommendation of the tooling committee of which I am a member is to abstain and leav…
The committee recommendation of the tooling committee of which I am a member is to abstain and leave it up to each delegate. I will be voting against the proposal at this point though I am a fan of Ambire wallet. The reason is stated in the committee review. krzkaczor: 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 strongly urge them to reapply next round taking that feedback into account and would be glad to consider the amended proposal and with the user incentivisation framework figured out.
