samczsun: The key to secure encryption protocols lies in proactive re-auditing.

Bug bounty programs are a reactive measure, while security protection requires proactive efforts.

Original article: Higher Bug Bounties Won't Stop Hacks

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

Compiled by: Foresight News

The industry now agrees that cryptocurrency security requires three key steps: writing test cases during development to identify fundamental bugs; 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 adoption of these best practices has significantly reduced the number of on-chain vulnerabilities, forcing attackers to target off-chain vulnerabilities such as private key theft and infrastructure intrusion.

However, even protocols that have undergone thorough audits and offer generous bug bounties are still subject to hacking attacks from time to time. Such incidents not only affect the protocols involved but also shake the foundations of trust within the entire ecosystem. Recent hacks of Yearn and Balancer V2, as well as the Abracadabra and 1inch security incidents earlier this year, all demonstrate that even the most proven 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 argue that increasing bug bounties could protect these protocols. However, even disregarding economic realities, bug bounties are essentially a passive security measure, handing the protocol's fate to white-hat hackers, while auditing is a proactive self-protective action. Increasing bug bounties cannot stop hacker attacks because it's tantamount to doubling down the stakes, betting that white-hat hackers will discover vulnerabilities before black-hat hackers. If protocols want to truly protect themselves, they must proactively conduct new audits.

Treasury Funds and Total Value Locked (TVL)

Sometimes hackers will agree to return most of the stolen funds, keeping only a small portion (usually 10%) as a reward. Unfortunately, the industry refers to this reward as a "white hat bounty," which raises the question: why doesn't the protocol simply offer an equivalent amount through a bug bounty program, thus avoiding the hassle of negotiation? But this idea confuses the funds that attackers can steal with the funds that the protocol can control.

While on the surface the protocol appears to have access to these two funds for security, it only has legal control over its own treasury funds and has no right to use user-deposited funds. Users are highly unlikely to grant the protocol such permissions in advance; the protocol will only be allowed to use deposits for negotiations in times of crisis (e.g., when depositors must choose between losing 10% or 100% of their deposits). In other words, risk increases in tandem with the TVL (Total Value Locked), but the security budget cannot increase accordingly.

Capital efficiency

Even with ample funding (e.g., a large treasury, strong profitability, or an existing security fee policy), allocating these funds reasonably for security protection remains a challenge. Compared to investing in re-auditing, increasing bug bounties is, at best, extremely inefficient in terms of capital, and at worst, leads to an incentive misalignment between the protocol and researchers.

If bug bounties are linked to TVL (Total Value Limit), researchers will have a greater incentive to conceal critical vulnerabilities when they suspect the protocol's TVL will increase and the probability of repeated vulnerabilities is low. This would ultimately pit researchers against the protocol, harming user interests. Simply increasing bounties for critical vulnerabilities is also unlikely to achieve the desired effect: while the freelance researcher community is large, very few dedicate the majority of their time to bug bounties and possess the skills to find vulnerabilities in complex protocols. These elite researchers will focus their time on bounty projects with the highest probability of return on investment. For large, well-established protocols, the probability of finding vulnerabilities is considered extremely low because they are always under close scrutiny by hackers and other researchers, so no amount of bounty will be enough to attract their attention.

Meanwhile, from the protocol's perspective, bug bounties are funds reserved for paying out for individual critical vulnerabilities. Unless the protocol is willing to gamble that a critical vulnerability will never appear and simultaneously conceals its liquidity situation from researchers, these funds cannot be used for other purposes. Rather than passively waiting for researchers to discover critical vulnerabilities, it's better to use the same amount for multiple re-audits over several years. Each re-audit ensures attention from top researchers and avoids being artificially limited to finding a single vulnerability, while also aligning the interests of researchers and the protocol: if the protocol is exploited, both parties will suffer reputational damage.

Existing precedents

In the software and finance industries, annual due-of-year audits are a proven and established practice, and the best way to assess a company's ability to cope with an evolving threat environment. SOC 2 Type II reports are used by B2B clients to assess whether suppliers maintain appropriate security controls; PCI DSS certification indicates that a company has taken adequate measures to protect sensitive payment information; and the U.S. government requires stakeholders with access to government information to obtain FedRAMP certification to maintain high standards of security.

While smart contracts themselves are immutable, their operating environment is not static. Configuration settings may change over time, dependencies may be upgraded, and code patterns that were initially considered secure may actually be risky. Protocol auditing is an assessment of the security status at the time of the audit, not a forward-looking guarantee of the protocol's future security. The only way to update this assessment is to conduct a new audit.

In 2026, the crypto industry should adopt annual audits as the fourth step in protocol security. Existing protocols with significant TVLs should undergo re-auditing of their deployments; auditing firms should provide specialized re-auditing services focused on assessing the overall deployment status; and the entire ecosystem should collectively shift its perception of audit reports as assessments of security at a specific point in time, which may become outdated rather than providing permanent security assurance.

Disclaimer: As a blockchain information platform, the articles published on this site represent only the personal views of the authors and guests and do not reflect the position of Web3Caff. The information contained in the articles is for reference only and does not constitute any investment advice or offer. Please comply with the relevant laws and regulations of your country or region.