A bug bounty program is a passive measure, whereas security protection requires proactive advancement.
By Samczsun, Founder of Security Alliance and former Research Partner at Paradigm
The industry has now reached a consensus that safeguarding cryptocurrency requires adherence to three key steps: writing test cases during development to detect fundamental errors; conducting comprehensive reviews through audits and competitions before deployment; and establishing bug bounty programs to reward researchers who responsibly disclose vulnerabilities to prevent attacks. The widespread adoption of these best practices has significantly reduced the number of on-chain vulnerabilities, forcing attackers to shift their focus to off-chain exploits such as private key theft and infrastructure breaches.
However, even protocols that have undergone thorough audits and offer substantial bug bounties still occasionally fall victim to hacking incidents. These events not only affect the compromised protocols themselves but also undermine trust across the entire ecosystem. Recent hacks targeting Yearn, Balancer V2, as well as security incidents involving Abracadabra and 1inch earlier this year, demonstrate that even battle-tested protocols are not entirely secure. Could the crypto industry have avoided these attacks? Or is this simply the inevitable cost of decentralized finance?
Commentators often suggest that increasing bug bounties could have protected these protocols. However, even setting aside economic realities, bug bounties are inherently a passive security measure, placing the fate of the protocol in the hands of white-hat hackers, whereas audits represent an active form of self-protection. Raising bug bounties cannot prevent hacking incidents, as it essentially amounts to doubling down on the bet that white-hat hackers will discover vulnerabilities before black-hat hackers. If protocols truly wish to protect themselves, they must proactively conduct re-audits.
Treasury Funds and Total Value Locked (TVL)
At times, hackers may agree to return most of the stolen funds while retaining a small portion (typically 10%) as compensation. Unfortunately, the industry refers to this retained portion as a "white-hat bounty," raising the question: why doesn’t the protocol simply offer an equivalent amount through its bug bounty program to avoid the hassle of negotiation? This reasoning conflates the funds an attacker can steal with the funds a protocol has discretion over.
Although it may appear that the protocol has access to both pools of funds for security purposes, it legally controls only its treasury funds and lacks authority over user deposits. Users are highly unlikely to grant such permissions in advance, allowing the protocol to utilize deposits for negotiations only during crises (e.g., when depositors must choose between losing 10% of their funds or 100%). In other words, risks scale with Total Value Locked (TVL), but the security budget does not increase accordingly.
Capital Efficiency
Even if a protocol possesses sufficient capital (such as having a large treasury, strong profitability, or having implemented a security fee policy), determining how to allocate these resources effectively for security remains a challenge. Compared to investing in re-audits, increasing bug bounties is, at best, a highly inefficient use of capital and, at worst, creates misaligned incentives between the protocol and researchers.
If bug bounties are tied to TVL, researchers are more incentivized to withhold critical vulnerabilities when they suspect that the protocol’s TVL will grow and the likelihood of recurring vulnerabilities is low. This ultimately pits researchers against the protocol, harming users. Simply raising the bounty for critical vulnerabilities is unlikely to achieve the desired effect: while the pool of freelance researchers is vast, only a handful dedicate significant time to bug bounties and possess the skills needed to uncover vulnerabilities in complex protocols. Elite researchers focus their efforts on projects where the expected return on investment is highest. For large, well-established protocols, which are assumed by default to be under constant scrutiny by hackers and other researchers, the perceived probability of discovering vulnerabilities is minimal. Consequently, no matter how high the bounty, it is insufficient to attract their attention.
From the perspective of protocol, a bug bounty is an amount of funds reserved for paying out for a single critical vulnerability. Unless the protocol is willing to gamble that no critical vulnerabilities will ever emerge while concealing its liquidity status from researchers, these funds cannot be repurposed for other uses. Rather than passively waiting for researchers to discover a critical vulnerability, it would be more effective to allocate the same amount toward conducting multiple re-audits over several years. Each re-audit ensures attention from top-tier researchers without artificially limiting findings to a single vulnerability and aligns the interests of researchers and the protocol: if the protocol is exploited, both parties will suffer reputational harm.
Existing Precedents
In the software and financial industries, annual maturity audits are a proven and mature practice, representing the optimal way to assess whether an enterprise can respond to evolving threat environments. SOC 2 Type II reports are used by B2B customers to evaluate whether vendors maintain appropriate security controls; PCI DSS certification indicates that a company has taken proper measures to protect sensitive payment information; meanwhile, the U.S. government requires entities handling government information to obtain FedRAMP certification to uphold high standards of security.
Although smart contracts themselves possess immutability, their operating environment is not static. Configuration settings may change over time, dependencies could be upgraded, and code patterns once considered secure might actually carry risks. A protocol audit evaluates the security posture at the time of the audit and does not constitute a forward-looking guarantee of future security. The only way to update this assessment is to conduct a new audit.
By 2026, the crypto industry should adopt annual audits as the fourth step in protocol security. Established protocols with significant TVL should undergo re-audits tailored to their deployment scenarios; auditing firms should offer specialized re-audit services focused on assessing overall deployment conditions; and the entire ecosystem should collectively shift its perception of audit reports, recognizing them as evaluations of security at a specific point in time that may expire, rather than as permanent guarantees of safety.
