Auditing wait times on top audit firms are 9-12 months and expensive.
We need something that is more participative and allows for new and yet-unproven security auditors.
Here I propose a decentralized audit marketplace that turns the auditing process into a prediction marketplace.
1. Select a jury
A jury is usually reputed security engineers. This jury doesn’t do the audit itself, but only signs off a reported vulnerability as a real bug.
There are 5 jury members selected for every audit. They control a 3/5 multisig that approves a detected bug once it is reported by an auditor.
They receive 5% of the total audit spend.
2. The contract is deployed for auditing
The contract must be deployed onchain so as to make the code immutable.
3. Pools are created
Once the contract is deployed, 2 betting pools are created. Called NoBugs and YesBugs - representing a betting pool that says there are no severe bugs in this contract v/s yese there are bugs in this contract.
4. Pools are equally funded
The person requesting the audit must fund both the pools equally to kick start the marketplace.
5. Auditors audit and fund pools
A security auditor looks at the deployed contract and judges whether there are bugs in this contract or not.
If they’re confident there are no severe bugs, they may add money to the NoBugs pool.
6. Money starts streaming from YesBugs to NoBugs
Till the time a bug has been reported, the money from the YesBugs pool starts streaming to NoBugs pool, such that the YesBugs pool will be exhausted in 30 days.
7a. Bug report
If a security engineer finds a bug, they may report the bug to the jury.
The jury will vote with their signature on whether the bug is a severe bug. If the jury accepts the bug to be a severe bug, the NoBugs pool is liquidated and all the money from NoBugs pool is distributed to the people who funded the YesBugs pool. This distribution happens proportional to
- When the funder put money in the YesBugs pool (earlier you make the bet, more is your reward if true)
- Amount put in as the bet (larger your bet that there are bugs, more is the reward)
- 5% goes to the jury members equally
7b. No bugs reported
If the size of NoBugs pool is greater than 95% of the summation of the pools, the NoBugs pool can be liquidated. All the people who bet that there are no bugs get rewarded by the same ratios as presented in 7a.
If the no bugs reported is the pool that won, an NFT is created with the amount of money that was liquidated and the ENS of people on the jury.
Analysis of the design
Who will be the people who participate in auditing
Security engineers who are not part of large auditing firms and are looking to prove their worth, building their reputation.
When to bet what
If the engineer has audited the contract and is highly confident that there are no bugs they’ve missed - they’ll fund the no bugs pool
If the engineer isn’t sure, it is prudent to fund the YesBugs pool for there is likely always a bug - especially in early iterations of a contract
If the engineer has found a bug, it is better to rally people to bet on NoBugs and increase the pool size of NoBugs and produce the bug to the jury once the NoBugs pool is large enough.
By rallying more people to bet on NoBugs an incentive is created for more engineers to come and find a bug in the contract. If someone else finds & reports the bug before the aforementioned security engineer, they lose the reward they could have claimed.
Looking to build?
Hit me up at @madhavanmalolan
This might not be something that can be built on a 1ETH bounty that I typically give out. But if this is something you are keen on taking up and building end to end hmu, we can work out something :)