updating community DAO to work with veNFTs

[souradeep-das]

The community DAO has to be updated to work with veNFTs from veBoba as the voting power (only).
By removing the usage of Boba( and xBoba) in its base form, and extending the application of veNFTs to the DAO, voting power across the ecosystem will be unanimous.
Some design decisions associated with the shift include:

1/ Update mechanism (Proxy/ fresh depl)

The current DAO contracts are proxy upgradeable, and the changes associated with this could fit in as an update to the existing contracts. But also, since the contracts don't have much dependence on past state, we could consider doing a fresh depl too

Problems with updating on the Proxy:

• currently all updates to the DAO contract have to go through the DAO, that means community voting and voting time for the update
• depending on the nature of this update - the total change might need two separate rounds of voting through the DAO - one to set the ve address, second to update the voting mech change (unless the ve contract is hardcoded, in which case it can be a single round?)
• some older unused variables such as - boba, xBoba, startBlock might stick around to maintain the storage structure

Problems with fresh deployment:

• Since, this will be a new address, we will need to check if LPs can have their 'DAO' actor updated

2/ Deciding on new proposal thresholds (and quorumVotes)

proposal threshold = amount of voting power you need to create a proposal
quorumVotes = amount of votes a proposal needs to succeed

The proposers should be the long-time ve-lockers, both of whose interests should be aligned towards the ecosystem. So a proposalThreshold line makes sense, but we have to re-adjust that number
Also, since the update to veNFTs, removes delegates and vote 'delegations' proposers have to build their voting power on their own - the threshold should not be high enough.
A new feature of "pre-committing tokens to a proposal"(to allow people to join in to create proposals) could be added in case delegations are very much need for proposing.

Similarly, depending on the number of ve lockers, and no delegations - the quorumVotes should be adjusted

3/ (informational) The tokenId (and its ve power) used to create a proposal cannot be used to vote for the same proposal again. How does this sound? we can tweak it back otherwise

Cc @bobachad

[berabuilder]

@souradeep-das what do u mean by DAO actor? If we re-deploy the DAO, will the previous votes vanish on the frontend or can we still show them?

re 2: I would say the amount of govBoba should equal 100,000 Boba like we do have right now to propose something. As of now anyone with any amount of Boba can vote on the proposals right?

re 3: sounds good

[souradeep-das]

The L1/L2 Liquidity Pool has an authorised address set (the address of the current DAO), only which can control setting the respective pool fees. calling this the 'DAO' actor
If we redeploy the DAO, we probably would have to proxy update the LPs to switch that actor?
(tagging @boyuan-chen, what do you think?)

We can still chose to show the previous proposals/votes from the previous DAO on the front-end

Re- 2, With no delegations, do you think its still same impact if we keep the proposal threshold to 100k veBoba?
And, yes right now, anyone with any amount can vote on proposals. quorumVotes is set to 1mil Boba.

[boyuan-chen]

Sure! No problem. I can update LPs.

[souradeep-das]

awesome! so, to confirm, we want to go with a fresh DAO deployment then? (over proxy update that has to go through DAO voting)

[boyuan-chen]

We definitely should go with a fresh DAO. For the frontend, we can update our subgraph so that it can display the old and new proposals.

[souradeep-das]

great!

[berabuilder]

If someone wants to propose another badger dance, they can bribe the votes right?

[souradeep-das]

yes they could chose bribe people to vote on their proposal, but the bribe mechanism has to be something separate at their discretion. we won't support doing that natively.

[souradeep-das]

Re 2/
from recent discussions, we are thinking about tweaking the threshold parameters, counting the effects of a) no delegates b) ve locks

(The following in voting-power units)
Proposal Threshold:
Min - 25k
Initial to be set - 50k
Max - 100k

Quorum Votes
To be set to - 250k