Protocol Owner

Protocol Owners are groups / people that have submitted requests for audits, or intend on doing so. As each identity is tied to a single account, a Protocol Owner can only be referenced by a single wallet address.

Submitting an Audit

Protocol Owners can easily create an audit in Bevor. The requirements for doing so are by the submitting the following:

• Name of the Audit
• Brief description of the audit
• Audit details (.md) thoroughly highlighting what exactly is needed
• Price
• Duration of vesting period
• Whitelisted auditors

The only 2 required fields are the "Name" and "Description" fields. All others can be edited upon submission, and might include defaults.

Whitelisting

Whitelisting an auditor is easy as selecting an auditor from a dropdown upon audit creation or edit. This does not guarantee they will conduct your audit, but it could at least streamline the process. For example, if you know in advance you want a specific auditor, then whitelist them. If you have some predetermined retainer agreement, whitelist them.

Locking an Audit

Immediately after creating an audit, it's still editable, and auditors can request to audit. Protocol Owners can verify or reject these requests. Whitelisting an auditor has the same effect as a protocol owner verifying a requested auditor, it just skips the step where a given auditor needs to request to audit in the first place.

The next phase is locking an audit.

The requirements for locking an audit are simply:

• Audit details have been submitted
• There is at least 1 verified auditor
• Terms have been set

Locking an audit prevents all auditors from requesting to audit your protocol. This moves you into the attestation period.

Attestation Period

During this period, protocol owners and auditors agree on terms. Terms can be the Price, Duration, or the specifics of the audit as outlined in the Details.

If a protocol owner elects to update any component of the audit, the attestations for each auditor reset. If a protocol owner removes an auditor from the audit, they reset as well.

If an auditor rejects the terms, then the protocol owner can make edits and automatically reset the attestations.

Once the audit has been fully attested to by all parties, then the actual auditing period can kick off. This requires making an on-chain transaction to lock an verifiable reference to all aspects of the audit.

Auditing Period

During this period, the auditors actually conduct the audit. When an auditor submits their findings, the findings are completely obfuscated from all parties. Once all auditors submits their findings, the protocol owner can request to view them.

Requesting to view findings requires:

• Signing an on-chain transaction
• Locking money (price of the audit) in escrow
• Declare that auditors submitted findings
• Minting an NFT to represent the audit

Once the money is in escrow, only the protocol owner can view the findings for a period of time. This prevents others from potentially acting on the uncovered vulnerabilities prior to the protocol implementing the necessary changes. Once this period of time is over, the protocol owner must post another transaction on-chain that includes the hash of the audit findings, or risk forfeiting their payment for the audit entirely.

Once these steps are taken, the audit moves into a challengeable period.

Challenges

The challenge period occurs as long as the vesting period is ongoing. If it is deemed that the audit was faulty, then Bevor DAO automates the rolling back of the remaining portion of escrowed funds to the protocol owner.

Finalized

Once the vesting period ends, the audit is in a finalized state. Now the protocol owner has a fully on-chain representation of the audit that was conducted. This can easily be showcased, and better, provably belongs to the protocol.