Full Report
Web3 has three key steps that almost every serious project does: write good tests, get audits/contests on the codebase, and start a bug bounty program. This has substantially reduced the number of vulnerabilities in recent years. Every once in a while, one of these projects with a significant bug bounty program gets hacked. Yearn and BalancerV2 are great examples of this. They are battle-tested and have large bounties. How can we prevent this from happening? Some folks suggest that higher bounties would have protected the protocols. The blog post dives into why this isn't the case. At times, a bad actor will return the funds but keep a small portion, like 10%. There's a difference between the total value locked (TVL) and the treasury. TVL is usually user funds, and treasury is protocol funds. The protocol has legal authority to spend funds from the treasury but not the TVL. Unfortunately, the risk scales with TVL, but the security budget doesn't; the amount of funds at risk doesn't directly correlate with how much a protocol can pay out because they don't own the money themselves. The second issue is around capital efficiency. How do we allocate funds for a bug bounty program? Raising the bounty makes it inefficient because this money will just sit around. Protocols would need to keep this on hand in case of a critical vulnerability, instead of using the money on other things, like more audits. Raising the bounty creates a perverted relationship between the whitehat and the protocol. If there's a horrible vulnerability at launch that is unlikely to be duplicated, then the whitehat is incentivized to hold onto the bug until there's a lot of TVL at risk to maximize their bounty. Whitehats that do this full-time are unlikely to look at very battle-tested code because the rate of return is very low. There's really no dollar amount that would make this effort worthwhile. So, what can we do? Reaudits. Get the code looked at again and again. In other industries, audits are conducted annually to ensure compliance. So, why not do that here as well? Having a bug bounty program is part of the process. But, raising it from $5M to 10% of funds at risk wouldn't have the positive effect that people think it would. Overall, a great article on the state of security in crypto.
Analysis Summary
# Best Practices: Continuous Security & Re-Audit Cycles
## Overview
These practices address the limitations of passive security measures (like bug bounties) in the Web3 ecosystem. The goal is to shift security from a "one-and-done" pre-deployment event to an active, continuous process that accounts for evolving threats, TVL (Total Value Locked) growth, and environmental changes.
## Key Recommendations
### Immediate Actions
1. **Baseline Audit Review:** Verify the date and scope of your last smart contract audit. If the report is older than 12 months or was conducted prior to significant TVL growth, mark it as "Expired."
2. **Treasury vs. TVL Assessment:** Formally define the "bug bounty pool" within the protocol treasury. Never price bug bounties based on a percentage of TVL that the protocol does not legally own or control.
3. **Establish a Bug Bounty Program:** If not already present, launch a program on a reputable platform to provide a responsible disclosure channel for freelance researchers.
### Short-term Improvements (1-3 months)
1. **Implement Re-audit Schedules:** Move away from "event-driven" security (auditing only during launches) to "time-driven" security. Schedule a comprehensive re-audit of the current live deployment.
2. **Environment Audit:** Beyond the core code, audit configuration settings, administrative roles (multisigs), and external dependencies that may have changed since deployment.
3. **Incentive Alignment:** Structure bug bounty rewards to be competitive but fixed (e.g., $250k–$500k for criticals) rather than a percentage of TVL, to avoid incentivizing "bug hoarding."
### Long-term Strategy (3+ months)
1. **Annual Compliance Cycle:** Adopt an industry-standard annual audit cycle (similar to SOC 2 or PCI DSS). Treat an audit report as a "point-in-time" certificate with an expiration date.
2. **Continuous Competitive Reviews:** Regularly engage different audit firms or host security contests to ensure "fresh eyes" look at the codebase from different angles.
3. **Security Budgeting:** Allocate a percentage of protocol revenue or treasury specifically for proactive re-audits rather than letting capital sit idle in massive, passive bug bounty reserves.
## Implementation Guidance
### For Small Organizations
- **Focus:** High-quality initial audits + Bug Bounty.
- **Action:** Use competitive security contests to get maximum eyes on code for a fixed cost. Prioritize unit testing and automated scanning to catch "low-hanging fruit."
### For Medium Organizations
- **Focus:** Strategic re-audits + Controlled Bounties.
- **Action:** Transition to annual re-audits. Ensure the bounty is high enough to be respected but low enough to remain capital-efficient.
### For Large Enterprises / High-TVL Protocols
- **Focus:** Continuous Security Operations.
- **Action:** Establish a "Security-in-Depth" model. This includes annual re-audits, perpetual bug bounties, and specialized reviews focusing on infrastructure, private key management, and cross-chain dependencies.
## Configuration Examples
While specific code is not provided, the following configuration "best practices" are implied:
* **Version Control:** Pin dependencies to specific versions; do not use floating versions that could introduce un-audited breaking changes.
* **Access Control:** Regularly audit the list of addresses with `OWNER` or `ADMIN` roles.
* **State Monitoring:** Implement real-time monitoring to alert on configuration changes (e.g., fee changes, logic upgrades) that deviate from audited states.
## Compliance Alignment
* **SOC 2 Type II:** For operational security and internal controls.
* **PCI DSS:** For protocols handling sensitive payment or user data.
* **NIST Cybersecurity Framework:** Specifically the "Protect" and "Detect" functions via continuous monitoring and periodic assessments.
* **FedRAMP:** As a benchmark for high-security cloud/infrastructure standards.
## Common Pitfalls to Avoid
* **TVL Conflation:** Assuming protocol "security" can be funded by user deposits (TVL) during a crisis.
* **The Passive Trap:** Relying solely on a bug bounty program. Passive security relies on luck; active security (audits) relies on planning.
* **Static Thinking:** Believing that because smart contracts are immutable, their security is permanent. Environmental factors (libraries, compilers, EVM updates) change.
* **Perverted Incentives:** Scaling bounties directly with TVL, which encourages whitehats to wait for the TVL to peak before reporting a vulnerability.
## Resources
* **Bug Bounty Platforms:** [Immunefi], [HackerOne]
* **Audit Firms:** [Trail of Bits], [OpenZeppelin], [Sigma Prime]
* **Frameworks:** [ConsenSys Smart Contract Best Practices], [Ethereum Smart Contract Security Alliance (SCSA)]