Auditopia

!! The project is still WIP, frontend integration is pending !!

The Problem: Auditing wait times in top audit firms are 9-12 months and expensive. We need something that is more participative and allows new and yet-unproven security auditors to get more opportunities. Owing to the immutable nature of blockchain technology, it is impossible to update the code afterits deployment. Placing smart contracts without adequate audits could lead to undesirable situations like differences in the contract's intended performance, gas leakage, and more. 43% Web3 hacks in 2022 were due to contract vulnerabilities, of which 52% were not audited.

Proposed Mechanism: Step 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.

Step 2 - Pools are created: Once the contract is deployed, 2 betting pools are created. Called NoBugs and YesBugs - representing abetting pool that says there are no severe bugs in this contract v/s yes there are bugs in this contract. Pools are equally funded - The person requesting the audit must fund both the pools equally to kick start the audit.

Step 3 - 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

Step 4 - 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.

Step 5a - 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:

1. When the funder put money in the YesBugs pool(earlier you make the bet, more is your reward if true)
2. Amount put in as the bet (larger your bet that ther eare bugs, more is the reward)
3. 5% goes to the jury members equally

Step 5b - 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 5a. If the no bugs reported is the pool that won, an NFT is created with the amount of money that was liquidated to establish a certification from people on the jury.

Who will participate? 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 rallypeople to bet on NoBugs and increase the pool size ofNoBugs and produce the bug to the jury once the NoBugspool 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.

Intuitive Features:

1. No Valid Submissions, No Service Fee - If no valid vulnerabilities are identified in your protocol, you owe nothing. Pay only for results. Very feasible for budding Web3 startups looking for audits
2. Eliminating duplicate submissions - Rewards only the first unique submission, discouraging spam and redundant reports

Jury Governance:

1. Specifying some background checks for approving a user as a jury member and not allowing anyone random to do so.
2. Create a DAO which votes on approving Jury members based on their security profiles.

!! The project's frontend integration is still WIP !!

1. This project uses the Scroll Sepolia testnet for contract deployment, since the L2 chain allows for lesser fees.
2. We have created a TheGraph Subgraph in the Subgraph Studio to efficiently index and query over the events emitted by the contract. This helped us quite a bit in querying the information and fetching it from the frontend just like GraphQL Queries.
3. Chainlink VRF is used for randomly selecting any 5 jury members from the pool of verified jury members available on the platform.
4. Chainlink Services are used for programmatically adding cronjobs for every created audit - which pools some amount of money at the end of every day from YesBugs to NoBugs. At the end of 30 days, if no bug has been reported, it distributes the funds by calling the smart contract's distribution function.
5. Sismo Connect, although not completely integrated, would be used for verifying identities. We would create a DataGroup for our Sismo App to verify if a user who's wallet/vault is connected is a Jury Member or not, without actually asking for a proof.
6. TableLand has been used to store info about the jury members. TableLand did not allow foreign-key constraints as of now, but we still managed to index the jury's wallet addresses with the table in our contract.
7. We plan to add XMTP Messaging and Notification features in the future for the project