The whitelisting event for early bonding will include an additional element of allowing the user to vote for a DAO which will receive a portion of set aside pCITADEL intended for distribution to partner DAOs. When the user deposits, they will include an additional parameter which indicates the DAO they'd like to vote for, and we need to capture this data.
We also need a way to enforce the whitelist. BADGER has already developed a bouncer system used for guarded launches and can provide that same architecture, but we will need to modify the deposit function for whitelisting events.
My proposal is to duplicate the deposit function into a whitelistDeposit function, adding in the whitelisting that we've developed at badger for guarded vaults as well as having an additional param included in the whitelistDeposit function _representative. We would have a mapping of representatives to a counter which is incremented by the payout amount. Once the whitelisting bonding period is over then we can get the values of the mapping and use that for a distribution amount of the reserved DAO amount.
Tasks:
[ ] Adapt badger bouncer to wrap around the whitelistDeposit function and utilize api.badger.com to serve the merkle proof
[ ] Duplicate the deposit function to whitelistDeposit including an additional parameter _representative
[ ] Define DAO constants in a mapping like mapping(string => uint256) public representatives;
[ ] increment the selected DAO by the payout amount like representatives[_representative] += payout after payout is made
[ ] Create dune dashboard collecting this data so it can be publicized
The whitelisting event for early bonding will include an additional element of allowing the user to vote for a DAO which will receive a portion of set aside pCITADEL intended for distribution to partner DAOs. When the user deposits, they will include an additional parameter which indicates the DAO they'd like to vote for, and we need to capture this data.
We also need a way to enforce the whitelist. BADGER has already developed a bouncer system used for guarded launches and can provide that same architecture, but we will need to modify the
depositfunction for whitelisting events.My proposal is to duplicate the
depositfunction into awhitelistDepositfunction, adding in the whitelisting that we've developed at badger for guarded vaults as well as having an additional param included in thewhitelistDepositfunction_representative. We would have a mapping of representatives to a counter which is incremented by the payout amount. Once the whitelisting bonding period is over then we can get the values of the mapping and use that for a distribution amount of the reserved DAO amount.Tasks:
whitelistDepositfunction and utilizeapi.badger.comto serve the merkle proofdepositfunction towhitelistDepositincluding an additional parameter_representativemapping(string => uint256) public representatives;representatives[_representative] += payoutafter payout is made