Study Real Web2 and Web3 Architectures

What you will learn

This lesson studies how TEE components are arranged in:

Confidential AI
Data clean rooms
Secure credential processing
Private order flow
Off-chain coprocessing
On-chain attestation
Decentralized TEE networks

Case study method

For every TEE system, ask:

1. What runs inside the TEE? 2. What remains outside? 3. Who operates the hardware? 4. Who controls the reference measurement? 5. Who verifies attestation? 6. How are keys released? 7. How is state stored? 8. How are updates handled? 9. What metadata remains visible? 10. What happens if the operator stops responding? 11. What happens if the hardware vendor is compromised? 12. Is a TEE necessary?

Web2 pattern 1: Confidential AI inference

Problem

A company wants to use an AI model without revealing:

User prompts to the infrastructure operator
Model weights to the customer
Private enterprise documents to the model provider

Architecture

Possible components:

User client
Attestation verifier
Confidential VM
Confidential GPU
Model server
KBS
Encrypted model storage
Privacy-safe logging

Flow

1. Workload starts. 2. CPU and GPU evidence is collected. 3. Verifier checks expected software and device state. 4. KBS releases model and data keys. 5. Client establishes an attested channel. 6. Prompt and model are decrypted in protected memory. 7. Inference runs. 8. Output is encrypted to the client.

Confidential AI architecture showing an encrypted client request, CPU and GPU attestation, verifier-approved model-key release, protected inference, and encrypted response to the client.

Remaining risks

Prompt length
Output length
Token timing
Model vulnerabilities
Unsafe output
Client compromise
Availability
Device-side leakage

Web2 pattern 2: Data clean room

Problem

Several organizations want to calculate a result over combined datasets without sharing raw records.

Architecture

Participant A
Participant B
Participant C
Verifier
Approved analytics workload
KBS
Confidential VM or enclave
Output policy

Flow

1. Participants agree on the source code or measurement. 2. Each participant verifies the workload. 3. Each participant encrypts data to the attested key. 4. Workload combines datasets. 5. Workload applies output policy. 6. Aggregate result is returned.

Data clean room architecture where multiple participants send encrypted datasets to an attested TEE workload, which performs confidential analytics and releases only a policy-approved aggregate result.

Remaining risks

Malicious participant input
Small-group output leakage
Repeated queries
Query differencing
Operator censorship
Side channels
Unsafe analytics code

💡

The TEE hides computation from infrastructure operators. It does not make every statistical result private. Output policy and minimum group size remain required.

Web2 pattern 3: Secure credential service

A TEE or isolated enclave may protect:

Token signing
Password verification
API-key processing
Certificate issuance
Payment tokenization

The design should expose policy-controlled operations rather than raw keys.

A credential TEE should track:

Who requested the operation
What policy allowed it
Whether the request is fresh
Whether the state can be rolled back
Whether duplicate instances can sign

Web3 pattern 1: Private order flow

Problem

Public transaction intent can allow:

Front-running
Sandwich attacks
Copy trading
Strategy extraction
Adverse transaction ordering

TEE architecture

Users encrypt orders to an attested block-building or matching workload.

The TEE:

1. Decrypts private intent. 2. Applies an ordering or matching rule. 3. Creates an output batch. 4. Signs or attests to the result. 5. Publishes settlement data.

Private order flow architecture where users send encrypted transaction intentions to an attested TEE, which privately applies matching or ordering rules and publishes the resulting batch for blockchain settlement.

Remaining risks

Operator censorship
Selective inclusion
Incorrect ordering code
Rollback
Side-channel leakage
Attestation centralization
Public settlement metadata
Availability

Flashbots currently describes BuilderNet as a block-building network running on TEEs, and Rollup-Boost as using TEE information-security properties for verifiable priority ordering.

The architecture should be evaluated through its actual code, measurement, operator set, and verification flow rather than through a general "TEE-powered" label.

