Oasis & TEE Vulnerabilities and Why Oasis Survived the Storm

Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV‑SNP recently hit the news with two nasty physical attacks: Battering RAM & Wiretap. These attacks target memory encryption and can expose attestation keys.

But here’s the kicker: Oasis wasn’t affected. Let’s break it down:

What went down with TEEs

The attacks:

• Extract keys directly from memory using physical access.




• Break the confidentiality guarantees of SGX v2 / SEV‑SNP.




• Affected projects had to patch immediately.

examples: Phala, Secret Network, Crust, IntegriTEE.

Why Oasis stayed safe

Oasis isn’t just “TEE inside blockchain”. it’s layered security:

• Runs critical components (key manager, Sapphire/Cipher runtimes) on older SGX v1, not affected by these attacks.




• Core system doesn’t rely on enclave secrecy for correctness or funds safety.




• Even if a TEE key were compromised, ephemeral keys & rotation reduce risk drastically.

Defense‑in‑Depth

Oasis uses multiple layers to protect users:

• On‑chain governance & staked validators


• Ephemeral key rotation & policy blacklists


• Enclave isolation for sensitive components

Even if a hardware TEE is compromised, consensus, funds, and historical messages stay safe.

Dev Takeaways

• TEEs are powerful but not infallible.


• Layered security > single-point trust.


• Design protocols assuming hardware can fail.

Oasis shows a blueprint for confidential computing done right in Web3.