Privacy in settlement infrastructure is not a feature. It is an architectural decision that determines the root of trust, the attack surface, the supervisory model, and the long-term viability of the system under regulatory scrutiny. Two fundamentally different approaches exist. One delegates privacy to hardware manufacturers. The other derives it from mathematics. For institutional settlement -- where participants include banks, payment service providers, and central bank supervisors -- the choice between them is not a performance tradeoff. It is a question of what the institution is willing to trust, who can verify that trust, and what happens when the trust assumption fails.

This distinction matters now because privacy-preserving settlement is moving from academic literature into production infrastructure. The decisions made today about which privacy model to build on will determine whether the resulting systems can satisfy the regulatory, supervisory, and adversarial requirements that institutional participants face. Not all privacy is equal. The mechanism matters.

The hardware trust model

Trusted execution environments -- Intel SGX, AMD SEV, ARM TrustZone -- provide a hardware-based approach to confidential computation. The model works as follows: a processor reserves a region of memory, called an enclave, that is isolated from the rest of the system. Code and data loaded into the enclave are encrypted in memory. The operating system, the hypervisor, and other software on the machine cannot read the enclave's contents. Computation runs inside the enclave at near-native processor speed, and the results are returned to the calling application.

The security model rests on two assumptions. First, that the hardware correctly isolates the enclave from all other software and firmware on the machine. Second, that the hardware manufacturer can attest -- through a cryptographic protocol called remote attestation -- that a specific enclave is running specific code on genuine hardware that has not been tampered with. Remote attestation is the mechanism by which a user verifies that the enclave is doing what it claims to do. The attestation chain terminates at the manufacturer. Intel signs the attestation for SGX. AMD signs it for SEV. The manufacturer is the root of trust.

This model has a genuine performance advantage. Because computation runs on the processor in plaintext inside the enclave, TEE-based privacy operates at near-native speed. There is no cryptographic overhead on each operation. For workloads that require high throughput on large datasets, this is a meaningful benefit. It is the reason TEEs are used in cloud computing, database confidentiality, and other contexts where performance constraints are tight and the threat model is primarily concerned with software-level adversaries.

For settlement infrastructure, the TEE model means that participants encrypt their obligations and submit them to an enclave. The enclave decrypts the data, runs the netting computation in plaintext, and produces the net settlement positions. Privacy is maintained as long as the enclave isolation holds. The netting algorithm itself is not modified -- it runs on cleartext values inside the enclave, exactly as it would without any privacy layer. The privacy is a property of the execution environment, not of the computation.

This is the core architectural point: in the TEE model, the computation is not private. The environment is private. Privacy is a physical property of the hardware, enforced by the manufacturer's design and verified by the manufacturer's attestation. If the physical property holds, the privacy holds. If it does not, the privacy fails -- and the failure may not be detectable by the participants whose data was exposed.

The vulnerability surface

The physical isolation that TEEs depend on has been violated repeatedly in published academic research. This is not a theoretical concern. It is a documented, peer-reviewed, multi-generational record of successful attacks against enclave isolation.

SGX.Fail, a research compilation maintained by Stephan van Schaik and collaborators (2022), catalogs multiple classes of side-channel attacks against Intel SGX. The attacks exploit microarchitectural properties of the processor -- speculative execution, cache timing, power analysis, memory bus snooping -- to extract data from enclaves without violating the software isolation model. The enclave remains "isolated" in the sense that no software can directly read its memory. But the physical side channels leak information through observable properties of the hardware's behavior.

The named attacks span several generations:

  • Spectre and Meltdown (2018) demonstrated that speculative execution could be exploited to read arbitrary memory, including enclave memory, across process boundaries.
  • Foreshadow (L1 Terminal Fault, 2018) specifically targeted SGX enclaves, extracting attestation keys and sealed data.
  • Plundervolt (2019) used software-controlled undervolting to induce computational faults inside enclaves, bypassing integrity guarantees.
  • LVI (Load Value Injection, 2020) reversed the direction of Meltdown-type attacks to inject values into enclave computation.
  • AEPIC Leak (2022) demonstrated that certain data could be read from enclaves through the Advanced Programmable Interrupt Controller without any side channel at all -- a direct architectural data leak.

Each of these attacks was disclosed, and Intel issued microcode patches and software mitigations. Each patch addressed a specific vulnerability. But the pattern is structural: the attacks exploit physical properties of the silicon, and each new processor generation introduces new microarchitectural features that create new side-channel opportunities. The patches address specific instances. They do not address the architectural class. A settlement system built on SGX today is protected against the attacks published so far. It is not protected against those still to come -- because those attacks will target microarchitectural properties that do not yet have mitigations.

AMD SEV has faced a parallel trajectory. SEVered (2018), SEV-SNP attacks, and CacheWarp (2023) demonstrate that AMD's approach to memory encryption and integrity is subject to similar classes of physical side-channel exploitation.

Beyond side-channel attacks, the TEE model introduces a collusion risk that is absent from cryptographic approaches. TEE operators -- the entities that control the physical hardware running the enclaves -- have privileged access to the machines. Published research has acknowledged that a sufficient number of colluding TEE operators could potentially extract private data from enclaves, and that such a breach of privacy may not be detectable or provable after the fact. For institutional settlement data -- where exposure of obligation amounts and counterparty identities could constitute material non-public information -- an undetectable privacy breach is not a tolerable risk class.

