# Twenty Years of Breaking Things

Knowing how systems break is the best possible training for building onchain — where mistakes are permanent. kooky's 20+ years in digital and information security is the foundation under everything.

---

There's a specific kind of silence that happens when you realize a system you just probed doesn't behave the way its builders thought it did. Not a dramatic alarm. Not a cascade of errors. Just a quiet, slightly wrong response that tells you someone made an assumption they shouldn't have. I've been sitting with that silence for over two decades. It has a texture I still find more useful than almost any documentation ever written.

This piece is about what that time actually taught me — and why it matters that it sits underneath everything I do now, from auditing at Darkwave to the way Shaka and Queensland are being built.

## What Systems Teach You When They Break

The single most reliable thing I learned in twenty-plus years of digital and information security is deceptively simple: **systems fail under load, at the edges, and where money and traffic concentrate.**

Not in the middle. Not in the carefully maintained core where everyone is looking. In my real-world testing, incidents rarely start at the core. They start at the edges — where systems, roles, and trust zones touch each other, and everyone quietly assumes the other side is behaving.

That word — *assumes* — is doing a lot of work. When reasoning about a software system, we make assumptions about the actual system as it's running in production. An attacker can violate an assumption. The violation doesn't require genius. It usually just requires noticing that someone drew a boundary and then trusted everything on the inside of it without ever checking whether that trust was earned.

Assumptions create a false sense of safety. People start trusting the *presence* of a control more than the condition that exists around it. I have watched this play out in enterprise networks, in financial systems, in identity and access architectures — and now I watch it play out onchain. The medium changes. The pattern does not.

The second lesson is related but distinct: **attackers think laterally.** They do not come at you through the door you reinforced. Every breach has a story — they follow a script. It starts with something simple: scraping public info, probing for weak spots, fooling someone into opening the door. From there, it's a slow creep — privilege escalation, staying hidden, exfiltrating and stealing valuable data. I spent years in that mode of thinking — not as an attacker for hire, but as someone whose job was to model attacker cognition before anyone else got hurt. That reorientation of perspective, from *builder* to *adversary*, is not a hat you put on. It is a permanent change in how you read a system.

One of the hallmarks of security professionals is that they spend a lot of time worrying about edge cases that would fail to alarm an ordinary person — because the edge case doesn't sound like something an adversary is likely to do. The edge cases are exactly where the interesting things happen.

## The OSINT Mindset, and How It Reads a Chain

Open-source intelligence work runs on a simple principle: nearly everything you need is already publicly available. The skill is knowing what to look for, where to look, and — critically — how to read what you find against what you expected to find.

Unlike traditional OSINT, which focuses on websites, emails, IP logs, and social media, Web3 OSINT mines value from wallets, smart contracts, DApps, token flows, and pseudonymous identities. The ledger is open. Every transaction is a public artifact. Blockchain makes it possible for open-source information to be recorded publicly while guaranteeing the data won't be changed after it has been stored, which significantly increases the accuracy of the data gathered.

That is a remarkable thing to sit with if you've spent any time trying to verify provenance in traditional environments. Onchain, the receipts are permanent and universal. The problem is not access to information — it's knowing what the information means.

This is where the OSINT background transfers directly. Security analysts and researchers use specialized OSINT techniques to conduct on-chain analysis, monitor wallet activities, and examine smart contracts for potential vulnerabilities. But the tool is only as useful as the analyst's model of behavior. What you're actually doing when you read a chain with an OSINT mindset is building a behavioral map: who is acting, at what time, with what frequency, in what patterns — and then asking where those patterns diverge from what a legitimate actor would do.

The divergences are the signal. Blockchain explorers let you examine transactions, addresses, and smart contracts in detail, and dive deep into transaction details, token movements, and interactions within the ecosystem. But the read-out from those tools is inert without context. Context is what two decades of watching how systems fail actually provides. I know what normal looks like because I have spent a very long time studying abnormal.

## Breaking and Building Are the Same Skill, Viewed From Two Sides

Here is the thing the security industry took me years to articulate cleanly: security engineers believe there is an optimal ratio of earned knowledge about risks gained from breaking, and building to prevent the risks you've discovered. Breaking is a source of knowledge. The lessons from breaking provide direction for security leadership.

That's the professional framing. The more personal version is this: every time I broke something, I learned something a builder would never have found. The designers are so busy making these systems work that they don't stop to notice how they might fail or be made to fail, and then how those failures might be exploited. Teaching designers a security mindset will go a long way toward making future technological systems more secure.

The build-it mindset optimizes for function. The break-it mindset optimizes for fragility. You need both. If we assume our controls will fail at some point, we can build a much more resilient architecture. This isn't defeatist thinking. It's realistic, battle-tested strategy.

When I come to a new system now — my own or someone else's — the first questions I ask are not *does this work?* They are: *under what conditions does this stop working? What happens at the boundary? What did the builder assume that they shouldn't have?* Those questions don't slow down development. They shape it.

## Why Onchain Raises the Stakes Considerably

