DAO Overview
The DAO acts as a form of judgement for qualifying the status of audits. This largely dictates money movement automation, and creates a layer of security behind possible vulnerabilities in audits. The DAO is not simply a forum, it is actually core to the automated on-chain mechanisms.
As mentioned in Protocol, once audit findings are submitted, and the protocol owner locks their funds, the audit moves into a challengeable period.
This challengeable period optimistically assumes that audits are deemed as valid, unless it's voted otherwise. It's important to note that DAO participants can be anybody, even the audits or protocol owners that are part of Bevor.
Proposing
WIP.... should DAO permissions be based on some attestations? As $BVR is required to vote, we can likely distribute it to trusted parties at first, make it non-transferable, then move to some other mechanism. More to come...
The DAO is permissionless, meaning anyone can choose to participate or not. Users can make proposals stating that an audit should be invalidated due to blatant exploits or the existence of high severity vulnerabilities that could lead to loss of protocol funds.
The issue with proposals is that we don't want to expose what the vulnerability actually is. At first, we can simply use the DAO to serve as a qualification of an exploit that was acted on, which will be feasible as on-chain movement will easily verify the truth of these statements. Until we have some safeguards in place to prevent revealing of information, while still verifying the truthiness in proposals, we'll want to hold off of the DAO serving as a vulnerability uncovering proposal.
The second a proposal is made, the vesting period is "frozen", meaning payments to auditors will be delayed. Payments to auditors will accumulate, without being paid out, for the duration of a proposal + voting process.
Let's say $100,000 was initially placed in the escrow contract. The vesting period is 10 months, and it vests monthly at $10,000 per month. Right before the 6th month, a proposal was made that challenges the validity of a specific audit. The duration of this proposal is a minimum of 2 weeks, for example, which overlaps with the 6th month's vesting payout. On that 6th month, the auditor(s) do not receive payment.
However, after the 2 week voting period, it was determine that the audit was not faulty, as either a quorum was not reached, or the DAO voted against the proposal. Now, on the 7th month, the auditor(s) will receive the standard $10,000, plus the accumulated $10,000 that was retained by the escrow contract, for a total payment of $20,000. Vesting proceeds as normal.
Queue: zk-circuits, commit-reveal schemes, partnerships with companies developing AI models specific to audits
I also think that the challenge period + DAO could inherently serve as a bug bounty program. Funds should not stop vesting to auditors because of low-to-mid severity vulnerabilities. It should only stop if a vulnerability is tagged as "loss of funds possible"
Voting
DAO participants vote on proposals. In order to participiate, the DAO relies on a native $BVR token, distributed amongst users.
Quorum
A minimum threshold of turnout needs to be reached within an alotted timeframe in order for a vote to be considered valid, regardless of what the outcome of the vote tells us. Quorum is determined by some threshold of total $BVR tokens involved in the voting process for a vote, likely set as a percentage of $BVR votes to circulating supply.
Support Threshold
A minimum percent of voting power needs to be in favor of a proposal in order for it to pass. We can set this to 50% for now, and adjust accordingly. I imagine we'd want this to be quite high.
Voting Power
Voting power is proportional to a participant's $BVR at stake relative the total amount of $BVR staked for a proposal. We take a quadratic voting approach, such that each additional vote that an individual has is worth incrementally less.
Freezing of Vesting
Once a proposal is placed for an audit, the vesting period is frozen. Funds accumulate. We'll likely want to set some maximum threshold allowed for challenges on a given audit.
Rollback
If a proposal passes, this means that an audit was faulty. Vesting of payments to auditors immediately stops. Remaining payments are mostly rolled back to Protocol Owners, and the remaining proportion of funds is granted to DAO participants and the Bevor treasury.
Incentives & Payments
Bevor incentives voting amongst users. The DAO relies on game theory to balance economic incentives with participants' actual beliefs towards a proposal. As it's economically favorable for DAO participants to declare an audit as faulty, the incentive structure is as follows:
- A stake of X $BVR is required to vote NO to a proposal
- A stake of 3X $BVR is required to vote YES to a proposal
- Those who vote "correctly", aligning with the outcome of the DAO, receive a portion of the staked $BVR tokens from those who voted on the opposing side
This means it is far more expensive to vote that an audit was faulty, which has its benefits.
Note: These numbers need to be worked out, and we might outsource this to protocols who specify in best DAO practices
This leads the following ground truth scenarios.
Scenario 1: Audit is faulty
Participants who properly voted that an audit was faulty are rewarded via rollback of the escrowed funds. They are also rewarded with the X $BVR tokens staked by participants who voted NO, which is relatively small compared to the stake they placed to vote YES.
Scenario 2: Audit is not faulty
Participants who properly voted that an audit was not faulty are rewarded with the 3X $BVR tokens staked by participants who voted YES, which is significant compared to the stake required to vote NO.