When the Nomad hack happened in August 2022, I was sitting at my desk watching $190 million drain in real-time. The exploit was brutally simple: a routine upgrade contained a flaw that effectively marked all messages as verified. It wasn't a sophisticated attack—it was a basic initialization error.

What struck me wasn't just the hack itself, but what happened after. The community tried a "white hat counter-hack" to save funds, which technically worked, but it felt like watching people use a kitchen fire to cook dinner. We were treating symptoms, not solving the underlying problem.

The so-called AI Security Gold Rush

Fast forward to 2023, and everyone seemed to be building AI-based security tools. The premise was appealing: train models on past exploits to predict and prevent future ones. But the deeper I looked, the more problems I saw:

The past doesn't predict the future in zero-sum games. Attackers don't repeat strategies—they innovate. AI trained on yesterday's exploits might miss tomorrow's novel attacks.

Latency kills in DeFi. When milliseconds determine whether a transaction is profitable, adding AI inference time creates unacceptable delays. Each second of latency is another second of vulnerability and everyone knows AI isn’t exactly computationally simple.

False positives destroy the user experience. AI security systems flag legitimate trades as suspicious and block transactions that should have gone through. Users don't come back after experiences like that.

Who is legally responsible for the decisions an AI makes? AI makes autonomous security decisions that create complex liability questions. Who's responsible when an AI security layer fails or inappropriately blocks transactions? This creates new legal risks for both protocols and networks.

Who’s data? Training effective AI requires access to transaction data, creating potential privacy issues. Users may not want their transaction patterns to feed security models.

AI is centralized. Effective AI security requires massive training data and computational resources, naturally leading to centralization. Only a few entities can afford to build and maintain these systems, creating new trust points. Moreover, any transaction inclusion or exclusion rights will lie with the AI.

But beyond these technical issues, there was a more fundamental problem. The teams building AI security tools were effectively saying: "Don't worry about understanding your contracts—our black box will protect you." This approach creates a dangerous disconnect between builders and the protocols they create.

Back to First Principles

I started asking a simple question: Who understands a protocol better than the team that built it?

Builders intimately understand their smart contracts. They know exactly what should and shouldn't happen. They write tests defining these boundaries. The answer wasn't in complex AI or anything else, it was in empowering teams to define their security rules.

This realization led directly to the Credible Layer's deterministic approach:

  1. Teams define what "hacked" looks like for their protocol
  2. These definitions run at the sequencer level
  3. Any transaction that would create a "hacked" state is rejected before execution

Devex Above All

Having spent years working with blockchain infrastructure, I've seen brilliant products fail because they weren't developer-friendly. Security tools often force teams to learn new languages, frameworks, or paradigms. This adds complexity when they should be removing it, and new attack surfaces when they are trying to prevent hacks. 

That's why we made a critical decision: assertions should be written in Solidity, structured like Forge tests.

When I first showed this to a developer at ETHDenver recently, they literally smiled. "You mean I just write tests like I already do?" Yes, exactly. The best security tool is one you already know how to use.

Here are two other ways we have built our product to be powerful and easy to use:

Parallel Validation: Traditional on-chain invariants run sequentially, creating gas constraints. Our assertions run in parallel off-chain, letting you write complex security rules without worrying about execution costs. 

Powerful Precompiles: We built specialized functions like forkPreState, forkPostState, getCallInputs, and getStateChanges that let developers inspect transaction internals in ways impossible on-chain. These precompiles enable "security time travel"—comparing states before and after transaction execution to catch sophisticated attacks.

Let me share a concrete example of how this all comes together: Imagine a lending protocol that implemented an assertion checking their global solvency. The assertion uses our forkPreState and forkPostState precompiles to compare the total collateral value before and after transaction execution, ensuring it never drops below the total borrowed value plus a safety buffer.

This single assertion would consume a lot of gas on-chain, making it impractical to run with every transaction. On the Credible Layer, it runs in milliseconds with zero gas cost.

We've seen teams port their existing test invariants to assertions in minutes. No new languages to learn. No complex integration. No redeployment. Security shouldn't require a PhD.

What excites me most about this approach is the potential security network effect. As more protocols write assertions, they create a shared knowledge base of security rules. A DEX's price manipulation protection can be adapted by another similar protocol in minutes. A lending platform's solvency check becomes a template for others.

This creates a virtuous cycle where the entire ecosystem becomes more secure through collaboration. Unlike proprietary AI models that keep their insights locked away, assertions are transparent and reusable. The more protocols join, the stronger everyone's security becomes.

Why Determinism Matters

In a space built on mathematical certainty, it's strange that we've embraced probabilistic security. Blockchain was created to eliminate trust—yet we're being asked to trust black-box AI with billions in value.

Deterministic assertions provide several fundamental advantages:

Transparency: Anyone can verify exactly what security rules protect a protocol
Certainty: Rules either validate or they don't. No probabilities or thresholds
Decentralization: Security rules are public, shareable, and adaptable by the community Evolution: Teams can expand protection as they learn, without breaking existing functionality, needing to pause their contracts or redeploy.

But perhaps most importantly, deterministic security reduces the attack surface instead of expanding it. Every new system component introduces potential vulnerabilities. AI security tools add ways to reduce functionality or in other words, censor transactions. 

And we’re also building a transparency explorer where users can verify exactly how protocols are protecting their funds. Instead of vague assurances about "industry-leading security," users can see the specific rules ensuring the safety of their assets. This shifts trust from teams to verifiable code. The way blockchain was always meant to work.

Imagine checking a protocol and seeing "Protected against: flash loan attacks, price manipulation, reentrancy" with the actual assertions available for inspection. That's true security transparency.

Looking Forward

The stakes are simply too high for probabilistic approaches. When billions in value depend on your code, you need guarantees, not probabilities.

That’s why I believe strongly that the teams building protocols should remain responsible for their security. Not because it's easier for us, but because it's truly better for the ecosystem. When teams deeply understand their security boundaries, they build better protocols.

The future of crypto isn't in delegating security to third-party AI. It is empowering builders with tools that make security natural, intuitive, and effective.

Sometimes the most innovative solution isn't the most complex. It's the one that feels so obvious in retrospect that you wonder why it wasn't built sooner. It’s the one that’s powerful and simple because it was designed with care. 

That's the Credible Layer—not a radical reinvention of security, but a return to first principles. Define what security means for your protocol, and let the network enforce it.

The best security isn't an add-on. It's built-in.

And if you're building a protocol and this approach resonates with you, we want to work with you. We're onboarding select projects to our early access program, helping teams implement their first assertions and providing direct support as they build their security foundation.

Reach out to me directly or visit our website to learn more about joining. Your expertise combined with our tools could set new standards for what security looks like in this industry.

‍