Web3 pattern 2: Off-chain coprocessor

Problem

A smart contract needs computation that is:

Too expensive on-chain
Private
Stateful
Dependent on external data
Difficult to express as a ZK circuit

Flow

1. Contract emits a request. 2. TEE worker receives input. 3. Worker verifies on-chain state. 4. TEE performs computation. 5. TEE signs output. 6. Contract verifies approved TEE identity. 7. Contract applies result.

Main questions

How does the TEE read canonical chain state?
Can the host provide a fake chain view?
Can the operator withhold results?
Can two workers return conflicting outputs?
How is attestation verified on-chain?
How are revoked machines removed?
Is output correctness independently checked?

Web3 pattern 3: Decentralized TEE cloud

A decentralized TEE network may allow independent operators to run confidential workloads.

Phala's current documentation describes confidential applications and off-chain computation deployed through TEE-based cloud infrastructure, including confidential virtual-machine deployment and attestation inspection.

Marlin Oyster documentation provides tooling to verify AWS Nitro attestation, expected measurements, root keys, user data, and evidence freshness. It warns that production verification should include expected measurements rather than checking only the document structure and certificate chain.

The important lesson is that decentralizing operators does not automatically decentralize:

Hardware roots
Attestation roots
Measurement policy
Software releases
Key release
Governance

Web3 pattern 4: On-chain attestation verification

Smart contracts may verify or consume evidence about a TEE.

Automata currently documents verifier contracts for Intel SGX, Intel TDX, AMD SEV-SNP, and AWS Nitro attestation families.

On-chain verification can improve:

Auditability
Reuse of verified machine identity
Smart contract integration
Public policy enforcement

It also introduces:

Gas or proving cost
Complex certificate parsing
Collateral updates
Revocation management
Contract upgrade risk
Dependence on vendor roots

Oracle warning

A TEE-backed oracle can prove which oracle program processed data.

It does not prove that:

The external source was truthful.
The HTTPS endpoint was honest.
The host did not block one source.
The application chose the correct source.
The economic result is safe.

The data origin remains part of the trust model.

Case-study worksheet

For each real system, fill in:

`` Protected asset: TEE platform: Trusted code: Untrusted code: Operator: Attestation verifier: Reference-value owner: Secret provider: Persistent state: Rollback control: User verification: Output verification: Availability dependency: Main metadata leakage: Fallback: ``

Developer exercise

Choose one system:

Confidential AI
Private order flow
TEE oracle
Data clean room
Decentralized TEE cloud

Create:

1. Architecture diagram 2. Trust boundary 3. Attestation flow 4. Key-release flow 5. State flow 6. Five remaining risks 7. One alternative design without a TEE

Common mistakes

⚠

**Treating project documentation as independent proof** — Verify actual code, measurements, and verification flow. **Assuming signed output proves correct input data** — TEE output proves the program ran; it does not validate data sources. **Calling a network decentralized because operators are distributed** — Hardware roots and measurement authority may still be centralized. **Ignoring operator censorship** — An operator can stop submitting requests without breaking TEE security. **Ignoring public blockchain metadata** — On-chain state commitments and settlement transactions are visible. **Checking hardware identity but not workload measurement** — A known TEE hardware platform can run an approved or malicious workload. **Trusting an oracle because it runs in a TEE** — The oracle's data source and selection logic are separate trust questions.

Key takeaways

Study complete architectures, not product labels.
Web2 and Web3 systems share the same core TEE problems.
Attestation proves selected state claims, not full correctness.
Decentralized operators may still share one hardware root.
On-chain verification adds transparency but increases operational complexity.
Every case study should identify remaining leakage and availability dependencies.

Check your understanding

1. What does a TEE-backed oracle fail to prove? 2. Why can a data clean room leak through its outputs? 3. What central trust may remain in a decentralized TEE network? 4. Why should an on-chain verifier track attestation collateral? 5. What risks remain in private order flow after encryption?