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 through 2022. It is not protected against the attacks that will be published in 2024, 2026, or 2028 -- 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 encrypted values without ever decrypting them. The privacy guarantee is a property of the mathematics, not of the hardware.

Pedersen commitments are the foundation. A Pedersen commitment on an elliptic curve (BN254 is the standard institutional choice) takes a value and a random blinding factor and produces a commitment that hides the value while preserving a critical algebraic property: the commitments are additively homomorphic. This means that the sum of commitments equals the commitment of the sum. In settlement terms: if each participant commits their obligation amounts, the netting engine can compute net positions by adding and subtracting commitments -- without ever seeing the underlying amounts. The netting computation runs on encrypted values. No enclave. No trusted hardware. No decryption step.

Bulletproofs provide zero-knowledge range proofs -- cryptographic proofs that a committed value lies within a valid range (for example, that an obligation amount is positive and does not exceed a defined limit) without revealing the value itself. Bulletproofs are particularly well suited to settlement because they require no trusted setup. Groth16, an earlier proof system, required a ceremony to generate public parameters -- and if the ceremony was compromised, the proof system's soundness was compromised with it. Bulletproofs eliminate this dependency entirely. Proving time for a single range proof is approximately 70 milliseconds -- operationally viable for settlement windows measured in minutes or hours, where the computational overhead per obligation is negligible relative to the window duration.

AES-256-SIV provides authenticated encryption for metadata -- counterparty identifiers, corridor designations, timestamps, and other structured data that accompanies obligation amounts. SIV (Synthetic Initialization Vector) mode provides deterministic authenticated encryption that is resistant to nonce misuse, a practical consideration in distributed systems where nonce generation cannot be centrally coordinated.

Shamir's Secret Sharing distributes decryption authority across multiple parties using a k-of-n threshold scheme. No single party holds the complete key. Reconstruction requires the cooperation of at least k participants out of n total keyholders. This eliminates the single point of trust that the TEE model concentrates in the hardware manufacturer. If one keyholder is compromised, the privacy of the system is not affected. The threshold can be configured to match the governance requirements of the settlement network.

The performance tradeoff is real. Cryptographic operations on committed values are slower than plaintext operations inside a TEE. Pedersen commitment arithmetic on BN254 is approximately two orders of magnitude slower than native integer arithmetic. But the relevant benchmark is not raw throughput -- it is whether the proving and verification times are compatible with the operational cadence of the settlement system. For netting windows of 30 minutes, two hours, or end-of-day, proof generation times under 100 milliseconds per obligation are operationally invisible. The bottleneck in institutional settlement is not computation. It is coordination, compliance, and finality.

The critical architectural difference: the privacy guarantee does not degrade with hardware generations. It does not depend on a manufacturer's attestation. It is not subject to side-channel attacks, because there is no hardware enclave to attack. The guarantee is mathematical. It holds as long as the discrete logarithm problem on the chosen curve is computationally hard -- a property that has been studied for decades and on which the security of the broader financial cryptographic infrastructure already depends.

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 -- derived from the Shamir's Secret Sharing threshold scheme -- 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 the timelines for this are tightening across G20 jurisdictions -- the ability to deploy FIPS 204 as a software decision, independent of hardware, is an operational advantage.

Where FiatRails stands

FiatRails uses cryptographic privacy for its settlement infrastructure. The privacy model is built on Pedersen commitments for amount confidentiality with additive homomorphism on BN254, Bulletproofs for zero-knowledge range proofs without trusted setup, AES-256-SIV for metadata encryption, and Shamir's Secret Sharing for threshold key distribution. Post-quantum digital signatures using ML-DSA (FIPS 204) are deployed alongside the classical cryptographic stack.

There is no trusted execution environment in the architecture. No hardware manufacturer serves as a root of trust. No remote attestation chain is required to verify privacy. The privacy guarantee is mathematical.

Supervisory observability is provided through a tiered view key architecture: governance-level, corridor-level, participant-level, and delegate-level access, each scoped, time-bounded, and revocable with an on-chain audit trail. The model is designed for the regulatory reality that central banks, prudential supervisors, and compliance teams face -- not as an afterthought to a hardware-first privacy design, but as a foundational architectural requirement.

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. For institutional settlement, the mathematics is the stronger foundation.

This article is part of the FiatRails 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.