Before getting into the replies, I want to mention that we forgot to thank @AvsA and @James for the early feedback and iterations on this idea. We wouldn’t have the lottery system idea or the hold time cap (which was previously a time-delegated cap) without your feedback and this look much more solid now.
Also, we are changing this topic to a [TEMPERATURE CHECK] so we can start moving it forward to implementation in the near future.
We don’t have a design for the UI yet. The idea so far is to give an easy experience to delegate and keep track of the rounds, which could have the user gains included.
Increase in delegated supply, % dumped, and its delegation stickiness over the following months.
Our proposal is to pilot this first before we automate it for the longer term if it’s successful.
This should be improved for future versions in case the pilot is successful.
Our goal, from point 4.1.5 of our SPP application is to get a 30% increase. Ideally, we achieve it in this pilot.
There are many paths to muse over, but this seems the most straightforward, and also rewards the community that contributed so far. We are planning non-financial mechanisms to add to this, but this one seems like the easiest win and reasonably priced for the results it can bring.
It’s not impossible, but all of our simulations went only as far as 4 rounds of iteration, and never got even close to 20% of addresses reaching the cap. If in a scenario all addresses would reach cap, the remainder will return to the DAO treasury.
At this time there are very few holders that even touch that cap, and they are mostly active in the DAO and well known. This could indeed be exploited, but there will hardly be a big enough number of exploiters that would benefit from this without a big reputational damage.
As the user will have a chance to win, rather than a guaranteed amount, we found it better to pool up to 10 ENS to provide a more substantial reward. Also, it reduces the number of transactions to send.
We will post it ahead of time for auditing, as the execution is made by metagov stewards not our own team. There is no specific process in place right now, happy to include it to our specs, but one way or another stewards will need to review.
We are using the same indexer we use for anticapture.com/ens built with ponder.sh to track ENS’s governor, timelock and token contracts
It is not a goal of this program to increase quality of delegates, but number of holders delegating to active voters. Would love to see/help something of that sort, but it is not in the goals here.
As long as the delegate is active (voted >7 in the last 10 props), there is no biggest reward delegate, it’s all the same. We removed the differentiation to avoid that effect.
We are working on it after @Coltron.eth feedback on the call. Nothing is defined yet.
I am not even sure we should be doing this multiple times, this will depend of results, stickiness and security improvements resulting from the pilot. The way to make this onchain seems straightforward but takes way more effort, so we are leaving this tbd if we make the pilot successful.