Skip to main content

​
Overview

Notional operates in a multi-layered environment involving TEE infrastructure, guardian multisigs, external venues, and oracle dependencies. This page outlines the major risk categories, potential attack vectors, and the mitigations implemented to protect user funds and ensure system integrity.

​
Risk Categories

​
Compromised Operator or Guardian Set

The protocol separates execution authority between the Operator (running in TEE) and the Guardian multisig to limit the blast radius of any single compromise.
A compromised operator may attempt to:
  • Produce incorrect state transitions
  • Submit unauthorized trades
  • Manipulate liquidation triggers
  • Access TEE-stored secrets
  • Operator cannot move funds without guardian approval
  • Operator wallet has trading-only permissions (no withdrawal authority)
  • All state transitions recorded in immutable event log
  • Guardians can revoke operator’s trading wallet at any time
  • TEE attestation ensures operator runs verified code
A compromised guardian majority (3 of 5) could:
  • Approve malicious withdrawals
  • Enable a rogue operator
  • Halt system operations
  • Requires coordinated collusion (3 of 5 guardians)
  • Distributed guardian set reduces likelihood of coordinated attack
  • All guardian actions logged on-chain for transparency
  • Guardian set can be rotated if compromise detected
  • Time delays on critical operations provide reaction window
Guardian compromise is the highest-severity risk. The initial guardian set is intentionally distributed across independent parties to minimize collusion risk.

​
Infrastructure-Level Attacks

The protocol relies on Azure infrastructure, AMD SEV-SNP hardware, and network connectivity. Compromise at these layers could affect system availability or expose secrets.
Azure or AMD hardware compromise may enable:
  • Memory inspection of TEE
  • Key extraction from secure enclaves
  • Code injection into running VM
  • Network traffic interception
  • Azure Secure Key Release (SKR) ties key access to valid attestation
  • Hardware attestation verifies code integrity before key release
  • Memory encryption by AMD CPU prevents host-level inspection
  • Long-term plan: diversification across TEE vendors (Intel TDX, Nitro Enclaves)
  • Even with extracted keys, operator remains restricted to trading-only permissions
Network partitions or DDoS attacks may:
  • Prevent block production
  • Delay liquidations
  • Cause stale oracle prices
  • Block user withdrawals
  • Guardian-controlled keys enable network restart from canonical state
  • Fully replayable event log allows state reconstruction
  • Backup operators can assume control during outages
  • Multi-region deployment reduces single point of failure
Infrastructure attacks cannot bypass guardian-controlled withdrawals or alter canonical state. The separation of concerns limits damage even under partial system compromise.

​
TEE Security Boundaries

The Trusted Execution Environment (TEE) provides hardware-level security guarantees that protect against many attack vectors, but also has known limitations that must be understood. What TEE Protects Against
Azure cannot read VM memory, inject code, or extract keys. All computation encrypted by AMD CPU with SEV-SNP technology.
Even with root access to host OS, attacker cannot break into TEE. Memory encryption enforced by hardware, not software.
All external communication over TLS. Remote attestation prevents MITM attacks by cryptographically proving VM identity.
Measured boot ensures only authenticated code runs. Any code modification detected via attestation verification.
Known TEE Limitations
TEE technology does not protect against:
  • Side-channel attacks - Speculative execution vulnerabilities (e.g., Spectre, Meltdown) and cache timing attacks
  • Physical access - Direct CPU access with lab equipment can potentially extract secrets
  • Supply chain compromise - Compromised AMD signing keys would undermine attestation trust
  • Firmware bugs - Vulnerabilities in SEV-SNP firmware (mitigated through platform security version updates)
See Protocol Architecture for detailed technical implementation including attestation, secure key release, and measured boot.

​
Oracle Price Manipulation

Accurate price feeds are critical for margin calculations, liquidations, and collateral valuations. Manipulated or stale prices can cause incorrect liquidations or enable exploitative withdrawals.
Compromised or delayed price feeds may cause:
  • Incorrect margin health calculations
  • Premature liquidations (prices artificially low)
  • Delayed liquidations (prices artificially high)
  • Opportunistic withdrawals during price lag
  • Bad debt accumulation during volatile periods
  • Primary source: Hyperliquid mark prices (robust against manipulation)
  • Self-hosted oracle nodes run by operator and guardians
  • Fallback to public Hyperliquid nodes on infrastructure failures
  • Real-time WebSocket feeds minimize staleness
  • Future: Oracle diversity with deviation detection
During illiquid or volatile periods, price accuracy becomes even more critical. The protocol uses Hyperliquid’s battle-tested mark price system, which aggregates multiple sources and applies impact mid-price calculations.

​
Operational Liveness Risks

System outages can temporarily halt trading, liquidations, and withdrawals, potentially exposing users to market risk during downtime.
Outages may result from:
  • TEE attestation failures
  • Cloud infrastructure failures
  • Software bugs or crashes
  • Network partitions
  • Operator key compromise requiring revocation
  • All critical keys are guardian-controlled, not operator-dependent
  • Complete state stored in immutable event log
  • Backup operators can assume control with guardian approval
  • Network can be safely restarted from canonical data
  • Hot standby systems enable rapid failover
Temporary liveness failures do not result in loss of funds. The system is designed for safe recovery from any failure scenario with full state reconstruction.

​
Risk Summary

Critical Risks

  • Guardian compromise (3 of 5)
  • Prolonged oracle failures
  • TEE hardware vulnerabilities

Mitigated Risks

  • Operator compromise (trading-only)
  • Cloud provider attacks (SKR + attestation)
  • Network outages (backup operators)
  • Stale prices (self-hosted oracles)

​
Responsible Disclosure

If you discover a security vulnerability, please report it to: [email protected] We follow a coordinated disclosure process and offer bug bounties for qualifying vulnerabilities.

​
Next Steps

Architecture

System architecture and TEE security

Liquidations

Risk management and liquidation system

Collateral

Multi-asset collateral system

Venue Adapters

Integration with trading venues