In early October, 2025, two new physical attacks - Battering RAM and Wiretap, broke open the latest generation of hardware trusted execution environments (TEEs), namely Intel SGX Scalable and AMD SEV-SNP.
These attacks didn’t just expose theoretical vulnerabilities. They granted real attackers the ability to extract attestation keys, effectively nullifying the cryptographic guarantees of those TEEs. Within hours of disclosure, multiple blockchain projects built around them like Phala, Secret, Crust, and IntegriTEE began issuing emergency updates and migration plans.
One project didn’t have to: Oasis.
While others scrambled to patch, Oasis nodes kept running exactly as before. The reason has less to do with luck and everything to do with architectural philosophy, a belief that TEE security must never be a single point of failure.
Understanding What Broke
To understand why Oasis stayed online, we first need to look at what actually failed elsewhere.
Both Battering RAM and Wiretap exploited flaws in deterministic encryption schemes used in new SGX and SEV-SNP memory controllers. By monitoring predictable encryption patterns, attackers could reconstruct secret material including attestation and session keys from physical side channels.
Once the attestation layer is gone, the whole TEE trust model collapses:
- Data sealed inside enclaves can be decrypted externally.
- Remote attestation can be forged.
- “Confidential compute” becomes just “compute.”
This chain reaction was precisely what many TEE-reliant blockchains experienced. Their node operators lost assurance that enclave nodes were genuine, effectively breaking consensus-level trust.
Why Oasis Didn’t Fall
Oasis took a different path years ago. Its team designed around the assumption that hardware will fail eventually, so every core system includes at least one independent layer that doesn’t rely on TEE integrity.
Here’s how that philosophy plays out in practice:
1. Architectural Separation
The key manager and Sapphire confidential runtime on Oasis run on Intel SGX v1, not the newer Scalable version. SGX v1 uses non-deterministic memory encryption and an attestation model that wasn’t impacted by the recent flaws.
More importantly, Oasis separates key access and execution. No single enclave or node ever holds the full cryptographic picture. A compromised enclave is isolated, not catastrophic.
2. On-Chain Governance as a Security Layer
Unlike networks that rely solely on enclave attestations, Oasis enforces on-chain governance rules around who can even run a key manager node.
Membership in the key committee requires:
- Explicit governance approval;
- A validator stake (≥ 5M ROSE);
- Continuous compliance with network policies.
Even if someone could fake attestation with stolen keys, they still couldn’t bypass these governance requirements baked into consensus logic.
3. Ephemeral Cryptography
Each epoch, the network rotates ephemeral encryption keys used for transaction confidentiality. Once rotated, the old keys are deleted permanently. This means that even a perfect enclave compromise only affects future sessions — past data remains irreversibly protected.
4. Adaptive Response
Oasis also maintains a CPU-level blacklist mechanism. When a hardware vulnerability is disclosed, affected processor models can be banned through governance proposals. This allows the network to react in hours, not months.
Lessons for Developers
For developers building privacy-preserving dApps or agent systems, Oasis offers a valuable case study in graceful failure.
TEE technology enables confidential logic and data handling, but as we’ve now seen, the underlying hardware is far from infallible. Designing for resilience means assuming that even your most “trusted” environment might one day betray you.
In practice, that means:
- Don’t rely solely on enclave attestations for authentication or access control.
- Keep sensitive operations modular and separable.
- Rotate encryption keys frequently, and expire them aggressively.
- Build governance or consensus checks that exist outside the hardware trust domain.
Oasis’s continued uptime and data integrity during this incident show that these principles are not just theoretical — they work.
A Model for Future Confidential Systems
What happened with Battering RAM and Wiretap should serve as a wake-up call for developers working on confidential smart contracts, MPC frameworks, or AI inference enclaves.
Hardware isolation is an important tool, but not a guarantee. The safer path forward is layered trust, where no single failure (hardware, software, or governance) can fully compromise the system.
Oasis’s defense-in-depth design represents one of the first large-scale proofs that this philosophy works in production.
While other networks were rebooting enclaves and replacing attestation keys, Oasis simply continued to function. No data loss, no downtime, and no user impact.
For developers, that’s more than just good news, it’s a validation of how to architect secure, resilient confidential compute systems in the real world.
Further Reading
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.