The cryptographic alternative

Cryptographic privacy takes a fundamentally different approach. Instead of running plaintext computation inside an isolated hardware environment, it transforms the data itself so that useful computation can be performed on committed values without ever decrypting them. Obligation amounts are committed rather than revealed, and the netting arithmetic runs on the commitments; range proofs establish that committed values are valid without disclosing them; metadata is encrypted under authenticated schemes; and decryption authority is distributed so that no single party holds a complete key.

The performance trade-off is real: arithmetic on committed values is slower than plaintext arithmetic inside an enclave. But the relevant benchmark is not microseconds; it is the settlement window, and cryptographic netting comfortably fits inside it.

The critical architectural difference: the privacy guarantee does not degrade with hardware generations. It does not depend on a manufacturer's attestation. It removes the enclave and the manufacturer's attestation chain as an attack surface; residual side-channel risk sits in the implementation, where it can be audited in open code rather than in silicon.

Why the distinction matters for institutional settlement

For a technology startup building a privacy-preserving analytics tool, the choice between TEE and cryptographic privacy is a legitimate engineering tradeoff. TEEs offer simplicity and performance. Cryptographic approaches offer stronger guarantees at higher computational cost. Reasonable engineers can choose differently depending on the threat model.

For institutional settlement infrastructure -- where participants are banks, payment service providers, and central bank supervisors -- the threat model is not the same, and the tradeoff calculus changes accordingly.

Supervisory observability requires granularity. Central banks and prudential supervisors do not want all-or-nothing access to settlement data. They require tiered, scoped, revocable access: a corridor supervisor sees positions within their corridor but not others; a participant sees their own obligations but not their counterparties'; an auditor receives time-bounded access to historical records that expires when the audit concludes. Cryptographic view keys, with key custody distributed by threshold secret sharing, support this granularity natively. A view key can be scoped to a specific corridor, a specific participant, a specific time range, and a specific data class. It can be granted and revoked on-chain with an auditable trail. TEE-based privacy is architecturally binary: either the party has access to the enclave, or it does not. The granular, scoped, revocable observability that supervisors require is not a natural property of the hardware trust model.

Regulatory confidence depends on verifiable guarantees. When a regulator evaluates a privacy model, they need to understand what the guarantee is, what it depends on, and how it can be verified. A mathematical proof -- this commitment hides this value, this range proof demonstrates validity, this view key grants exactly this scope of access -- is auditable by any competent cryptographer. Hardware attestation is a probabilistic trust statement: the manufacturer certifies, with a given confidence level, that this enclave is running this code on this hardware. The regulator must then evaluate the manufacturer's attestation infrastructure, the history of side-channel vulnerabilities, and the manufacturer's patching cadence. For a central bank evaluating settlement infrastructure that will process sovereign payment flows, the auditability of mathematical guarantees is a structural advantage over the opacity of hardware attestation chains.

The adversary model is nation-state grade. Institutional settlement data -- who owes whom, how much, in which currencies, through which corridors -- is high-value intelligence. The adversaries capable of and motivated to extract this data include nation-state intelligence services with access to hardware supply chains, microarchitectural research capabilities, and the resources to develop novel side-channel attacks. The published academic literature on TEE vulnerabilities represents what researchers have found and disclosed. The classified capability of well-resourced adversaries is, by definition, unknown. Cryptographic privacy does not eliminate all attack vectors -- implementation bugs, key management failures, and protocol design errors remain possible. But it eliminates the hardware supply chain as an attack surface entirely. For institutional settlement, that reduction in attack surface is material.

Post-quantum readiness is a deployment decision, not a hardware dependency. Lattice-based digital signature schemes -- specifically ML-DSA (FIPS 204), standardised by NIST -- are deployable today in cryptographic architectures as a software update. Post-quantum signatures can coexist with classical elliptic curve cryptography during the transition period. TEE-based systems inherit whatever post-quantum capability the hardware manufacturer has implemented in their attestation and enclave infrastructure. The timeline for post-quantum TEE hardware is determined by the manufacturer's product roadmap, not by the settlement system operator. For institutions that must demonstrate post-quantum preparedness to their supervisors -- and NIST IR 8547 sets the timeline (deprecation of quantum-vulnerable algorithms from 2030, disallowed by 2035) -- the ability to deploy FIPS 204 as a software decision, independent of hardware, is an operational advantage.

Where NETTA stands

NETTA's privacy is cryptographic, not hardware-based: homomorphic netting on committed values, no master key, no trusted hardware, no trusted setup, and post-quantum signatures and key encapsulation. There is no trusted execution environment in the architecture; no hardware manufacturer serves as a root of trust. Supervisory observability is provided through tiered view keys that are scoped, time-bounded and revocable, with an audit trail.

NETTA's runtime is Qedis, owned by Digitalyze Labs Ltd and perpetually licensed to the NETTA group; the Foundation holds its own privacy filing. Technical detail is available under NDA.

The choice between hardware trust and cryptographic privacy is not abstract. It determines what regulators can verify, what supervisors can observe, what adversaries can exploit, and what the system's privacy guarantees will look like in five years when the next generation of side-channel research is published.

This article is part of the NETTA Insights series on institutional settlement infrastructure. Other articles in the series examine what multilateral netting is and how it works, the empirical case against universal atomic settlement, MiCA's gap for digital asset settlement, the current state of the Settlement Computer, and the distinction between set-off and settlement netting.