Traditional software has a recovery path. You patch. You revert. You compensate users. You issue a post-mortem and move on. Onchain, that path is substantially narrower. Alarming statistics reveal that DeFi has suffered total losses of $77.1 billion due to scams, hacks, and exploits, with only $6.5 billion recovered. The permanence is not a metaphor. It is a structural feature of the technology.

This changes what a security mindset is worth. In a traditional environment, catching a vulnerability before production is better than catching it after — but catching it after is survivable. Onchain, the window between discovery and irreversibility can be a single block. Smart contracts feel like rules carved in stone, but attackers move like water, always looking for the smallest crack.

The attack surface is also genuinely novel in ways that traditional security intuitions don't fully cover. Flash loan attacks exploit the ability to borrow large amounts of crypto without collateral, provided the loan is repaid within the same transaction. Attackers use these loans to manipulate on-chain data, like prices or governance votes, executing complex transactions that exploit vulnerabilities in the contract's logic. This is not a class of attack that maps cleanly onto anything from enterprise security work. It required developing a new vocabulary while leaning heavily on an old one.

Losses remain huge, but the mix has shifted toward multi-vector exploits that blend bridges, oracles, MEV tactics, governance moves, and admin control abuse. Lateral thinking again. An attacker who cannot break the contract itself will go around it — through the oracle it trusts, through the governance process that controls it, through the bridge it connects to. In 2020, the bZx lending protocol suffered multiple flash loan attacks, highlighting the risks of external dependencies. These attacks exploited vulnerabilities in external price oracles that bZx relied on to determine token prices. Attackers manipulated the price data to borrow funds they were not entitled to. The contract was fine. The assumption the contract made about its data feed was not.

## How a Break-It Mindset Catches What a Build-It Mindset Misses

Let me make this concrete. Consider a hypothetical token vesting contract. A developer builds it, tests it, deploys it. The happy path works. Tokens release on schedule. Every test case the developer wrote passes. They ship.

A break-it thinker asks different questions before the first line of code goes to production. What happens if someone calls the release function twice in the same block? What happens if the admin key is compromised? What happens at the edge of a cliff date — is the state transition atomic, or is there a window? What does this contract assume about who calls it, and what happens if an unexpected caller arrives? What is the worst financial outcome if the oracle feeding this contract lies for thirty seconds?

Most security failures at boundaries come from assumptions, not exotic exploits. The exotic exploits get headlines. The assumption failures are where the consistent, quiet losses happen — the ones where, on review, everyone agrees it was obvious in hindsight.

Reentrancy attacks exploit external calls made by smart contracts before they update their own state. This is one of the oldest classes of onchain vulnerability. It was identified years before it was weaponized at scale. The gap between *identified* and *addressed* exists because builders are optimizing to ship, and the break-it mindset that would catch it isn't always in the room. The exploit enabling the attack was published a full year before it was used. The information was available. The incentive to act on it was not sufficiently present.

That gap — between known vulnerability and addressed vulnerability — is where I operate. Not because I'm uniquely clever, but because I have spent twenty years making that gap my professional habitat.

## How This Led Naturally to Darkwave, Shaka, and Queensland

Audit work is applied adversarial thinking. When I engage with a protocol through Darkwave, I'm not reading code to admire it. I'm reading it to find the condition its author didn't model, the state its tests didn't cover, the trust assumption that felt safe in isolation but becomes dangerous in context. The goal is to identify vulnerabilities in smart contracts and dApps — but the method is to think like the adversary first and the engineer second.

With Shaka and Queensland, that orientation is baked into architecture, not bolted on afterward. Security-first building means asking the break-it questions at the design stage, not the audit stage. It means treating the threat model as a first-class artifact, updating it as the system evolves, and when an incident is detected and remediated, not viewing this as a return to a secure state — but asking what related indicators might have been missed, what other accounts or systems might be compromised, and what detection gaps the incident revealed.

This is not a posture that makes you slower. It makes you more precise about what you're building and why each component is shaped the way it is. The twenty years aren't just résumé texture. They are the actual reason certain design decisions get made in certain ways.

## The Honest Summary

I have broken a lot of things. Most of them weren't mine to break — I was hired, contracted, or tasked to break them, because someone smart recognized that an adversary would eventually try to do the same and they'd rather have the finding than the loss. Some of them I broke by accident, which is how you learn about failure modes that nobody thought to model. All of them taught me something that no amount of reading about security could replicate.

The crucial factor differentiating resilient practitioners from susceptible ones is a pre-existing cognitive disposition: a security mindset. This mindset is not about technical knowledge, but a default way of thinking characterized by healthy skepticism. You can teach tools. You can teach frameworks. The default posture — the habit of asking *how does this break?* before you ask *how does this work?* — that one takes time.

Twenty years is apparently about the right amount of time.

What follows in the rest of the Darkwave and Shaka and Queensland story is built on that foundation. I'll explain the specifics of those projects in the pieces that follow. But if you want to understand why the decisions get made the way they do, this is the part to have read first.