samczsun: The Key to Crypto Protocol Security Lies in Proactive Re-Auditing

Bug bounty programs are passive measures, while security protection requires proactive advancement.

Written by: samczsun, Founder of Security Alliance, former Research Partner at Paradigm

There is now a consensus in the industry that cryptocurrency security protection must follow three key steps: writing test cases during the development phase to identify basic 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 vulnerabilities such as private key theft and infrastructure breaches.

However, even protocols that have undergone comprehensive audits and offer generous bug bounties still occasionally fall victim to hacker attacks. Such incidents not only affect the protocols involved but also shake the very foundation of trust in the entire ecosystem. Recent hacks of Yearn and Balancer V2, as well as security incidents involving Abracadabra and 1inch earlier this year, all demonstrate that even time-tested protocols are not absolutely secure. Could the crypto industry have avoided these attacks? Or is this simply an inevitable cost of decentralized finance?

Commentators often suggest that increasing bug bounties could have protected these protocols. But even putting aside economic realities, bug bounties are essentially passive security measures, placing the fate of protocols in the hands of white-hat hackers, while audits are proactive self-protection actions taken by protocols. Increasing bug bounties cannot prevent hacker attacks, as this is tantamount to doubling down, betting that white-hat hackers will find vulnerabilities before black-hat hackers do. If a protocol truly wants to protect itself, it must proactively conduct re-audits.

Treasury Funds and Total Value Locked (TVL)

Sometimes, hackers agree to return most of the stolen funds, keeping only a small portion (usually 10%) as a reward. Unfortunately, the industry refers to this portion as a "white-hat bounty," which raises the question: why don’t protocols simply offer the same amount through bug bounty programs to avoid the hassle of negotiation? But this thinking confuses the funds that attackers can steal with the funds that protocols can actually control.

Although on the surface, it may seem that protocols can use both types of funds for security protection, protocols only have legal control over their own treasury funds and have no right to use user-deposited funds. Users are also highly unlikely to grant such permissions in advance; only in times of crisis (for example, when depositors must choose between losing 10% or 100% of their deposits) would they allow protocols to use deposits for negotiation. In other words, risk increases in tandem with TVL, but the security budget cannot increase accordingly.

Capital Efficiency

Even if a protocol has ample funds (for example, a large treasury, strong profitability, or has already implemented a security fee policy), how to reasonably allocate these funds for security protection remains a challenge. Compared to investing in re-audits, increasing bug bounties is, at best, extremely inefficient in terms of capital, and at worst, can lead to misaligned incentives between protocols and researchers.

If bug bounties are tied to TVL, then when researchers suspect that a protocol’s TVL will grow and the probability of repeat vulnerabilities is low, they are clearly more motivated to conceal critical vulnerabilities. This ultimately puts researchers and protocols in direct opposition, harming user interests. Simply increasing critical vulnerability bounties is also unlikely to achieve the desired effect: while the pool of freelance researchers is large, very few spend most of their time on bug bounties and possess the skills needed to find vulnerabilities in complex protocols. These elite researchers will focus their time on bounty programs with the highest potential return on investment. For large, time-tested protocols, since they are assumed to be under constant scrutiny by hackers and other researchers, the probability of finding vulnerabilities is considered extremely low, so no matter how much bounty is offered, it is not enough to attract their attention.

Meanwhile, from the protocol’s perspective, bug bounties are reserved for paying out a single critical vulnerability. Unless the protocol is willing to bet that there will never be a critical vulnerability, while also concealing its liquidity status from researchers, these funds cannot be used for other purposes. Rather than passively waiting for researchers to find critical vulnerabilities, it is better to use the same amount for multiple re-audits over several years. Each review ensures the attention of top researchers and is not artificially limited to finding a single vulnerability, while also aligning the interests of researchers and protocols: if the protocol is exploited, both parties suffer reputational damage.

Existing Precedents

In the software and financial industries, annual audits are a proven and mature practice, and the best way to determine whether a company can cope with an ever-evolving threat environment. SOC 2 Type II reports are used by B2B clients to assess whether vendors maintain appropriate security controls; PCI DSS certification indicates that a company has taken proper measures to protect sensitive payment information; the U.S. government requires parties handling government information to obtain FedRAMP certification to maintain high standards of security protection.

While smart contracts themselves are immutable, their operating environments are not static. Configuration settings may change over time, dependencies may be upgraded, and code patterns once considered safe may actually pose risks. Protocol audits are assessments of security at the time of the audit, not forward-looking guarantees of future protocol security. The only way to update this assessment is to conduct a new audit.

In 2026, the crypto industry should make annual audits the fourth step in protocol security protection. Existing protocols with large TVL should conduct re-audits of their deployments; audit firms should offer specialized re-audit services focused on assessing overall deployments; and the entire ecosystem should collectively shift its perception of audit reports—they are merely assessments of security at a specific point in time, may expire, and are not permanent guarantees of safety.