feat: update TEE+ZK settlement, private trade settlement, and add network anonymity pattern

[Meyanis95]

Summary

• New pattern-network-anonymity.md: Transport-layer sender anonymity for both reads and writes via TEE-assisted secret sharing (based on Flashbots Flashnet research). Addresses the who layer that existing content-privacy patterns miss — hides IP, timing, and query-to-identity mapping.
• Enhanced pattern-tee-zk-settlement.md (Issue feat(pattern): update pattern-tee-zk-settlement.md and update with recent learnings #79): Expanded from ~250 to ~1200 words with trust framework, TEE API surface, stealth address time-locked notes design, anti-pattern table, and concrete cross-border bond DvP example with failure path
• Restructured approach-private-trade-settlement.md (Issue feat(approaches): update approach-private-trade-settlement.md: propose implementation approaches for single-chain and cross-chain #77): Separated single-chain (shielded pool DvP, privacy L2) from cross-chain (TEE+ZK, MPC/threshold, intent-based) approaches with explicit trust models, trade-off matrices, and privacy set discussion. References approach-dvp-atomic-settlement.md for atomicity primitives instead of duplicating
• Refreshed pattern-tee-based-privacy.md: Added CPU-encrypted vs hypervisor-isolated platform classification and threat model comparison table (SGX/SEV vs Nitro)

Key design decisions

• Same-network = true atomicity is the organizing principle — cross-chain approaches are presented as trust tradeoffs, not equivalents
• TEE+ZK pattern incorporates learnings from atomic swap design iterations (8 failed approaches → stealth address with time-locked notes as winner)
• Approach doc complements (not duplicates) approach-dvp-atomic-settlement.md — focuses on privacy layer, links to DvP doc for escrow/HTLC mechanics
• TEE-based privacy now distinguishes hardware TEEs (CPU-encrypted memory, protects from cloud provider) from VM TEEs (hypervisor-isolated, operationally simpler but trusts cloud provider)
• Network anonymity pattern captures the who vs what distinction — TEEs provide liveness, cryptography provides anonymity (clean separation of concerns)

Test plan

• npm run validate — passes (word count warning on patterns expected, under error threshold)
• npm run check-terms — passes, all canonical GLOSSARY.md terms used
• Internal links verified
• CHANGELOG.md updated

Closes #77, closes #79

🤖 Generated with Claude Code

[rymnc]

do we need phasing in the approach doc?

[Meyanis95]

It's not a hard requirement, but it's a way to classify approaches' scope by maturity.

[rymnc]

we should recommend that if the tee approach is used, and the proof system makes use of a gpu, the gpu should also support TEEs: https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/

and that the gpu attestation should be verified in the cpu tee, to improve security

[rymnc]

ref Phala network security disclosure

[rymnc]

• The host operator (not just the hardware vendor) can intercept, reorder, drop, replay, and inject all messages between the enclave and external systems, making the infrastructure operator a primary trusted party.
• Vsock metadata (packet sizes, processing duration, connection counts) leaks trade timing and size information even without breaking enclave confidentiality, enabling front-running.
• TEE-only deployments without constant-time cryptography remain vulnerable to cache timing and speculative execution side-channels that can extract plaintext order data.
• A single TEE coordinator is a single point of compromise; threshold key distribution across multiple TEE instances operated by independent parties is required before production use.
• Attestation verification must pin specific PCR values (not just PCR0), validate the full certificate chain to the hardware vendor root CA, and enforce measurement freshness to prevent enclave code substitution.
• The 24h timeout is also a griefing vector: a malicious operator can selectively stall settlement to lock counterparty capital while market conditions change.
• TEE trust is weaker than HSM trust along every axis (no physical tamper resistance, large attack surface, documented side-channel history), so institutional HSM acceptance does not transfer to TEEs without additional defense layers.

based on https://docs.bluethroatlabs.com

[Meyanis95]

addressed in c0ba732

[oskarth]

Can we decople network level anonymity from being solved with TEE? To me they seem like two different things? E.g. diff ways to get network anonymtiy

[oskarth]

This one seems specifically about TEE based approach (not clear from filename)

[Meyanis95]

Good point!
Addressed in 4279b81

[oskarth]

Skimmed some parts and focused on high-level, overall looks good!

Re lint: I suggest either fixing issues or adjusting lint to be less aggressive

[oskarth]

This one seems specifically about TEE based approach (not clear from filename)

[oskarth]

I think there are quite a few research groups looking into TEE open stack security etc

Probably a good idea to reference some of these as external links? Otherwise our summary seems a bit random maybe

[Meyanis95]

Addressed in 57a0c97