Security in crypto carries a reputation problem. For years the security function has been cast as the team that says no, the box that has to be checked before a release ships, the cost center that slows everything down. In a recent conversation on The Security Table, Tamas Henning argued that this framing is backward, and that the teams getting it right treat security as a source of business value rather than a tax on velocity.

Henning has spent his career shaping security organizations in fast-moving environments, from Novi and the Libra project to Circle. His view is worth weighing for any team building on decentralized rails, because it reframes three questions that come up constantly in web3 security: how to build a security culture that keeps pace with product, where automation actually helps, and which threats deserve attention first.

Security Teams Should Add Business Value, Not Subtract It

Henning's central point is that the security function has to position itself as a business differentiator. In his words, the goal is to be "a business value add versus a business value substractor." When security operates as the police, it earns a negative connotation and gets routed around. When it operates as an advisor that helps teams find creative unlocks, it earns a seat at the table with product and engineering leadership.

This matters more in crypto than almost anywhere else. As Henning put it, "especially in a fast-paced moving environment like crypto," there is "no box that you can design that really works in this environment." A static checklist cannot keep up with the rate of change in smart contract development, novel protocol designs, and composable financial infrastructure. The security function has to be creative, and it has to be embedded early enough to influence what gets built rather than auditing it after the fact.

For protocol teams, the practical takeaway is that security should be present at the design stage, not bolted on before deployment. The earlier a security perspective enters the development lifecycle, the more it functions as an enabler and the less it functions as a gate.

‍

Automation Belongs on the Work That Does Not Require Judgment

Asked how he decides what to automate, Henning offered a sharp personal philosophy: "if you're not automating yourself out of your own job, you're focusing on absolutely the wrong thing." The work he targets for automation is the mundane and repetitive layer, the tasks that are critical to the business but do not require human creativity. Automating those frees the team to focus on the harder, more novel problems.

This is the distinction that defines responsible automation in security. The repeatable, well-defined work is exactly where automated tooling shines, because the same input should produce the same result every time. That reliability is the value. The open-ended, judgment-heavy work, by contrast, still needs human expertise.

This is also where the line between deterministic tooling and probabilistic AI becomes operationally important. Deterministic security testing produces the same result on every run, which is what makes it trustworthy for the repetitive layer of the security workflow. It can be run continuously, in development, as part of the build, without a human babysitting every execution. The goal is to be, as Henning described it, "more of an observer to those events happening, to those assessments happening and unfolding," rather than performing each check by hand.

Olympix builds in this direction. Pre-deployment security tooling that runs deterministically inside the development workflow gives teams the continuous coverage Henning describes, while reserving human attention for the design decisions and edge cases that genuinely require it.

Privacy and Security Are Intertwined, and Easy to Decouple by Accident

Henning also spoke to a subtler failure mode. Privacy and security are deeply intertwined, but it is "really, really easy to look at it only on the base layers." As teams compose on top of existing infrastructure, they can lose sight of one or the other. His guidance is to state both as explicit principles and non-negotiables from the start, and to keep a clear line of sight on how the two interact across the stack.

For composable DeFi, where protocols build on protocols, this is a standing risk. A guarantee that holds at the base layer does not automatically survive composition. Properties have to be verified at the layer where they actually matter, across the paths a system can actually take.

Be Practical About the Threats You Actually Face

The most grounded part of Henning's argument is his case for practicality. There is no perfect security. As he put it, "if you really want perfect security, just turn it off, go home, wrap it up." Since something always has to be compromised, the right question is what is practical for the stage and threat model you are actually in.

The security posture of a Series A company is not the posture of a Fortune 100 company, and the attackers, regulatory regimes, and scale of problems differ accordingly. Henning's advice is to be practical for your stage and for the real threats you will face, while keeping an eye on where you need to move next. The mistake is over-investing in a low-probability scenario a decade away while under-investing in the threats arriving this quarter.

For most protocol teams, the threats arriving this quarter are concrete. Logic errors, unchecked edge cases, and vulnerabilities introduced during active development are the practical, present-day risks, and they are best caught before code reaches mainnet.

The Human Layer Is the Most Underestimated Defense

Asked for his security hot take, Henning named the human layer. People make mistakes. Even the most sophisticated and aware practitioners eventually slip, because they get tired, they travel, they get jet lagged, and something goes wrong. Stacking defensive layers does not change this. As he warned, assuming that ten million layers of defense will protect you "from literally everything is a false sense of security," because an attacker will go after the single human still making the decision.

His second warning was about convenience habits that are hard to break, like SMS-based two-factor authentication, which feels effortless but exposes users to SIM swapping and social engineering. His conclusion ran against the instinct to chase the newest tool: "the boring, easy, more well-defined hygiene security things actually get you way further than you think." Go for the boring controls, especially where it matters, because those are the ones that have been truly tested.

This translates cleanly to smart contract security. The disciplined, well-tested practices, comprehensive testing, verification of critical properties, and rigorous review before deployment, do more to protect a protocol than the latest novel tool that has not yet earned trust.

Where This Leaves Teams Building on Decentralized Rails

Henning's themes connect into a single posture. Security should enable the business, automation should handle the repeatable work so humans can focus on judgment, and the practical, well-tested controls deserve priority over whatever is newest. None of this argues for retreating from DeFi or slowing down. It argues for hardening the parts that can be hardened, with discipline, before they ship.

That is the layer Olympix is built for. Pre-deployment, deterministic security tooling catches the practical, present-day vulnerabilities during development, when fixing them is cheapest and before an attacker can reach them. Audits and AI-assisted review are valuable, but they are necessary rather than sufficient. Provable, pre-deployment security is what holds when everything else is probabilistic.

See how Olympix builds provable security into your code before deployment. Book a free demo!