How to Securely Launch a DeFi Protocol After an Audit:
A Comprehensive Guide

Most new teams building Web3 protocols often overlook the fact that an audit is not a 100% guarantee of security. These teams take no additional measures to mitigate risks for their protocol’s users beyond conducting an audit, which often leads to unpleasant consequences — especially if the chosen audit provider is of low quality. In this article, we aim to highlight the options currently available in the industry that can help add extra layers of protection alongside audits and, as a result, reduce risks for your protocol’s users.

We will start from the typical state of a protocol that has undergone one or two security audits, fixed all critical vulnerabilities discovered during these audits, and increased test coverage using various mindsets. (For more details on how to create thoughtful tests using hacker, invariant, and system architect mindsets, check out this article: Mastering Effective Test Writing for Web3 Protocol Audits)

Picture this: you are mere days (or preferably weeks) away from deploying your protocol. The stage is set — you are prepared to announce on Discord and Twitter that users can begin depositing funds and earning XX% APR. Everything appears to be in place. You’ve traveled a long path: from conceptualizing the initial idea, developing an MVP, pitching to investors, assembling a team, and creating the first version of your product, to obtaining public audit reports and growing your community to over 100,000 Discord members.

Yet, a pressing thought suddenly arises: "What if $5 billion in deposits flow into the protocol immediately after launch? Is the protocol robust enough to ensure the security of user funds, allowing me to rest easy?"

This concern lingers, prompting you to consider delaying the launch to address potential vulnerabilities. If this scenario resonates with you, even partially, this article will guide you through actionable steps to enhance your protocol's security and confidently prepare it to withstand any threats.

The first thing to consider is how many audits you have conducted for your protocol. If your protocol introduces a new financial primitive that has not yet been implemented in DeFi, the recommended number of audits is no less than three. If your protocol integrates with another protocol but does not introduce a new financial primitive, then conducting two audits may be sufficient. An added advantage is engaging companies that audited the base protocol, as this can result in a higher-quality audit — provided that the same team that audited the base protocol is assigned to your audit.

The general rule for determining the number of audits your protocol needs should depend on the level and severity of risks your protocol faces (for example, the number of different types of protocols your protocol will integrate with, the cross-chain nature of your protocol, the number of functions with complex calculations, etc.). The greater the risks, the more audits you should conduct. Each case requires an appropriate number of audits. Unfortunately, these cases are not easily classified, and it’s challenging to establish universal rules for determining the number of audits. Therefore, you should consult your audit provider to understand how many audits they believe are necessary to cover most of your risks, especially the critical ones.

The rule of thumb here is not to release a single line of code that at least two developers haven’t reviewed. Even if there is currently no budget for the appropriate number of security audits, make sure that your in-house team conducts at least one cross-check of the protocol. Never deploy unaudited code, even small parts, especially in critical areas of the project. Verify deployments to prevent errors in parameters or versions.

Beyond the number of audits conducted, you should consider implementing a capped launch, where you cap the total deposit volume in your protocol during the initial phase. This approach allows you to test all use cases of your protocol “in action” while limiting risks for users.

When it comes to security, it’s always better to be overly cautious. We recommend starting with a limit equal to the future maximum bounty for white-hat hackers, effectively turning your limited launch into a live Capture the Flag (CTF) event. This type of launch can also be marketed effectively to attract security specialists. For instance, the Euler v2 protocol conducted a similar launch and described the process in detail here: Euler v2 Capture the Flag Competition.

Before deploying your protocol on the mainnet, you must launch it on a testnet and test all user flows there. A testnet deployment allows you to experiment with the “live” protocol without risking user funds and test contract (or network) updates in advance, mitigating potential future risks.
The testnet version of your protocol should always be a 100% replica of the mainnet contracts in terms of contract versions (achieving a full state copy is likely impossible). If you need to deploy a minor update to one of your contracts, always make those changes in the testnet first. This will protect you from unnecessary and preventable errors.

At this stage, you can also test the security of your frontends, having a handy testing environment for penetration testers. Even XSS vulnerabilities, which are not critical in Web2 projects, can be extremely dangerous in Web3 environments. It may be a good idea to start a bounty program for project frontends on HackerOne or a similar Web2 bounty platform.

The proper functioning of a protocol — whether it consists of multiple modules, implements cross-chain logic, or is a simple protocol based on a single contract — requires robust monitoring. To monitor your protocol, you need a service that collects all necessary metrics to determine the protocol’s current state. Additionally, you will need a service to display your protocol’s metrics in real-time and send alerts to your on-call team in case of unexpected events.

• Use tools like Prometheus for real-time metric visualization.
• For alert notifications, services like PagerDuty or similar are suitable.

It’s essential to have a dedicated team ready to respond to unexpected changes in the protocol’s state and take measures to mitigate risks for users. Prepare a list of invariants and metrics that define your protocol’s normal operations. If these metrics exceed acceptable ranges, an alert should be sent.

Examples of effective alerts include:

• Changes in multisig signers responsible for critical protocol roles.
• Reverted valid transactions sent to the protocol.
• Deviations in key invariants (e.g., discrepancies between the contract’s balance and the variable tracking all available funds).
• State changes in protocols your protocol interacts with (e.g., price oracles).

Writing invariants is a topic deserving its own article, which we may cover in our blog in the future.

To ensure that your on-call team is ready for emergencies, conduct stress tests to trigger alerts in the test environment and assess how the team reacts to each type of threat. The Seal 911 conducts stress tests for market leaders, but their methodology can be adapted to your specific case. Simulate an emergency at random intervals to evaluate your team’s response and refine internal procedures.

After addressing the above, your protocol is nearing readiness for launch. The next significant milestone in ensuring its security is registering it on a bug bounty platform. Immunefi is the most well-known platform, though others with unique features exist.

Additionally, ensure contact details for your dedicated security team are prominently placed in your documentation and GitHub repository. Strategically position these contact points wherever a potential white-hat hacker might encounter your code, enabling them to report issues quickly and reduce user risks.

Make your code easy for bounty hunters to explore by providing them with a convenient testing environment. Comment your code thoroughly to prevent misinterpretation. Ensure your protocol always has an active bounty program, even for issues outside the protocol itself — such as bugs in the compiler or blockchain nodes. In such cases, bounty hunters can often respond faster than your development team.
Communicate with bounty hunters promptly and respectfully, ensuring they continue to find your project worth their effort.

Congratulations! You are ready for a secure protocol launch, having significantly minimized risks for your users. Great job!