By mid-2025, reported crypto losses tied to security failures had already passed $2.4 billion. That number gets repeated often enough that it barely lands anymore. What’s troubling isn’t just the size of the losses, but how easily they’re brushed aside as isolated incidents rather than symptoms of the same underlying problems.

Looking at this year’s largest failures, a pattern becomes hard to ignore. Many didn’t involve broken cryptography or attackers prying keys out of cold storage. Instead, funds moved through valid signing paths using permissions that already existed. The systems worked as designed. The design itself appears to be the issue.

The Kiln incident fits this pattern closely. It’s usually described as a staking failure, but that framing may be misleading. No keys were stolen. No custody boundary was obviously breached. The signatures were valid. What failed were the assumptions around how signing authority was delegated and reviewed.

What Actually Happened

To keep staking operations efficient, Kiln relied on pre-authorized signing flows that reduced the need for constant human approval. That choice was understandable. Staking is operationally repetitive, and friction doesn’t scale well. The downside was quieter.

On Solana especially, transactions approved through these flows were not meaningfully readable. Signers saw opaque calldata, not clear intent. In normal conditions, that limitation probably felt acceptable.

The exploit only worked once that assumption broke. After compromising a Kiln engineer’s GitHub token, an attacker injected malicious code into the Kiln Connect API. When users later requested to unstake, the API returned what looked like a standard unstaking transaction, along with an embedded instruction transferring withdrawal authority to the attacker.

From the system’s perspective, nothing was obviously wrong. The transaction followed an approved path. The signature checked out. The problem was simpler: no one signing could clearly see what they were authorizing.

Why This Keeps Happening

This kind of risk rarely shows up all at once. Permissions accumulate. Integrations deepen because they make life easier. Over time, custody controls and application logic blur together.

We’ve seen similar dynamics in incidents involving Phemex and several BSC-based protocols. Treasury systems become tightly coupled to application behavior. Roles gain more authority than originally intended. Controls quietly assume that the right person will notice the right alert at the right moment.

That assumption is optimistic. Much of today’s custody infrastructure still seems designed for normal operations, not failure. When something slips, the architecture often does little to slow value movement or limit impact.

Why Process Isn’t Enough

After an incident, the response is familiar. Keys are rotated. Permissions tightened. Another signer added. Runbooks get longer.

These steps are often sensible but incremental. They sit on top of the same architecture that already failed. Risk doesn’t disappear; it shifts. Humans become the control plane, and systems quietly assume people will perform perfectly under stress. Many post-mortems describe exactly this dynamic.

Swapping tools or vendors can help mitigate symptoms, but it rarely addresses the core issue: broad signing authority combined with weak structural limits once access is obtained.

Why Puffer Took a Different Approach

When we built Puffer’s liquid staking and institutional staking, we assumed that people make mistakes, dependencies fail, and attackers look for quiet paths rather than obvious ones. That assumption shaped the design.

Private keys are never exposed in accessible environments. Withdrawal credentials are verified using Trusted Execution Environments, with validator registration halting automatically if the TEE code changes. Treasury and validator operations are isolated by design, reducing the chance of cascading failures.

Economic guardrails matter too. The 2 pufETH bond introduces a meaningful cap on blast radius, adding roughly $5 billion in economic security against slashing and helping protect users from de-pegs. The goal isn’t invulnerability. It’s containment.

Puffer Institutional

Puffer Institutional is designed for exchanges and asset managers that want to retain full control over deposit and withdrawal permissions while choosing how much to stake or restake. Institutions can launch their own liquid staking or restaking tokens without handing authority to opaque application logic.

If you’re re-evaluating whether your current custody stack is actually built for today’s risk profile, Puffer is meant for that conversation, especially for teams that want security treated as a first-order architectural constraint, not an operational assumption.