When I made my first steps in web3, it was all about discovering new, ambitious, and disruptive protocols.

The more bizarre it seemed, the more interested I was.

Along with my weird discoveries, I learned a little more about the most famous and widely-spread community guidelines.

But there is one in particular that caught my attention: the audit checking.

• Check the audit! said cryptolover954 to me.

• How? said old me that didn’t know what an audit was.

• It’s in the docs, DYOR! replied cryptolover954.

• Do you mean the 20 pages long PDF file made by SecurityBlockSafeFundExpertChain? I replied.

• Yes… said cryptolover954, bothered.

• So the 20 pages long PDF file made by SecurityBlockSafeFundExpertChain, proves that this system is safu?

• Yes, obviously…

• How can I know that SecurityBlockSafeFundExpertChain is reliable?

• They audited other contracts…

• Which contracts?

• Go to their website for god sake…

• They could post anything on their website, how is it reliable?

• Man, idk they have a good reputation…

• A lot of trust required for a trustless system at the end…, I replied sadly

And indeed, old me was right. In order to be sure this system was safe, I had two solutions, deep reading and studying the contracts myself or fully trusting another party.

I never heard of cryptolover954 after that, but he allowed me to pinpoint one of web3’s biggest flaws: the audit checking.

Don’t misread me, auditors and audits are essential to web3, the main issue is that when you check an audit, the only way to know for sure they’re reliable is to have heard about the auditor before.

You’re going to an auditor’s website but because they own their website and their database, they can display what they want and that is why most of the time you won’t be able to trust auditors you’ve never heard of.

• Number of audits

• Projects audited

• Years of experience

These are the main metrics displayed on an auditor’s website, and the ones we have to blindly trust because it could not be possible to just go and ask every project if they did have an audit with this auditor.

We use web3 because we want transparency, openness and we want to be able to verify records easily, we don’t want to blindly trust an owned website.

So I had this crazy idea, what about having audits on-chain, this would allow any user and protocols to easily fetch a project audit and get all the necessary information that will allow to evaluate it qualitatively. But how do you provide solid data regarding audits and auditors, if auditors can just publish audits reports on a decentralized server, that doesn’t make it more decentralized.

The right way to provide a decentralized source of truth for audits is if audits are decentrally handled, meaning that every step of the audit is made through an autonomous smart contract.

An audit can only be proven real if we have sufficient elements to prove its existence. When we use an open system, we should be able to easily find its audit request, we need to be able to find its author, which smart contract addresses are concerned, and to whom it was asked. We need to be able to find its pricing, its attached dates (when was it requested, when was it delivered). We also need to be able to accurately track what the auditor did before.

And more importantly, we need to be sure that this data is reliable. And as stated just a few lines above, “It’s not about pushing data onto chains but rather having data as a result of transactions.”, what it means is that getting this data decentralized should be a consequence of clients’ and auditors’ actions dealing with each other.

Neither auditors nor clients should think about data, they should just be using a platform that allows them to make deals throughout a decentralized system.

So, was what cryptolover954 implied right, should we just trust reputation by word-of-mouth?

Fortunately, no.

When it all became clearer I started working on the topic and doing researches on my own, to understand how requesting and delivering an audit work.

And I came to the conclusion that using a decentralized system could really improve the way clients and auditors work together.

After doing my interviews with dozens of auditors, I was able to design a flow that offers guarantees to the auditor and the client. I built an autonomous and decentralized system that didn’t need middlemen, or supervision to work.

On Trustblock, every critical action surrounding the audit is decentrally made. Every wallet can register as an auditor by minting themself an auditor smart contract. This auditor smart contract is owned by its minter, it contains some information about the auditor and can receive audit requests.

When a client requests request an audit (through an auditor smart contract with his wallet), an audit smart contract will be minted.

💡 What’s interesting here is that you can easily trace back an auditor’s history by going through its smart contract. You can do this manually, automatically, or embed logic inside your own smart contracts.

An audit smart contract contains white paper(s), a website URL, a logo, short description. If the client has already deployed his smart contracts, he can attach them to the request by providing their addresses, and so the auditor will conduct a review from the ones deployed on the mainnet. If the client has not deployed his smart contracts yet, they will have to provide sufficient material to the auditors for them to perform their review.

💡 On the Trustblock’s web app, the client can connect his github repository, and the auditor can make his review in-app. We introduced the system in our short introduction video (~4min): https://www.youtube.com/watch?v=0Qfw6INQwN8

An audit smart contract is not owned by its client or its auditor, as you will see further reading, they can only execute specific actions at specific given times.

💡 Everyone can easily get all the relevant information of an audit by going through its contract. Most importantly they can rely on this data because what is recorded is linked to real actions made by either the client or the auditor. What’s also interesting is that directly from within an audit smart contract you can find its client and its auditor.

Once the audit smart contract is minted, the client can only wait for the auditor’s reply. To answer this request, the auditor will be submitting a proposal through a transaction emitted on the audit smart contract. This proposal contains:

• a price (in USDC) ⇒ Pricing of the audit.

• an acceptance date ⇒ deadline for the client to accept the proposal and start the audit.

• and a delivery date ⇒ deadline for the auditor to deliver the audit.

To accept this proposal, the client will have to deposit the USDCs inside the audit smart contract, before the acceptance date.

If the audit is not delivered before the delivery date the client will be either able to withdraw their funds thus canceling the request or wait for the auditor’s delivery if they trust them on the delivery.

I know some auditors might already be worried about the pricing and the deadline estimation. Sometimes projects can take a longer or shorter time to be audited and the prices and deadlines could be adjusted. Our system is robust and flexible, and so these parameters can be modified afterward if the client agrees to it, I’ll come back to this later.

💡 This system offers a guarantee of delivery to the client and a payment guarantee to the auditor for the work they deliver. Consequentially, clients can easily request an auditor they don’t know, and an auditor can easily work with a client. Moreover, people are able to verify if there really is an “audit in progress”. Often enough I saw projects saying they didn’t have sufficient funds to pay for an audit, and the community had to rely on their sayings. Unfortunately, sometimes projects are not being audited, not because they don’t have the funds but because they want to hide malicious behaviors, an auditor could have brought light on. Now project members can earn their community’s trust by sharing their audit smart contract proving there’s really an audit going on, an auditor working with them. In the event it was too expensive, community members can check the proposal submitted by the auditor themselves.

So when the proposal is accepted by the client, the USDCs are locked inside the audit smart contract until the audit is delivered.

The auditor can make his review and help the team make their contracts safe for release.

They can also edit the initial proposal, by making a proposal update. They can change the price and/or the delivery date but once this update is submitted, the audit smart contract is frozen until the client either accepts or rejects it.

If the client accepts the proposal update, extra USDCs will be sent to the contract if the price went higher, or sent back to the client’s wallet if the price went lower. If the delivery date was postponed, then the auditors will have until the new one to deliver the audit, and the client will not be able to withdraw its funds until it’s reached.

💡 Just a little reminder, to let you know all of these steps are decentralized and so they happen through transactions sent by the auditor’s and/or the client’s wallets on the audit smart contract 😇.

Once the review is done by the auditor, the client can deploy their smart contract(s) to the mainnet, and bind the deployed addresses to the audit smart contract. This is done through a contracts update, and similarly to the proposal update it has to be agreed by both parties, the audit smart contract is frozen until the auditor either accepts or rejects it.

This allows the auditor to check if the contracts he audited are the same as the ones deployed on the mainnet provided by the client. Once accepted by the auditor the smart contracts are attached to te audit smart contract .

Trustblock enables the search for audits opened to the public (users/protocols) once the smart contracts’ addresses are attached to the audit smart contract. Because some clients care to keep privacy and make a public announcement for their audit, we are adding a private mode, which allows clients to decide when they think announcing they had an audit is a good time.

💡 As you can see once again, clients and auditors don’t own the audit smart contract. Instead it provides them with a safe and fair way to deal with each other. The system is agnostic enough so it can be used by any kind of auditor and any kind of client.

Once the deployed smart contracts are effectively attached to the audit smart contract, the auditor can finally deliver the audit.

The auditor will receive the USDCs locked inside the audit smart contract, and it will become what we call a Proof of Audit. It’s not owned, non-interactive, immutable, thus making it a reliable source because it inherits from all real actions conducted by the auditor and the client. All the history is recorded on-chain, and so every data is verifiable and proven.

💡 We reached what we wanted: to have a reliable decentralized source for audits. This source is not owned by the auditor, nor the client, nor Trustblock, it feeds entirely on what actions were made by the client and the auditor, and so the data recorded on-chain is therefore relevant.

The first major benefit is giving access to users and systems a reliable, transparent, and open source of audits. Below is a non-exhaustive list of what information they can retrieve:

• When was the audit requested?

• When was it delivered?

• Who requested it?

• Which auditor delivered it?

• What did the auditor work on before?

• What were the addresses audited?

By just knowing the smart contract(s)’ address(es) everyone can access the audit smart contract.

It also unlocks scalability and decentralized gateways for DAOs. Governance can submit a vote to enable an audit request and payment all of that from within smart contracts directly, the project teams don’t have to manually and centrally pay the audit, they also don’t have to search, fact-check, and provide information regarding an auditor, instead, everything can be found on our app or on audit and auditor smart contract transactions’ history directly.

What’s also amazing is that because we have access to a full history we can display on our app real metrics calculated upon past transactions on an auditor’s profile. This makes it way easier for clients to pick an auditor because they have way more reliable information to make their opinion.

We believe Trustblock’s system unleashes lots of possibilities, we already have hints on what could be built upon, but we care to let the decentralized world and its never-stopping creativity find ideas on its own.

As some may have already guessed, there’s a low entry barrier to becoming an auditor, so we added an on-chain certification to the auditor’s smart contract. This certification is a high-level filter that allows clients to be sure they can easily identify and pick qualified auditors. But it’s also useful for the users and protocols as they can apply this filter on the platform or directly in their smart contracts to check only audits done by certified auditors. We want to let some respected ethereum security institutions give this certification, as they are objectively the most qualified for the job.

💡 This is the only “centralized” side of the system, our goal though is to make it decentralized and we already have solid plans to do so but we will only be able to achieve this when our community will be more mature and educated. We personally think launching a DAO day 1 can be pretty dangerous for a project, especially when it relates to security topics. DAO is our number 1 goal but it still needs some time to be properly achieved because we want to be sure to empower/reward the most involved users in the future.

It’s not perfect yet, but the backers (fabric.vc, frst.vc) and I think Trustblock drastically improve today’s state-of-the-art.

Our next big topics are:

• Vesting payment systems

• Decentralized dispute resolution for litigations

We already found some potential solutions but they will only be added when Trustblock will become a fully decentralized autonomous organization. I’m always happy to answer questions and hear new suggestions from our community, so come and chat with us on Discord. You can also follow us on Twitter to know what’s going on.

If you are interested, feel free to play with the testnet app and check our documentation for a more detailed flow.