You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 awhitelistDeposit
function, adding in the whitelisting that we've developed at badger for guarded vaults as well as having an additional param included in thewhitelistDeposit
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:
whitelistDeposit
function and utilizeapi.badger.com
to serve the merkle proofdeposit
function towhitelistDeposit
including an additional parameter_representative
mapping(string => uint256) public representatives;
representatives[_representative] += payout
after payout is madeThe text was updated successfully, but these errors were encountered: