denniswon · April 10, 2026 22:33 · denniswon · Apr 28, 2026 · denniswon · Apr 28, 2026
diff --git a/gistfile1.txt b/gistfile1.txt
  ---
  Meeting: TEE Integration for Newton Protocol

  ---
  Problem Statement

  Newton Protocol accumulates sensitive data (identity PII, confidential data, policy client secrets) that operators must decrypt and
  process during policy evaluation. Two core concerns:

  1. Operator data leakage — operators currently decrypt private data locally, meaning a malicious or compromised operator could exfiltrate
   PII
  2. Regulatory compliance (GDPR) — the safest posture for regulators is that private data is never exposed in plaintext outside a
  hardware-attested environment

  ★ Insight ─────────────────────────────────────
  This maps directly to Newton's existing three-path privacy model: identity data (data.identity.*), confidential data
  (data.confidential.*), and inline ephemeral (data.privacy.inline[0].*). Today, operators decrypt all three paths locally — either with
  their own HPKE key (centralized mode) or via DKG key shares (threshold mode). TEE would move that decryption boundary inside a hardware
  enclave, so operators never see plaintext.
  ─────────────────────────────────────────────────

  ---
  Approaches Evaluated

  ┌─────────────┬─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │  Approach   │     Verdict     │                                             Reasoning                                              │
  ├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ TEE (AWS    │ Chosen          │ Practical, well-documented, prior team experience with Intel TDX, meets GDPR requirements,         │
  │ Nitro)      │                 │ hardware attestation valued by institutional partners                                              │
  ├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │             │ Deferred        │ Jacob called it "Pandora's box" — higher risk, longer timeline, no guaranteed results in 2-4       │
  │ MPC         │ (research       │ weeks. Dennis noted MPC isn't scalable as TEE. Existing DKG/PSS work mitigates some                │
  │             │ phase)          │ operator-leaving risks already                                                                     │
  ├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ FHE         │ Rejected        │ Too expensive, circuit arithmetic limited to basic operations ("very old days of ZK"), not         │
  │             │                 │ practical for Rego evaluation                                                                      │
  ├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ ZK proofs   │ Doesn't solve   │ ZK proves computation correctness but doesn't prevent data decryption — you still need to decrypt  │
  │             │ the problem     │ before running the circuit                                                                         │
  └─────────────┴─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

  ---
  Agreed Architecture

  What goes inside the TEE enclave:
  - Rego policy evaluation only (Phase 1) — where private data is actually loaded and used
  - WASM execution is a secondary step (Phase 2), lower priority since WASM only handles policy client secrets, not PII

  What stays outside the enclave:
  - Application code (operator binary)
  - WASM data provider execution (less sensitive)
  - All non-privacy policy evaluations

  Communication: Enclave ↔ Application via VSOCK (attached secure encrypted channel). No external network connections needed from the
  enclave — it only talks to the local operator application.

  Fallback: If TEE communication fails, fall back to raw (non-enclave) policy evaluation. Only privacy-involved evaluations run inside the
  TEE.

  ┌─────────────────────────────────────────────┐
  │  Operator Process (outside enclave)         │
  │  ┌────────────┐  ┌──────────────────────┐   │
  │  │ WASM Exec  │  │  Operator Service    │   │
  │  │ (data      │  │  (RPC, BLS signing,  │   │
  │  │  provider) │  │   chain interaction) │   │
  │  └────────────┘  └──────┬───────────────┘   │
  │                         │ VSOCK              │
  │  ┌──────────────────────▼───────────────┐   │
  │  │  AWS Nitro Enclave                   │   │
  │  │  ┌──────────────────────────────┐    │   │
  │  │  │ Rego Policy Evaluation       │    │   │
  │  │  │ + Private data decryption    │    │   │
  │  │  │ + HPKE decrypt → eval →     │    │   │
  │  │  │   zeroize → return result   │    │   │
  │  │  └──────────────────────────────┘    │   │
  │  │  Remote Attestation (built-in)       │   │
  │  └──────────────────────────────────────┘   │
  └─────────────────────────────────────────────┘

  ★ Insight ─────────────────────────────────────
  1. Memory is not a concern — Jacob noted TEE memory limits of 256-512 MB per CPU. Dennis confirmed Rego evaluation is lightweight and
  fits comfortably. This is a much smaller footprint than running the full WASM data provider.
  2. The zeroization pattern already exists — Newton already zeroizes decrypted private data outside WASM (lessons.md documents this). TEE
  takes this further by ensuring the plaintext never exists outside the enclave at all.
  3. Secret Network is the closest analog — Wesley identified Secret Network's model as nearly identical: encrypted transactions enter the
  TEE, are decrypted inside a Cosmos SDK runtime, executed, and only the output exits. Newton's model substitutes Rego evaluation for
  Cosmos SDK execution.
  ─────────────────────────────────────────────────

  ---
  Key Design Decisions

  1. AWS Nitro as preferred platform — best performance, mature remote attestation, existing AWS infra alignment. Intel TDX / AMD SEV as
  future portability options (not high priority now).
  2. Every operator runs their own enclave — not a single centralized enclave. Rationale: preserves the operator model where each operator
  independently evaluates. Wesley proposed a single-enclave model but Dennis noted it "kills the purpose of having multiple operators."
  3. Institutional operators, not general validators — Newton targets financial institutions and strategic partners, not Block Daemon /
  Luganodes-style validator shops. These operators are motivated by "I don't want to touch PII data" — TEE gives them hardware-level
  guarantees.
  4. Tiered operator model (Alec's suggestion, Dennis acknowledged) — institutional operators run enclaves for privacy-sensitive work;
  other operators could handle non-sensitive tasks. Operator running is permissioned, staking is permissionless.
  5. No vendor lock-in panic — cloud-native Nitro enclaves (VM-based, not bare metal). Dennis noted no additional pricing overhead beyond
  Nitro-enabled EC2 instances.

  ---
  Concerns Raised

  ┌────────────────────────────────────────┬─────────────┬─────────────────────────────────────────────────────────────────────────────┐
  │                Concern                 │  Raised By  │                                 Resolution                                  │
  ├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
  │ SGX/TDX security gaps (physical access │ Jacob       │ Dennis: these are research-level, not practical threats. Nitro has stronger │
  │  attacks)                              │             │  attestation than SGX                                                       │
  ├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
  │ Vendor lock-in to AWS                  │ Jacob,      │ Accepted as trade-off for speed. Future TDX/AMD support possible            │
  │                                        │ Wesley      │                                                                             │
  ├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
  │ Operator onboarding complexity         │ Wesley      │ Mitigated by targeting institutional operators who can handle it            │
  ├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
  │ Centralization risk                    │ Wesley      │ Each operator runs own enclave. Duplication + fallback for availability     │
  ├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
  │ Operator key compromise on departure   │ Jacob       │ Already mitigated by DKG epoch rotation + upcoming PSS (NEWT-628). TEE adds │
  │                                        │             │  defense-in-depth                                                           │
  ├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
  │ MPC as alternative                     │ Jacob       │ Dennis: not ruled out long-term, but can't be sole bet without a Plan B     │
  └────────────────────────────────────────┴─────────────┴─────────────────────────────────────────────────────────────────────────────┘

  ---
  Action Items

  1. Wesley Coakley — Lead the TEE integration initiative. Draft a detailed technical document covering:
    - Enclave architecture
    - Communication protocols (VSOCK)
    - How Rego policy evaluation runs inside the enclave
    - Staged WASM integration plan
  2. Team — Include TEE-based policy evaluation in upcoming sprint. Start technical exploration immediately (today/tomorrow).
  3. Dennis + team — Monitor MPC as a future alternative while prioritizing TEE now.

  ---
  Relationship to Existing Newton Architecture

  This maps onto the current codebase as follows:

  ┌───────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────┐
  │                     Current Component                     │                               TEE Impact                               │
  ├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
  │ crates/core/src/crypto/envelope.rs (HPKE decrypt)         │ Decryption moves inside enclave                                        │
  ├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
  │ crates/operator/src/core.rs (Rego evaluation with privacy │ Evaluation moves inside enclave                                        │
  │  extensions)                                              │                                                                        │
  ├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
  │ crates/core/src/dkg/ (threshold key management)           │ DKG key shares would be loaded inside enclave only                     │
  ├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
  │ crates/data-provider/ (WASM execution)                    │ Stays outside enclave (Phase 1). Policy client secrets injection may   │
  │                                                           │ move inside later (Phase 2)                                            │
  ├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
  │ Privacy data zeroization (already in place)               │ Becomes hardware-enforced rather than software-enforced                │
  └───────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────┘

  ★ Insight ─────────────────────────────────────
  1. TEE is complementary to the existing DKG/PSS work, not a replacement. DKG handles key rotation so departed operators can't decrypt
  historical data. TEE handles runtime protection so active operators can't exfiltrate plaintext during evaluation. The Phase 2C PSS work
  (PRs #523/#525/#526) remains relevant.
  2. The "only privacy evaluations in TEE" decision is architecturally clean — it means the enclave binary is small (just Rego engine +
  HPKE decrypt), the VSOCK interface is narrow (encrypted input in, boolean/evaluation result out), and non-privacy policies see zero
  performance impact.
  3. Fallback to non-TEE evaluation is a pragmatic choice that matches the existing pattern where the gateway can degrade gracefully (e.g.,
   circuit breaker patterns in crates/gateway/src/task/circuit_breaker.rs).
  ─────────────────────────────────────────────────
	---
	Meeting: TEE Integration for Newton Protocol

	---
	Problem Statement

	Newton Protocol accumulates sensitive data (identity PII, confidential data, policy client secrets) that operators must decrypt and
	process during policy evaluation. Two core concerns:

	1. Operator data leakage — operators currently decrypt private data locally, meaning a malicious or compromised operator could exfiltrate
	PII
	2. Regulatory compliance (GDPR) — the safest posture for regulators is that private data is never exposed in plaintext outside a
	hardware-attested environment

	★ Insight ─────────────────────────────────────
	This maps directly to Newton's existing three-path privacy model: identity data (data.identity.*), confidential data
	(data.confidential.), and inline ephemeral (data.privacy.inline[0].). Today, operators decrypt all three paths locally — either with
	their own HPKE key (centralized mode) or via DKG key shares (threshold mode). TEE would move that decryption boundary inside a hardware
	enclave, so operators never see plaintext.
	─────────────────────────────────────────────────

	---
	Approaches Evaluated

	┌─────────────┬─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐
	│ Approach │ Verdict │ Reasoning │
	├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
	│ TEE (AWS │ Chosen │ Practical, well-documented, prior team experience with Intel TDX, meets GDPR requirements, │
	│ Nitro) │ │ hardware attestation valued by institutional partners │
	├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
	│ │ Deferred │ Jacob called it "Pandora's box" — higher risk, longer timeline, no guaranteed results in 2-4 │
	│ MPC │ (research │ weeks. Dennis noted MPC isn't scalable as TEE. Existing DKG/PSS work mitigates some │
	│ │ phase) │ operator-leaving risks already │
	├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
	│ FHE │ Rejected │ Too expensive, circuit arithmetic limited to basic operations ("very old days of ZK"), not │
	│ │ │ practical for Rego evaluation │
	├─────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
	│ ZK proofs │ Doesn't solve │ ZK proves computation correctness but doesn't prevent data decryption — you still need to decrypt │
	│ │ the problem │ before running the circuit │
	└─────────────┴─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

	---
	Agreed Architecture

	What goes inside the TEE enclave:
	- Rego policy evaluation only (Phase 1) — where private data is actually loaded and used
	- WASM execution is a secondary step (Phase 2), lower priority since WASM only handles policy client secrets, not PII

	What stays outside the enclave:
	- Application code (operator binary)
	- WASM data provider execution (less sensitive)
	- All non-privacy policy evaluations

	Communication: Enclave ↔ Application via VSOCK (attached secure encrypted channel). No external network connections needed from the
	enclave — it only talks to the local operator application.

	Fallback: If TEE communication fails, fall back to raw (non-enclave) policy evaluation. Only privacy-involved evaluations run inside the
	TEE.

	┌─────────────────────────────────────────────┐
	│ Operator Process (outside enclave) │
	│ ┌────────────┐ ┌──────────────────────┐ │
	│ │ WASM Exec │ │ Operator Service │ │
	│ │ (data │ │ (RPC, BLS signing, │ │
	│ │ provider) │ │ chain interaction) │ │
	│ └────────────┘ └──────┬───────────────┘ │
	│ │ VSOCK │
	│ ┌──────────────────────▼───────────────┐ │
	│ │ AWS Nitro Enclave │ │
	│ │ ┌──────────────────────────────┐ │ │
	│ │ │ Rego Policy Evaluation │ │ │
	│ │ │ + Private data decryption │ │ │
	│ │ │ + HPKE decrypt → eval → │ │ │
	│ │ │ zeroize → return result │ │ │
	│ │ └──────────────────────────────┘ │ │
	│ │ Remote Attestation (built-in) │ │
	│ └──────────────────────────────────────┘ │
	└─────────────────────────────────────────────┘

	★ Insight ─────────────────────────────────────
	1. Memory is not a concern — Jacob noted TEE memory limits of 256-512 MB per CPU. Dennis confirmed Rego evaluation is lightweight and
	fits comfortably. This is a much smaller footprint than running the full WASM data provider.
	2. The zeroization pattern already exists — Newton already zeroizes decrypted private data outside WASM (lessons.md documents this). TEE
	takes this further by ensuring the plaintext never exists outside the enclave at all.
	3. Secret Network is the closest analog — Wesley identified Secret Network's model as nearly identical: encrypted transactions enter the
	TEE, are decrypted inside a Cosmos SDK runtime, executed, and only the output exits. Newton's model substitutes Rego evaluation for
	Cosmos SDK execution.
	─────────────────────────────────────────────────

	---
	Key Design Decisions

	1. AWS Nitro as preferred platform — best performance, mature remote attestation, existing AWS infra alignment. Intel TDX / AMD SEV as
	future portability options (not high priority now).
	2. Every operator runs their own enclave — not a single centralized enclave. Rationale: preserves the operator model where each operator
	independently evaluates. Wesley proposed a single-enclave model but Dennis noted it "kills the purpose of having multiple operators."
	3. Institutional operators, not general validators — Newton targets financial institutions and strategic partners, not Block Daemon /
	Luganodes-style validator shops. These operators are motivated by "I don't want to touch PII data" — TEE gives them hardware-level
	guarantees.
	4. Tiered operator model (Alec's suggestion, Dennis acknowledged) — institutional operators run enclaves for privacy-sensitive work;
	other operators could handle non-sensitive tasks. Operator running is permissioned, staking is permissionless.
	5. No vendor lock-in panic — cloud-native Nitro enclaves (VM-based, not bare metal). Dennis noted no additional pricing overhead beyond
	Nitro-enabled EC2 instances.

	---
	Concerns Raised

	┌────────────────────────────────────────┬─────────────┬─────────────────────────────────────────────────────────────────────────────┐
	│ Concern │ Raised By │ Resolution │
	├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
	│ SGX/TDX security gaps (physical access │ Jacob │ Dennis: these are research-level, not practical threats. Nitro has stronger │
	│ attacks) │ │ attestation than SGX │
	├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
	│ Vendor lock-in to AWS │ Jacob, │ Accepted as trade-off for speed. Future TDX/AMD support possible │
	│ │ Wesley │ │
	├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
	│ Operator onboarding complexity │ Wesley │ Mitigated by targeting institutional operators who can handle it │
	├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
	│ Centralization risk │ Wesley │ Each operator runs own enclave. Duplication + fallback for availability │
	├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
	│ Operator key compromise on departure │ Jacob │ Already mitigated by DKG epoch rotation + upcoming PSS (NEWT-628). TEE adds │
	│ │ │ defense-in-depth │
	├────────────────────────────────────────┼─────────────┼─────────────────────────────────────────────────────────────────────────────┤
	│ MPC as alternative │ Jacob │ Dennis: not ruled out long-term, but can't be sole bet without a Plan B │
	└────────────────────────────────────────┴─────────────┴─────────────────────────────────────────────────────────────────────────────┘

	---
	Action Items

	1. Wesley Coakley — Lead the TEE integration initiative. Draft a detailed technical document covering:
	- Enclave architecture
	- Communication protocols (VSOCK)
	- How Rego policy evaluation runs inside the enclave
	- Staged WASM integration plan
	2. Team — Include TEE-based policy evaluation in upcoming sprint. Start technical exploration immediately (today/tomorrow).
	3. Dennis + team — Monitor MPC as a future alternative while prioritizing TEE now.

	---
	Relationship to Existing Newton Architecture

	This maps onto the current codebase as follows:

	┌───────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────┐
	│ Current Component │ TEE Impact │
	├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
	│ crates/core/src/crypto/envelope.rs (HPKE decrypt) │ Decryption moves inside enclave │
	├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
	│ crates/operator/src/core.rs (Rego evaluation with privacy │ Evaluation moves inside enclave │
	│ extensions) │ │
	├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
	│ crates/core/src/dkg/ (threshold key management) │ DKG key shares would be loaded inside enclave only │
	├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
	│ crates/data-provider/ (WASM execution) │ Stays outside enclave (Phase 1). Policy client secrets injection may │
	│ │ move inside later (Phase 2) │
	├───────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────┤
	│ Privacy data zeroization (already in place) │ Becomes hardware-enforced rather than software-enforced │
	└───────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────┘

	★ Insight ─────────────────────────────────────
	1. TEE is complementary to the existing DKG/PSS work, not a replacement. DKG handles key rotation so departed operators can't decrypt
	historical data. TEE handles runtime protection so active operators can't exfiltrate plaintext during evaluation. The Phase 2C PSS work
	(PRs #523/#525/#526) remains relevant.
	2. The "only privacy evaluations in TEE" decision is architecturally clean — it means the enclave binary is small (just Rego engine +
	HPKE decrypt), the VSOCK interface is narrow (encrypted input in, boolean/evaluation result out), and non-privacy policies see zero
	performance impact.
	3. Fallback to non-TEE evaluation is a pragmatic choice that matches the existing pattern where the gateway can degrade gracefully (e.g.,
	circuit breaker patterns in crates/gateway/src/task/circuit_breaker.rs).
	─────────────────────────────────────────────────
No results found