bock

It's time to change how we think about web3 security. Most security reviews in Web3 still focus on the state of the code at a specific commit. They ask: “Does this implementation behave as expected under the documented assumptions?” That is necessary, but it is no longer sufficient. Recent incidents have made one thing painfully clear: attackers do not respect audit scope. They do not limit themselves to the commit that was reviewed. They do not care whether an exploit path involves a “trusted role,” an admin key, a governance process, a relayer, an oracle, a bridge dependency, or an operational assumption buried in the docs. They attack the system as it exists in production. And that is where the industry has a serious gap. Very few teams invest the time to map their entire threat model: who can do what, which roles are trusted, what happens if those roles are compromised or malicious, how dependencies interact, where privilege is concentrated, and what the true blast radius is if a single assumption fails. This is not just a problem for early-stage protocols. Even top-tier ecosystems with mature engineering, audits, and bug bounty programs still depend on complex trust assumptions that are often not fully modeled, documented, or tested under adversarial conditions. Bug bounties have the same issue. Researchers often submit findings around unsafe feature design, excessive privilege, dangerous trust assumptions, or catastrophic failure modes, only to be told that the behavior is “intended,” “requires a trusted role,” or is “out of scope.” That approach is becoming dangerous. A badly designed feature can be just as damaging as a traditional code bug. A privileged role with unchecked power is not automatically safe because it is labeled “trusted.” A governance or admin path that can drain, freeze, upgrade, or misconfigure a protocol is part of the attack surface. A cross-chain dependency that can create systemic risk is not outside the threat model; it is the threat model. The next generation of Web3 security cannot be limited to point-in-time audits. We need security reviews that include protocol-level threat modeling, role and permission analysis, upgrade-path review, oracle and bridge dependency analysis, governance failure scenarios, operational key compromise assumptions, and clear blast-radius mapping. Teams should be able to answer, plainly: - What can each privileged actor do? - What happens if that actor is compromised? - What assets are at risk? - What downstream systems are affected? - What assumptions must remain true for the protocol to be safe? - Where are the emergency brakes, and who controls them? If the answer to a serious bug report is “this requires a trusted role,” the next question should be: “What is the impact if that trust assumption fails?” The industry is at a breaking point. We cannot keep treating audits as a checkbox and bounties as narrow code-defect programs while ignoring design-level risk. The most damaging failures are often not isolated bugs. They are unmodeled assumptions, excessive privileges, unclear dependencies, and underestimated blast radius. It is time for protocols, auditors, and bounty platforms to evolve from code review to system security. Because users do not lose funds based on whether something was technically “in scope.” They lose funds when the system fails.