Confidential Compute

TEE Attestation

Aethelred uses a multi-TEE verification framework supporting Intel SGX, AWS Nitro, AMD SEV-SNP, and NVIDIA H100 Confidential Computing. Data enters the enclave encrypted, is processed in isolation, and exits as an attested result. The validator does not see plaintext input, and the resulting quote is validated against chain-specific binding rules before it can contribute to Proof-of-Useful-Work or a Digital Seal. Pair this surface with zkML proofs when a workload needs hybrid verification.

Blind Compute 4 Platforms EVM 0x0400 1.5x TEE Bonus

Review Platforms Open ZK Surface

CURRENT MULTI-TEE MODEL

Blind compute is a protocol primitive

Encrypted data enters the enclave, is processed in isolation, and exits only as an attested result bound to the workload.

Production checks are explicit

Signature validation, measurement lookup, quote schema checks, timestamp bounds, and chain binding are required in production mode.

Economics reward secure hardware

TEE-equipped validators receive a 1.5x compute bonus multiplier, with hardware-specific fee multipliers reflecting operating cost and security level.

4 Platforms Current multi-TEE framework

2.3s Achieved attestation time

100,000 AETHEL Validator minimum stake

Overview

TEE attestations are the current hardware-backed trust surface

This page reflects the current production model in the March 2026 whitepaper and tokenomics. TEE attestation is one of the documented verification modes per job, and it is the foundation of Aethelred's blind-compute posture for regulated and confidential workloads.

BLIND

Why TEEs Matter

Confidential execution without trusting the validator with plaintext data

Aethelred's sovereign privacy model describes blind compute: sensitive data enters a hardware Trusted Execution Environment encrypted, is processed in isolation, and exits as an attested result. This is the hardware-backed path for workloads where the operator should verify execution but must not see the underlying data.

Best Fit

Medical, financial, private-model, and jurisdiction-sensitive inference where confidential execution is part of the trust model.

Protocol Role

The validator includes the TEE quote inside vote-extension verification data so consensus can reason about both compute and evidence.

Proof Surface TEE attestation stands alone for hardware-backed assurance and also pairs with zkML proofs in hybrid mode.

Contract Surface The current developer docs expose the TEE precompile at 0x0400 for smart-contract level attestation flows.

Operator Surface Validators are documented as TEE-capable GPU servers with HSM-aware operational flows and a 100,000 AETHEL minimum stake.

QUOTE

Attestation Model

The quote is useful only when it is bound to the exact workload and chain context

The current attestation document binds enclave measurement, input hash, output hash, block height, and chain ID. Production mode rejects simulated platforms and unbound attestations because a quote that is not attached to chain context is replayable and therefore not trustworthy enough for consensus evidence.

Validation Surface

Quote format, measurement registry lookup, timestamp skew, signature validation, and binding hash checks all happen before acceptance.

Consensus Outcome

Accepted attestations become part of the evidence set that can support a Digital Seal when the network reaches supermajority agreement.

Seal Access Full TEE attestation records are exposed through the seal query surface once a result is promoted into a seal.

Developer Rehearsal The Infinite Sandbox and documented devnet path let teams inspect the operational behavior before public rollout.

Tooling Support The current VS Code extension includes in-editor TEE simulation to keep iteration local until the workflow is ready.

Supported Platforms

Precompile

0x0400

Achieved Attestation

2.3s

TEE Bonus

1.5x

Verification Reward

100 uaeth

Platforms

The current multi-TEE framework and its fee profile

The whitepaper and tokenomics document the active hardware environments below. The fee multipliers reflect the cost and assurance profile of each environment, while the protocol itself verifies attestation data against the correct platform-specific rules.

Platform	Attestation Path	Current Role	Fee Multiplier
Intel SGX	SGX DCAP quote	Enclave-backed verified inference	1.2x
AWS Nitro Enclave	Nitro NSM document	Cloud-isolated confidential compute	1.5x
AMD SEV-SNP	SEV-SNP attestation report	Confidential VM execution for validator inference	1.2x
NVIDIA H100 Confidential	Confidential GPU attestation	Highest-assurance GPU workloads	2.0x

Hardware choice is an economic and operational decision

The protocol rewards stronger confidential-compute postures, but the platform should still match the workload, the deployment model, and the operational maturity of the validator team.

Open Verification Tools

Binding Rules

Attestations are bound to the exact chain and block context

A quote without chain context is replayable. The current production model binds attestation data to workload output, block height, and chain identity before the network will treat it as valid evidence.

tee binding

UserData = SHA-256(output_hash || LE64(block_height) || chain_id)

BIND

Required Fields

What the protocol expects inside the attestation record

Enclave measurement or equivalent code identity.
Input hash and output hash for the workload.
Block height and chain ID binding for replay protection.
Platform-specific quote structure that matches the selected TEE type.

TIME

Replay Resistance

The timestamp window is deliberately narrow

Attestation timestamps are validated within a 10-minute past window and a 1-minute future window relative to block time.
Cross-chain and cross-block replay are blocked by the user-data binding rule.
Measurement registry lookup ensures the quote maps to a trusted code identity before acceptance.

Production Guards

Current production mode is designed to fail closed

The whitepaper explicitly states that a three-layer defense prevents simulated verification from reaching production, while vote-extension verification rejects malformed, unsigned, or insufficiently bound attestation data.

GATE 01

Build-tag enforcement

The production build tag forces a compile-time production flag so runtime configuration cannot quietly switch the node back into simulated behavior.

GATE 02

One-way governance gate

AllowSimulated can move from true to false, but once disabled it cannot be re-enabled through governance.

GATE 03

Runtime readiness checks

The first production BeginBlock runs readiness checks and panics if the environment does not meet the required security posture.

VERIFY

Vote Extension Checks

What peers validate on incoming attestation data

Signature verification against the validator consensus key.
Timestamp skew validation before accepting quote freshness.
Platform-specific schema validation and measurement registry lookup.
Binding-hash verification and job existence checks on-chain.

REJECT

Explicit Rejections

What production mode refuses to accept

Unsigned vote extensions.
Simulated TEE platforms.
Attestations missing block-height and chain-ID binding.
Quotes that do not resolve cleanly against the trusted measurement registry.

Operations

Current economics and operator implications

TEE use is not only a security posture. It also changes validator economics, deployment requirements, and the rehearsal path through tools, devnet, and the foundation node standards.

Surface	Current Value	Why It Matters
Validator Entry	100,000 AETHEL minimum stake	The current validator profile is a TEE-capable GPU server participating in consensus and AI inference.
Compute Bonus	1.5x reward multiplier	TEE-equipped validators receive additional reward weight reflecting hardware cost and security guarantees.
Verification Reward	100 uaeth per verified job	Attestation-backed verification contributes directly to validator revenue alongside PoUW rewards and fees.
Devnet	10 services, 3 validators on heterogeneous TEE platforms	The local environment already mirrors the confidential-compute path teams need to rehearse before public rollout.
Tooling	Seal verifier, diagnostics, VS Code TEE simulation	Operational support already exists across the tools page, the developer docs, and the local iteration surface.
Operations Stack	HSM-aware node operations and production-readiness checks	TEE usage belongs inside a mature validator operating model, not as a detached demo capability.

Use TEE alone when confidentiality is central, pair it with zkML when proof and confidentiality both matter

For many regulated workloads, hardware-backed isolation is the primary requirement. When the workload also needs mathematical proof of execution, move to the zkML and hybrid verification surface.

Open ZK Proofs