This is an idea for a relatively simple project that would open a lot of interesting possibilities for us, specifically exploring and testing the brightid solution for decentralized sybil resistance. This would be valuable for us as a way to help onboard people, create a broad, fair, and inclusive distribution process for Honey, and create the foundation for integrating more “people-centric” features into the DAO space. As an initial step, I propose we work on a “faucet” which brightid validated users can register for, the faucet can be topped up with honey, and users who participate in the process can then claim distributions from the faucet periodically.
User flow
- Users will need to verify an ethereum account using BrightID. An example of this type of account validation can be seen in production at https://ethereum.brightid.org.
- After verifying their account they must register with the faucet contract to be eligible to claim in the next period.
- During each subsequent period they must claim their distribution and register for the subsequent period. If they fail to claim a distribution they register for, they will forfeit that distribution and will essentially be back at step 2.
Technical Flow
- Faucet defines a
period
as a number of blocks, acurrentRegistry
as a mapping of accounts, and anextRegistry
as a mapping of accounts. - Users can call
claim
at any time when they do the following happens: - If this is the first time
claim
has been called during a period, thecurrentRegistry
is replaced bynextRegistry
andnextRegistry
is cleared and thedistributionAmount
for that period is calculated based on the current balance ofhoney
, arate
parameter of the Faucet (that determines the ratio of faucet funds that are distributed in a given distribution), and the total number of users registered for the period. - Checks if the user is registered to receive a distribution this period:
1. If the user is registered, the faucet releasesdistributionAmount
ofhoney
and then moves the user from the current period registry to the next period registry.
2. If the user is not registered and not already on the next period registry, they are added.
Some other thoughs
- We should consider if we can use this faucet as a means to onboard a “brand new users” who may not have a wallet or any xdai.
- We can potentially use portis and GSN to subsidize transactions via meta transactions with the faucet. If the faucet either also distributes some small amount of xdai, or we provide an option to convert some of the honey to xdai when claiming we can help users get some xdai in order to pay for transactions (enabling them to start interacting with the DAO).
- If we get the registration/faucet flow figured out, we could consider doing some other proof of concepts, like implementing quadratic conviction voting, quadratic dandelion voting, restricting participation in voting to validated users, creating a “people’s court”, creating moderation policies based on temporary/permanent bans on different types of participation.