If Your Security Firm Cannot Review the Next Diff, It Cannot Protect Today's TVL

The right smart contract security firm in 2025 has to review live changes, signer workflows, and integration risk, not just ship a polished audit PDF.

Choosing an auditor used to sound like a procurement problem. Pick a recognizable name, scope the contracts, wait for the report, fix the findings, and ship. That model is obsolete. Live protocols do not fail only because somebody missed a math bug in a repository snapshot. They fail because risk moves faster than static review, and too many firms still sell confidence at the speed of a point-in-time artifact.

Establish the problem with technical depth

The cleanest way to see the problem is to look at where large losses actually came from.

On July 16, 2024, LI.FI said a newly added smart contract facet was exploited for about $11.6 million across Ethereum and Arbitrum, affecting 153 wallets. The protocol's own incident report says the vulnerable facet allowed arbitrary calls without the usual validation checks, and that the issue appeared shortly after the new facet was deployed. That is not an argument against auditing. It is an argument against treating the first audit as the finish line. The dangerous surface was the change itself: a new facet, a modified deployment path, and a missing validation step in the exact place where user approvals could be abused.

Three months later, on October 16, 2024, Radiant Capital said it lost about $50 million after attackers compromised developer devices and used them to sign malicious transactions. Radiant's post-mortem says the Safe interface displayed legitimate transaction data while malicious transactions executed in the background, and that Tenderly simulations and human review did not show anomalies during signing. That is a different class of failure, but it exposes the same buying mistake. If a security firm is only reviewing Solidity and not the privileged transaction path around the system, it is leaving part of the real attack surface unpriced.

This matters to founders and investors because TVL does not care which layer failed. Capital is still gone whether the cause was a storage collision, a permissive upgrade, or a compromised signer workflow. It matters to CTOs and Solidity engineers because the protocol they are actually defending is no longer just the deployed bytecode. It is the deployed bytecode plus the next diff, the next upgrade, the next integration, and the set of people and tools allowed to change all of it.

That should change how teams choose security partners. The right question is not "who can audit our contracts?" It is "who can still reduce loss probability once the audited contracts start changing under production pressure?"

The mechanism, the mistake, the misunderstanding

The mechanism is simple even when the incidents are not. Protocol risk now moves through three linked surfaces: logic, change, and control.

Logic is the familiar one. Does the code preserve the invariants that keep the system solvent, correctly permissioned, and internally consistent? Every serious firm should still be good at this. But pure logic review is not enough because the reviewed state is rarely the shipped state for long.

Change is the second surface, and this is where many audits quietly expire. By "diff," we mean the exact code, config, and deployment changes between what was last reviewed and what is about to ship now. LI.FI's own report is a blunt example of why this matters. The exploit followed the addition of a new facet, and the critical whitelist-style validation that existed elsewhere was missing in that deployment. A firm that can produce a clean first-pass report but cannot rapidly review release deltas is not protecting a live system. It is documenting an older one.

Control is the third surface. By "control plane," we mean the accounts, multisigs, scripts, dashboards, wallet flows, and emergency procedures that can change the protocol or move funds. Radiant is the warning here. The loss was not described as a missing require statement. It was a failure in the privileged execution path: trusted operators, legitimate-looking transaction displays, and malicious execution hiding underneath. If your security partner does not examine how privileged actions are proposed, decoded, simulated, approved, and revoked, then some of your most dangerous code paths are being treated as operations instead of security.

The misunderstanding is to buy depth on only one of those three surfaces and call it coverage.

That is why "we were audited" has become such a weak sentence. An audit might be excellent inside its scope and still leave the protocol exposed everywhere else that live teams actually take risk. OpenZeppelin's access control documentation makes the core point plainly: access control decides who can mint, freeze, vote, or perform other critical actions, so it has to be designed carefully. OpenZeppelin's upgradeable-contract guidance makes the second point just as clearly: upgradeable systems have structural constraints, and even initialization and storage layout mistakes can become critical if they are not validated correctly. If a security firm is not fluent in both privilege design and upgrade discipline, it is not auditing the system you really run.

What good looks like

Good security buying in 2025 starts with scope discipline. A serious firm should want the exact commit under review, the list of pending release deltas, the upgrade pattern in use, the role map, and the deployment path. If the kickoff is basically "send us the repo and we will send back a PDF," the scope is already too soft.

Good review also includes explicit upgrade safety work. OpenZeppelin's @openzeppelin/upgrades-core tooling provides a validate command to check upgrade safety and storage layout compatibility. That should not be exotic. It should be normal. If a protocol uses proxies or upgradeable facets, the buyer should expect concrete evidence that the reviewer checked whether the next implementation is compatible with the current state, not just whether the new code looks reasonable in isolation.

Good firms pressure-test protocol truths, not just functions. Foundry's invariant testing guidance is useful because it checks properties that must always hold across random sequences of calls, instead of overfitting to the polite path the developer imagined. Foundry's fork testing guidance matters for a related reason: it lets teams run those checks against real chain state and live integrations without touching production. When a firm says it reviewed solvency, reward accounting, liquidation safety, or privilege boundaries, there should be an artifact behind that claim, not just a sentence.

Good firms also review the signer path like it is part of the protocol, because it is. That means checking role separation, timelocks, emergency permissions, transaction decoding outside a single wallet interface, and the procedures used when approvals or upgrade proposals are signed under time pressure. Radiant is what happens when teams assume multisig threshold math is the whole story. It is not. If a signer cannot independently verify transaction meaning, the protocol has a security problem even when the underlying contracts are elegant.

Finally, good firms define when the audit stops being current. That sounds obvious, but it is the most common missing deliverable. The buyer should leave the engagement knowing which classes of changes require re-review: new integrations, new privileged actions, new upgrade authority, new asset types, new callback surfaces, or any release that widens who or what can influence protocol state. If that rule is missing, the engagement optimized for a report rather than a control system.

ChainShield's angle

ChainShield's view is that the best security partner is not the firm with the most impressive static artifact. It is the one that can keep following risk after the artifact becomes stale.

That means reviewing the live diff, not just the last milestone branch. It means treating the control plane as part of the protocol, not as somebody else's operational problem. It means asking what changed, who can push it, how they verify it, and what invariant breaks if the answer is wrong. Most importantly, it means refusing to let "audited" stand in for "defensible."

This is where the market is going whether firms like it or not. Founders are going to be asked harder diligence questions. CTOs are going to be judged on release discipline, not just code cleanliness. And security vendors that cannot follow the system through upgrades, privileged workflows, and high-velocity changes will keep producing artifacts that look complete right until the next diff ships.

If your security firm cannot tell you how it will review tomorrow's change, it is not really protecting today's TVL. It is certifying a snapshot that is already disappearing.