Thank you for the thoughtful post, Nadav!
I generally agree with your assessment and the effort to be as surgical as possible as a means of maximizing equity for legitimate users and capital efficiency for the community treasury.
In that spirit, I describe in point 3 (below) how elements of my previous suggestion can benefit users when integrated with your revised proposal.
I believe these elements will materially benefit overall UX and allocation outcomes, which I aim to demonstrate.
I also believe it will address concerns you and @haydenadams have expressed.
For clarity, I’ll recap my understanding of your proposal along with my suggested amendment in a rough OKR format & procedural outline.
Objective:
Identify, verify, & make whole all excluded, legitimate users eligible for UNI in the most equitable, frictionless, transparent, and capital efficient manner possible.
Note: “legitimate users” is defined here as individual users utilizing projects that incorporate Uniswap for personal trading and are not engaged in arbitrage or other use cases involving enmassed EOAs.
Key results:
-
Legitimate users are identified & included in finalized Merkle root (by extension, arbitrageurs, bots, and relayers are identified & maximally excluded)
-
Code & identified addresses are independently verifiable by users
-
Legitimate, excluded users recieve UNI as though omission never occurred.
Amended process proposal:
-
Identify projects via Nadav’s aforementioned Inclusion Criteria
-
Selected projects generate lists of affected users which will be verified against historical Uniswap v1 & v2 calls as well as UNI claims list to verify eligibility. This serves as preliminary Merkle root.
-
Users are able to independently verify their address has been included in preliminary Merkle root via a search bar similar to initial Uniswap claim UI and/or a CAPTCHA enabled form where addresses may be submitted and verification of inclusion is provided on submission.
If the user’s address has been omitted, the user is additionally able to add it to a pending list via form logic for consideration and will be required to provide proof that they are not an arbitrager with 10+ wallets, while also meeting initial eligibility requirements. It is unlikely that projects with KYC would experience additional omissions but in the interest of benefitting users and mitigating future contention, I think this should be included.
I believe user verification is an important feature in this process because it:
-
Provides users trustless/transparent assurance of inclusion & a dispute resolution process in the event of another unintended omission while eliminating the external locus of control they may otherwise feel.
-
Provides projects a secondary dataset to verify against. Lists generated by projects may still be vulnerable to inefficient inclusion, just as my previously suggested claim design is, but a combination of project lists and user verification should create a highly surgical (i.e. efficient & effective) dataset of EOAs.
In the event the end-result numbers exceed the projected goal of single digit thousands, user-generated verification could prove to be a viable solution to satisfy projects’ burden of proof.
This can also create metrics such as % of user verified EOAs to objectively confirm achievement of key results, which subsequently confirm achievement of our objective.
-
Merkle root is compiled using finalized list after completion of the vetting process described in 3
-
Deploy Merkle drop contract referencing that root.
-
Initiate governance proposal to grant
approval
-
Potentially overkill option to optimize for capital efficiency:
Include claim
function in addition to aforementioned verification process for Merkle drop contract and refund unclaimed UNI to community treasury after x claim period.
This will add friction and be inherently more exclusive and labor intensive, but will have redundant verification that only active users will recieve drop.
Thank you for your consideration and I hope my perspective positively influences the outcomes of all involved.