Thanks, @AxlVaz for the question. To clarify, this is how I understand your questions and what I’m responding to (please correct me if I misunderstood part of your question).
1. How will we purchase the ETH? (If you were referring to why we plan to purchase ETH, may I point you to our response above to OPUser’s question?)
We consider the following aspects as relevant: the frequency of swapping, the time period over which the swapping will take place and the amount swapped each time.
Concerning the frequency and time period, we plan to swap OP into ETH at regular intervals and, therefore, not all at once. As we plan to distribute the tokens over a period of 12 months, we will likely follow a monthly/bi-weekly swapping schedule. In the first months, we will swap less OP into ETH and then increase this monthly swapped amount as the user base grows.
This way, we should receive, on average, a reasonable exchange rate without exerting any significant impact on the liquidity or the price of the underlying assets.
2. How are we going to avoid the ETH being farmed in this Airdrop (e.g., programmatically draining the account of ETH)?
We consider the following aspects relevant for this question: how the ETH is distributed, who gets access to the badge allow list & airdrop, and how much ETH is exposed at a given time.
How the ETH is distributed:
Our product & engineering teams are currently looking into the trade-offs associated with either airdropping the tokens, using a relayer contract, or meta transactions, all to enable robust & easy adoption and onboarding of users. At the time of writing, we consider the airdrop to be the best approach. The event triggering an airdrop would be an address added to the badge allow list for the first time and only once per address across all badges.
Given this, we believe that beyond ensuring the safety of the technical implementation, two additional control handles exist for us: (i) Who gets access to a badge allow list & airdrop & (ii) how much ETH is exposed at a given time.
Who gets access to the badge allow list & airdrop:
During our ongoing private Beta, we are personally in touch with representatives of all DAOs using Otterspace, and using Otterspace is subject to going through our onboarding & screening. Therefore, we currently have influence on who gets access to a badge allow list as we work with them directly.
Once we open up the product and enable any DAO to start using the app, we will retain a screening process and make the airdrop subject to approval. Any DAO could use Otterspace, but in order to benefit from the Airdrop we would first need to speak to and screen the DAO representatives, to ensure that they represent the DAO that they claim. We would then only enable the airdrop for organizations that we have screened to ensure that only entities that we deem trustworthy have access to airdropped ETH. Our product is tailored towards DAO workstream leads and coordinators issuing badges. These individuals typically would know the individuals to whom they issue badges, thereby acting as a web of trust.
How much ETH is exposed at a given time:
In addition to ensuring that trustworthy DAO representatives use the badge allow list & the airdrop, we also plan to limit the exposure of ETH. The ETH will be primarily kept in the Otterspace Gnosis Safe, and the contract that controls the airdrop will be “topped up” periodically to ensure that at any given time, only the ETH amount necessary to serve the new incoming user base is in the contract and thereby exposed to potential threats.
This is the working state of our considerations on ensuring the safety and correct allocation of the token grant. We appreciate all feedback on this and will keep the Optimism community updated on our progress as we go (provided the approval of the grant).