On September 8, 2025, a sophisticated attacker compromised a prominent staking provider’s infrastructure and walked away with customer funds. The breach at Kiln was not prevented by audits, penetration tests, or SOC 2 compliance, all of which were in place. The attacker used state-actor-level techniques that evaded every security measure.
The Kiln incident reveals a fundamental architectural problem: when institutions stake through external dApps, they’re often blind-signing transactions they can’t fully read and trusting infrastructure they don’t control. The incident perfectly illustrates why institutions need more than just custody solutions. They need integrated, intent-aware infrastructure that eliminates entire categories of risk.
What Happened: Anatomy of the Attack
The breach began when an attacker compromised a Kiln infrastructure engineer’s GitHub access token, eventually injecting malicious code into the Kiln Connect API. The modification was surgical: when customers requested to unstake their Solana positions in significant amounts, the API returned the expected unstaking transaction plus a hidden instruction that transferred the withdrawal authority of the stake account to the attacker’s address.
On August 31st, one institutional customer connected to the Kiln dApp to unstake a position. They reviewed the transaction, their signing quorum approved it, and they broadcast it to the network. Everything appeared normal. But embedded in that transaction were multiple instructions that reassigned ownership of their staked assets. Days later, the attacker withdrew the funds.
Think of it like signing a contract that appears to be about one thing, but buried in the fine print is a clause stating “all your money now belongs to me.” The customer unknowingly signed away control of their assets because they were blind-signing a serialized transaction payload that was essentially unreadable. On Solana especially, even experienced blockchain engineers struggle to parse raw transaction data. The signing quorum did their job, but couldn’t see what they were actually signing.
Why It Happened: The Fundamental Problem with External dApps
The Kiln incident wasn’t just about a compromised backend. It exposed a systemic vulnerability in how institutions interact with external staking providers.
When you stake through an external dApp, here’s what actually happens:
- You initiate an action in a third-party application
- That application’s backend serializes a transaction
- Your custody solution receives raw bytes
- Your approvers attempt to verify those bytes
- You sign and broadcast based on incomplete information
At every step, you’re trusting infrastructure you don’t control. You’re trusting that the dApp backend hasn’t been compromised. You’re trusting that the serialization layer is generating transactions that match your intent. You’re trusting that no malicious commands have been injected into a payload you can’t fully read.
For institutions with strict compliance requirements, this model is architecturally incompatible with how digital asset operations should function, and the risk is unacceptable.
Fireblocks’ Immediate Response
As soon as the Kiln incident came to light, Fireblocks took immediate action to protect customers:
- Blocked compromised dApps to prevent any exposure through the affected infrastructure
- Halted API integrations with potentially compromised endpoints as a precautionary measure
- Facilitated migration of all external staking positions created outside our native solution, ensuring customers could continue operations without security risk
These rapid response measures protected all Fireblocks customers from exposure. But more importantly, the incident reinforced why we built native staking the way we did. We designed it not just to respond to threats, but to make entire classes of attacks impossible by design.
How Native Staking on Fireblocks Eliminates This Risk
Fireblocks’ native staking solution is built on a fundamentally different architecture, one where the Kiln-style attack couldn’t happen. Here’s why:
1. Intent-Based Operations with Full Context
When you stake on Fireblocks, the operation begins inside the Fireblocks Console. We know your intent from the start: you pressed “Stake” or “Unstake.” You’re not connecting to an external application that then sends us a serialized payload.
This might seem like a small distinction, but it’s architecturally critical. Because we have the intent, we can validate every subsequent step against what you actually told us you wanted to accomplish.
2. Policy Engine for Staking Governance
With intent captured at the source, Fireblocks can apply sophisticated policy rules specifically designed for staking operations. Customers can configure:
- Which users can stake or unstake
- Which blockchains and protocols are permitted
- Which validators and providers should be used
- Maximum amounts per transaction
- Required approval workflows
- Permitted source vaults
These aren’t generic transaction policies, they’re staking-aware rules that understand the semantic meaning of the operation. When a transaction comes from an external dApp, we can’t apply this level of governance because we don’t have the context. We only see the serialized payload.
In the Kiln scenario, the attack that succeeded (i.e. changing the withdrawal authority of a stake account) wouldn’t even be possible within Fireblocks’ native staking architecture. Our staking operations are structurally constrained to do exactly what they’re designed for: stake or unstake. Commands to change authorities, transfer ownership, or execute any action outside the staking context simply cannot be embedded in a Fireblocks staking transaction.
3. Human-Readable Transaction Verification
When approvers review a staking transaction on their mobile devices, they see human-readable information that accurately reflects what will happen:
- Operation type: Stake / Unstake
- Amount
- Blockchain and protocol
- Source and destination addresses
- All relevant parameters in plain language
No raw bytes. No opaque payloads. No blind signing.
Even on complex chains like Solana, where raw transactions are nearly impossible to parse, Fireblocks presents clear, accurate information because we control the entire flow from intent to serialization.
4. Secure Enclave Serialization
Once your staking transaction is approved, Fireblocks serializes it within secure enclaves, which are isolated, tamper-resistant environments where the transaction payload is generated. Critically, this serialization is bound to the original intent.
There’s no external backend that could be compromised. There’s no opportunity for malicious code to inject additional commands. The transaction that gets created is, by design, limited to exactly what you approved. If you authorized an unstaking operation, the payload will contain only the unstaking command, nothing else.
In the Kiln incident, the attacker compromised the serialization layer. In Fireblocks’ architecture, that layer is isolated within secure enclaves and directly coupled to validated intent.
Defense in Depth: Architecture That Prevents These Risks
The Kiln incident wasn’t a failure of vigilance. Kiln is SOC 2 Type II certified, conducts regular penetration tests, and has robust security measures. The attacker used sophisticated, state-actor-level techniques that evaded every audit.
In this case, architecture matters more than audits. Fireblocks’ native staking solution was specifically designed to eliminate the risks that external integrations introduce. Here’s how each step in the workflow adds a layer of protection:
User Action (Intent)
↓
Policy Validation (Governance layer ensures only authorized operations)
↓
Approval Workflow (Human-readable verification by designated approvers)
↓
Secure Enclave Serialization (Tamper-proof transaction generation)
↓
Signing (Cryptographic authorization in MPC-based architecture)
↓
Broadcast to Network (Direct node communication)
This is what institutional-grade staking infrastructure looks like, that is designed from the start to make entire classes of attacks structurally impossible.
Moving Forward: Security by Design
The cryptocurrency industry will continue to be targeted by sophisticated adversaries. As adoption grows and the value at stake increases, attacks will become more creative and more damaging.
The answer isn’t just better monitoring or faster incident response, though those matter. The answer is infrastructure designed so that even if an attacker compromises external systems, your assets remain protected because the attack vector doesn’t exist in your architecture.
Fireblocks delivers not just security measures, but security by design.
Ready to Stake with Confidence?
If you’re evaluating staking infrastructure or reconsidering your current setup in light of recent events, we’d be happy to discuss how Fireblocks’ native staking solution can meet your institution’s requirements.
Our team can walk you through the architecture, discuss policy configurations tailored to your governance model, and show you how intent-based operations provide both security and operational efficiency.
Schedule a demo to learn more about securing your staking operations.
