CIP-23: TEE Execution and Composite Attestation (v3)

v3.1 amendment (2026-07-20, COW-2703). Pins the Job-path result_payload canonical encoding (§3.5.1a) and the Deterministic cross-runner byte-match (§3.5.2; primary home CIP-2 §9): result.data was hashed/compared via non-canonical serde_json (unpinned object-key order + f64 formatting), so honest producers/verifiers could hash the same logical result to different bytes → wrongful reject or wrongful slashing. The amendment adopts the CIP-11 §12.6 CBOR-float64 profile (sorted keys, integral-normalizing, negative-int), VERSION-prefixed and single-sourced in cowboy-protocol-codec with a frozen cross-stack fixture, gated by a dormant CANONICAL_RESULT_PREIMAGE_ACTIVATION_HEIGHT (no-op until governance activates; fork-free). Scope: the CAE preimage (§3.5.1a, all tee_required results — binary64 admitted) and the Deterministic full-result byte-match (§3.5.2, no-floats), with grouping keyed at a single verification-block height. An INVALID result (NaN/±Inf/non-integral binary64/over-cap) has no canonical key → cannot join the equality group and is dispositioned by the existing threshold-gated byte-mismatch slash — no new result_schema predicate (gating a slash on data_format, free-form per CIP-2 §1, would itself split consensus): slashed as a §6.1 invalid reveal only when the valid cohort reaches threshold (gated per-result on inclusion ≥ activation); a sub-threshold valid cohort (ThresholdNotMet) or an all-INVALID round both fail with no slash. The threshold gate is symmetric — a lone below-quorum valid result neither slashes an honest fractional majority (F1) nor lets a defector escape an above-quorum one. A single-runner tee_required INVALID result is the all-INVALID case at N=1 → rejected, no slash. The binary64-in-canonical-preimage vs whitepaper-no-floats (WP §207) tension is an open governance item that blocks activation, not merge. Caps are a CANONICAL_RESULT_VERSION-bumped codec constant (not a free parameter). MajorityVote/StructuredMatch are field-scoped/tolerant (CIP-2 §9/§9.1) and out of scope — a tracked exposure, not yet resolved. v3 changelog (vs v2). Single complete document (no more Part I/II/III layering). New: (1) explicit verification-philosophy split — TeeAttested (confidential, 1-replica, attestation-as-verification) vs Deterministic (non-confidential, reproducible, byte-match), §3.4; (2) on-chain DCAP verified as a SNARK-compressed proof with governance-anchored collateral and a TCB-level policy step, §3.8; (3) multi-root trust chip_root ∧ operator_root (Proof-of-Cloud) and an explicit threat model post-TEE.Fail, §3.6, §6; (4) attest_digest circularity fixed and nonce made unpredictable, §3.5; (5) implementation reconciled — the shipped interim trusted-key model is documented and repurposed as the operator root, §3.8.2; (6) P2 fixes — gas target 20M, measurement 48-store/32-index, SGX rejected for attested modes, canonical TEE-type naming. Folds in v2: three-layer chain (§3.14), CIP-13 delegation (§3.15), canonical TEE types. Refinement (2026-06-18): §3.8.8 — proving-latency split. The chip-root SNARK is verified at registration / renewal (~7 days), not per call: the binding captures the platform key (bound_quote_key), and per-call acceptance is a light path (quote-sig vs bound key + REPORTDATA + freshness/replay, no SNARK). Driven by zkVM DCAP proving (~30 s–min) not fitting the 75-block freshness window.

​

1. Abstract

• Two verification philosophies, kept apart (§3.4). TeeAttested is for confidential outputs: a single runner, where the attestation is the verification (no cross-runner reproduction). Deterministic is for non-confidential, reproducible outputs: a committee re-executes and byte-matches the result. v1/v2 conflated these; they are incompatible (a confidential output is never byte-identical across runners) and are now separated.
• On-chain verification is a SNARK-compressed DCAP proof (§3.8). The chain runs verify(proof, public_inputs); the circuit performs quote parsing, the vendor X.509 chain, ECDSA, and TCB-level evaluation. This makes verification deterministic (time-dependent collateral becomes a circuit input anchored to a governance snapshot) and cheap (≈ 1 order of magnitude gas reduction vs a hand-rolled on-chain chain walk).
• Multi-root trust (§3.6). After TEE.Fail (2025-10) demonstrated physical extraction of attestation keys (and forged TDX attestations on a live chain), a single hardware root is insufficient. v3 requires chip_root ∧ operator_root, where the operator root is a Proof-of-Cloud / deployment endorsement.

​

2. Motivation

1. TEE.Fail (2025-10) — a < $1,000 DDR5 physical interposer extracts signing/attestation keys from Intel TDX/SGX and AMD SEV-SNP (deterministic AES-XTS, no replay protection), and was used to forge TDX attestations on Ethereum BuilderNet. A forged quote can chain to a vendor root. The single-hardware-root assumption is therefore unsafe → multi-root trust (§3.6).
2. On-chain DCAP matured — production SNARK-compressed DCAP verifiers (e.g. Automata) verify SGX/TDX attestations on EVM at ~1/10th the gas, and resolve the determinism problem by moving time-dependent checks into the circuit → SNARK verification (§3.8).

​

3. Specification

​

3.1 Terminology

• CVM — Confidential Virtual Machine (TDX Trust Domain, SEV-SNP VM, Nitro Enclave).
• NCC — NVIDIA Confidential Compute; per-GPU attestation signed by an NVIDIA-rooted key plus an EAT token from the NVIDIA Remote Attestation Service (NRAS).
• Quote — a signed, hardware-generated attestation bound to a measurement and caller-supplied user_data.
• Measurement — a hash of the TEE’s initial state (TDX MRTD, SNP LAUNCH_DIGEST, Nitro PCR0; further Nitro PCRs ride in pcr_extensions).
• CAE — Composite Attestation Envelope (§3.5).
• CollateralSnapshot — a governance-published bundle of vendor collateral (root certs, TCBInfo, QEIdentity, CRLs, NRAS root) selected by block height; the only source of truth for time-dependent validity on-chain (§3.8.4).
• Measurement Binding — on-chain Registry record tying a runner to CPU/GPU measurements, a service pubkey, and an operator-root reference, established at registration (§3.9).
• Chip root / Operator root — the two trust roots of §3.6.
• Freshness Anchor — (nonce, deadline, generated_at) in a CAE (§3.5).

​

3.2 System Actor Map (authoritative)

​

3.3 Hardware Stack

​

3.4 Verification modes — TeeAttested vs Deterministic

• A tee_required job defaults to TeeAttested. Selecting Deterministic requires the submitter to declare the output non-confidential.
• For both modes every TEE result MUST carry a CompositeAttestation that passes §3.8.
• tee_type eligibility: tdx / sev / nitro → both modes; sgx → neither (legacy, EconomicBond only).

Wire encoding (normative — matches cowboy-protocol-codec::job_spec::VerificationConfig). TeeAttested and Deterministic name verification philosophies, not VerificationMode enum tags. There is no TeeAttested tag in the on-chain VerificationMode enum; its wire tags are None=0, EconomicBond=1, MajorityVote=2, StructuredMatch=3, Deterministic=4, SemanticSimilarity=5 (single u8). TEE attestation is carried by the sibling tee_required: bool field of VerificationConfig (plus required_tee_type: Option<String>, ≤128 B). The two philosophies map to the wire form as: TeeAttested = tee_required = true with a confidential single-runner VerificationMode (None / EconomicBond); Deterministic = VerificationMode::Deterministic (tag 4) with tee_required == true (the node enforces that Deterministic requires tee_required).

​

3.5 Composite Attestation Envelope (CAE)

pub struct CompositeAttestation {
    pub version:     u16,                         // = 1
    pub cpu:         CpuAttestation,
    pub gpu:         Option<GpuAttestation>,      // required for AI / GPU jobs
    pub service_sig: ServiceSignature,
    pub freshness:   FreshnessAnchor,
    pub extra:       BTreeMap<String, Vec<u8>>,   // reserved
}

pub struct CpuAttestation {
    pub tee_type:       CpuTeeType,               // Tdx | Sev | Nitro  (Sgx not eligible, §3.3)
    pub quote:          Vec<u8>,                  // raw quote bytes (verified inside the SNARK, §3.8)
    pub cert_chain_cid: Cid,                      // CIP-9 CID for the full cert chain
    pub measurement:    [u8; 48],                 // MRTD / LAUNCH_DIGEST / Nitro PCR0 (vendor-native width)
    pub pcr_extensions: Vec<[u8; 48]>,            // runtime/boot measts: TDX RTMR0..3 / Nitro PCR1..N (empty if none)
}

pub struct GpuAttestation {
    pub tee_type:          GpuTeeType,            // NvidiaNcc
    pub nras_token:        Vec<u8>,               // NRAS-signed EAT (JWT)
    pub gpu_measurement:   [u8; 48],
    pub bound_cpu_pubkey:  [u8; 32],              // CPU↔GPU binding
}

pub struct ServiceSignature {
    pub scheme:         SigScheme,                // Ed25519 only in v3 (see note); EcdsaP256 reserved
    pub service_pubkey: [u8; 32],                 // 32-byte Ed25519 key (see "Service-key scheme")
    pub sig:            Vec<u8>,                  // Sign(sk, task_id ‖ req_hash ‖ result_hash ‖ attest_digest)
}

pub struct FreshnessAnchor {
    pub nonce:        [u8; 32],
    pub deadline:     u64,                        // block height
    pub generated_at: u64,                        // block height at quote request
}

attest_digest := keccak256( D-CBOR(CompositeAttestation { service_sig: ∅, .. }) )

nonce := keccak256( task_id ‖ req_hash ‖ submission_block_hash ‖ beacon )

On-chain enforceability (normative status). This nonce-derivation recipe is a producer-side MUST. The chain cannot verify the derivation — the verifier treats nonce as opaque, checking only its inclusion in REPORTDATA (§3.8.5) and non-replay. Beacon-binding is a well-formedness obligation on honest runners, not a chain-checked invariant; an adversary who can already extract attestation keys is out of scope for this control (that is the operator-root’s job, §3.6).

user_data = keccak256(nonce ‖ service_pubkey ‖ gpu_measurement_if_any)

​

3.5.1 Per-path preimages (normative)

req_hash := keccak256( DOMAIN_TAG ‖ [JOB_SPEC_VERSION] ‖ JobType::encode() )
DOMAIN_TAG = b"cowboy/jobspec-req-digest/v1"

​

3.5.1a result_payload canonicalization (normative — amendment, COW-2703)

result_payload := if block_height >= CANONICAL_RESULT_PREIMAGE_ACTIVATION_HEIGHT
                      [CANONICAL_RESULT_VERSION] ‖ canonical_result_cbor(result.data)
                  else
                      serde_json::to_vec(result.data)          // legacy — byte-identical to today

• canonical_result_cbor is the CIP-11 §12.6 CBOR-float64 profile applied to arbitrary JSON: recursively, object → CBOR map with sorted text keys; array → array; a number that is integral and in range → shortest CBOR int (non-negative major-type-0 and negative major-type-1), otherwise IEEE-754 binary64 (an 8-byte binary form — no float→string non-determinism). (“In range” = the value the parser produced fits the CBOR integer major-types the codec emits; the exact f64-that-is-integral-but-outside-i64/u64 boundary is fixed by the single-source codec + fixture, not by this prose, so third-party re-implementers must derive it from the codec, not paraphrase it.) A value that cannot be represented — NaN / ±Inf, or one exceeding the result-domain depth/size caps (§below) — is INVALID. Disposition of an INVALID result: for the cross-runner Deterministic mode, §3.5.2; for a single-runner tee_required result (committee = 1 — TeeAttested, or None/EconomicBond with tee_required), the CAE preimage cannot be formed, so the result is rejected and the job fails verification (there is no candidate group to exclude from, and no cross-runner slash set); any bond disposition follows the mode’s existing single-runner rule (EconomicBond forfeits its bond on a failed result exactly as today; None has no economic consequence). NaN/±Inf here is producer-controllable, but a single-runner failure is already fully accounted by the existing mode rule — this amendment adds no new slash on that path.
• CANONICAL_RESULT_VERSION (u8) prefixes the CBOR so any future bytes-changing edit is an explicit version bump, not a silent fork. It and canonical_result_cbor are single-sourced in cowboy-protocol-codec; every node and runner MUST pin the identical codec rev, guarded by a checked-in frozen (result.data, block_height) → result_payload cross-stack fixture that fails loud on any bytes-changing upgrade.
• Result-domain caps. The canonical form imposes a maximum nesting depth and encoded size, set above any plausible legitimate result so the INVALID rule can never reject/slash an honest runner. Because a cap change moves the INVALID boundary (and hence the grouping/slash set) without changing any within-cap bytes, the caps are not a free governance parameter: they are a CANONICAL_RESULT_VERSION-bumped constant of the single-source cowboy-protocol-codec (a cap change is a version bump, exactly as any bytes-changing edit is), and the frozen cross-stack fixture MUST carry over-cap boundary vectors (a result at cap−1, at cap, and at cap+1) so any node/runner reading a different cap fails the golden loudly. No node may read a cap value that is not pinned by the codec rev in force at the evaluated height.
• No-op while dormant. Every live block is below u64::MAX, so result_payload is byte-identical to today until governance activates; all validators at a given inclusion height apply the same branch, so activation is fork-free (a result whose CAE was produced under the pre-activation rule but included at/above the height fails verification and is resubmitted — a brief, announced liveness window, not a safety split).

Open governance item (blocks activation, not merge) — binary64 in a canonical trust-boundary encoding vs the whitepaper no-floats rule. §3.5.1a admits non-integral binary64 into canonical_result_cbor, which is hashed into result_hash / the CAE service_sig — a canonical, consensus-verified quantity crossing the runner→verifier boundary. The whitepaper (WP §207) forbids floats in any canonical encoding (note the ban is specifically on canonical encodings; float computation is permitted via deterministic softfloat, WP §541 — which is why the determinism-motivated reading is plausible). This amendment applies no-floats only to the cross-runner Deterministic match (§3.5.2); it exempts the CAE preimage on the rationale that it binds one runner’s own bytes and is never cross-reproduced (satisfying the determinism spirit). Whether WP §207 is determinism-motivated (spirit satisfied) or categorical (letter violated) is a governance call, not adjudicated here. The tension pre-exists in the CIP-11 §12.6 profile (cip-11:983); this amendment is the first to route arbitrary-JSON floats (where floats genuinely occur — {"price":19.99}) through a consensus preimage. Before governance lowers CANONICAL_RESULT_PREIMAGE_ACTIVATION_HEIGHT, WP §207 MUST be reconciled — either the WP is amended to state the rule is determinism-motivated (and single-runner-bound floats are permitted), or floats are dropped from the CAE preimage too (making all result.data no-floats, at the cost of confidential float outputs). Merging this dormant amendment does not require the decision; activating it does.

​

3.5.2 Deterministic cross-runner byte-match (normative — amendment, COW-2703)

• No-floats (per CIP-2 §9.1 / the whitepaper no-floats rule). Deterministic is a cross-runner reproducibility mode: canonical_result_cbor pins serialization, not computation, so two honest runners whose f64 math differs by 1 ULP would still hash to different bytes. Consensus-reproducible outputs therefore MUST be scaled-integer / fixed-point (Nano), never native floats — exactly as CIP-2 §9.1 already requires of canonical-wire values. A Deterministic result.data whose canonical form contains a non-integral binary64 is non-conformant → INVALID. (This restriction is specific to the byte-match; the single-runner CAE preimage of §3.5.1a still admits binary64, since it binds one runner’s own bytes and is never cross-reproduced.)
• Height reference — split: grouping vs slash-eligibility. The grouping/equality branch (which encoding the comparison keys on) is decided once for the whole verify_results call at its verification/finalizing block height — all results grouped under one branch on every validator, so the equality partition is identical network-wide across the flag day (a per-result-height reading would diverge the partition → consensus split). But the INVALID ⇒ slashed disposition is gated per result on that result’s own inclusion block height ≥ activation (also a deterministic consensus quantity, so still no partition split). A runner who conformed to the rules in force at its submission (result included below activation, under the §3.5.1a legacy serde_json branch, where no no-floats rule applied) is therefore never retroactively slashed when settlement crosses the flag day — a slash is not a resubmit. Its uncanonicalizable form may still exclude it from the equality group (a liveness outcome), but it is not added to the slash set.
• INVALID disposition — no new predicate; reuse the existing disagreement rule. A result whose canonical form is INVALID (NaN/±Inf, non-integral binary64, or over the §3.5.1a caps) has no canonical key, so it can neither form nor join an equality group nor serve as the comparison reference (it is filtered from reference selection, so a single invalid submission cannot veto the round). It is not slashed by a new amendment rule — and in particular not by parsing the job result_schema (data_format is free-form per CIP-2 §1; gating a slash on an unpinned predicate would itself split consensus, the very defect this amendment removes). Instead it is dispositioned by the existing Deterministic byte-mismatch slash, which keys only on canonical quantities — and which is itself threshold-gated (matching_count < threshold ⇒ ThresholdNotMet, on which the shipped verifier discards runners_to_slash and slashes no one). So the disposition is the mechanism’s real three-way, not a binary:
  • Valid cohort reaches threshold (the reference result’s identical-canonical group is ≥ threshold): every INVALID result fails to match that cohort and is slashed exactly as any byte-mismatching result is — a 0 + slash invalid reveal per CIP-2 §6.1 (not §6.2, which is non-reveal; here the runner did reveal) — the slash gated per-result on inclusion height ≥ activation (F2 above).
  • Valid results exist but the largest canonical cohort is sub-threshold: ThresholdNotMet ⇒ the job fails with no slash, exactly as the shipped verifier discards runners_to_slash on that path. INVALID results are not slashed here — matching the pre-existing behavior for any sub-threshold disagreement (a wrong-integer defector that denies quorum is likewise unslashed today).
  • Every result is INVALID (no canonicalizable result): job fails with no slash — an all-fractional honest committee (a job-result_schema fault every runner reproduces — F1) and an all-garbage round both fail cleanly, without slashing the whole committee.
  Both inputs — “is this result canonicalizable” and “which results share the reference’s canonical cohort” — are deterministic consensus quantities (the canonical_result_cbor Err is single-sourced + fixture-guarded; the threshold is the stored spec’s), so the slash set is identical on every validator: no undefined predicate, no split. The float route is therefore slashable exactly when a disagreeing integer would be — above threshold, slashed; sub-threshold, not — so it grants an attacker no advantage over the pre-existing Deterministic threshold guarantee (no better, no worse); it does not manufacture a new penalty-free dodge. Nor the inverse: the threshold gate is what stops a lone integral-outputting defector from inverting an all-honest-fractional round into a slash of the honest majority. If R1/R2 honestly return {"rate":3.333} (INVALID) and a deviating R3 returns {"rate":3} (VALID), R3’s valid cohort has size 1 < threshold → ThresholdNotMet → the job fails and no one is slashed — the honest fractional majority is never slashed just because a single below-quorum valid result exists. (The status-quo outcome — the fractional pair being the winning cohort — becomes a clean job-fail post-activation, a documented liveness narrowing, not a wrongful slash.) A committee that adaptively degrades to one Deterministic survivor is the all-INVALID (or sub-threshold) case → job-fails, no slash — consistent with the §3.5.1a single-runner path.
• Below the activation height, comparison uses the legacy serde_json::to_vec(result.data) (byte-identical to today).

Out of scope — MajorityVote / StructuredMatch code divergence. The shipped node verifier groups MajorityVote and StructuredMatch by a full-result.data serde_json::to_string fingerprint, which already diverges from CIP-2 §9/§9.1 (field-scoped vote / tolerant pipeline) independently of canonicalization. This amendment deliberately does not canonicalize — and thereby cement — that divergence; reconciling verifier.rs MajorityVote/StructuredMatch to their §9/§9.1 models is tracked as a separate issue. Being out of scope does not mean those two modes are sound: until that issue lands they still group/slash on the same non-canonical serde_json::to_string this amendment fixes for Deterministic, so they carry the same live wrongful-slash exposure — a tracked, not a resolved, gap.

​

3.6 Trust roots — multi-root (chip_root ∧ operator_root)

• chip_root — the vendor attestation, verified via the SNARK pipeline (§3.8).
• operator_root — a Proof-of-Cloud / deployment endorsement (cf. Flashbots Proof-of-Cloud, Intel POE) proving the CVM runs in an attested operational environment, not a bench rig under interposition. One conformant implementation is the shipped governance-trusted-key model (§3.8.2).

Current-state vs target-state (normative status). The chip_root ∧ operator_root MUST is target-state. Today only the operator_root ships (the interim trusted-key model, §3.8.2); the chip_root SNARK pipeline is a roadmap item (§7). Until the chip-root activation block, acceptance runs on the operator root alone (single-root), with chip_root in --tee-soft-fail (warn-only) mode; the AND-rule is enforced from chip-root activation onward. This is a known, human-accepted Draft gap — it is not a claim that both roots are enforced today.

​

3.7 On-chain Storage Strategy

​

3.8 TEE Verifier Actor (0x05)

​

3.8.1 State

pub struct TeeVerifierState {
    pub collateral: BTreeMap<u64, CollateralSnapshot>,   // governance-published, keyed by effective_at
    pub seen_nonces: BTreeMap<JobId, BTreeSet<[u8; 32]>>,
    pub last_gc_block: u64,
}

​

3.8.2 Implementation status — interim model vs target

• Instructions (opcodes 60–63): RegisterTeeTrustedKey / RevokeTeeTrustedKey / SubmitTeeAttestation / RevokeTeeAttestation. Governance registers a trusted quote-signing key per (tee_type, measurement_hash); a runner submits a per-job ECDSA-signed attestation record; the chain verifies the signature against the governance-registered key (not a vendor cert chain). Consumed today only by CBSS secret release (validate_runner_tee_for_release).
• This model does not verify a hardware cert chain; its trust root is “governance vouches for this measurement→key”.

​

3.8.3 Instructions

Collateral (TCBInfo / QEIdentity / CRL) is published as one snapshot via UpdateCollateral, replacing v1/v2’s root-only UpdateCpuRoot/UpdateNrasRoot. This is what lets governance blacklist a vulnerable microcode/TCB level (§6) — by publishing a snapshot whose TCBInfo marks that level unacceptable.

​

3.8.4 Determinism via governance-anchored collateral

​

3.8.5 Verification pipeline (verify_cae)

enum Mode { Full { proof }, Light }   // Full ⇔ proof present; Light ⇔ no proof

fn verify_cae(mode, cae, job_id, req_hash, result_hash, registry, snapshot) -> Result<(), TeeVerifyError>:
    1. Freshness:   now ≤ deadline AND (now − generated_at) ≤ MAX_QUOTE_AGE (= 75 blocks)
    2. Replay:      cae.freshness.nonce ∉ seen_nonces[job_id]

    match mode:
      Full { proof }:                 # registration / renewal — §3.8.8
        3. SNARK/chain: verify(proof) — circuit checks quote parse + vendor X.509 chain
                        (TDX→PCS, SNP→VCEK) + ECDSA, against snapshot roots;
                        (Nitro is the exception — verified directly on-chain, no SNARK, §3.8.9)
                        journal ⇒ ChipRootPublicInputs (measurement, tcb_status, bound_quote_key, …)
        4. TCB level:   tcb_status ∈ governance-allowed set (default {UpToDate})   → else TcbOutOfDate
        4b. Capture:    persist Active binding(service) ← { measurement(s), bound_quote_key := AK
                        from the verified quote, operator_root, tcb_epoch }                 # §3.9

      Light:                          # per-call hot path — NO SNARK, NO per-call CRL/TCB — §3.8.8
        3'. Binding:    b := registry.binding(service); b.status == Active AND now ≤ b.expires_at
                        → else RegistryMismatch
        4'. Quote sig:  verify(b.bound_quote_key, quote.header ‖ quote.report_body, quote.signature)
                        — a single ECDSA against the AK captured at registration  → else SigInvalid

    # common tail (both modes)
    5. Measurement: keccak(cae.cpu.measurement) ∈ registry.binding(service).allowed_cpu
                AND cae.gpu?.gpu_measurement ∈ registry.binding(service).allowed_gpu
    6. Binding:     quote.REPORTDATA == keccak(nonce ‖ service_pubkey ‖ gpu_measurement_if_any)
    7. Service sig: verify(service_pubkey, task_id ‖ req_hash ‖ result_hash ‖ attest_digest, sig)
    8. NRAS (GPU):  verify EAT(JWT) against snapshot.nras_root AND token.measurement == gpu_measurement
    9. Operator root (Full only): operator_root endorsement valid (§3.6, §3.8.2)  → else OperatorRootFail
   10. Accept → insert nonce into seen_nonces[job_id]; else → TeeVerifyError::<kind>

​

3.8.6 Error codes

pub enum TeeVerifyError {
    AttestFail,         // SNARK/cert-chain failure
    TcbOutOfDate,       // TCB level not accepted (v3)
    RegistryMismatch,   // measurement not whitelisted
    SigInvalid,         // service signature invalid
    TaskExpired,        // deadline or MAX_QUOTE_AGE exceeded
    TaskReplayed,       // nonce already seen
    InvalidResultHash,  // result_hash mismatch
    UnsupportedTeeType, // no root for this TEE type (e.g. SGX legacy)
    NonceBindingFail,   // REPORTDATA mismatch
    OperatorRootFail,   // operator/Proof-of-Cloud root failed (v3, multi-root)
    TeeUnavailable,     // runner couldn't obtain a quote
}

​

3.8.7 Gas

Terminology (per marshal review). CIP-3 defines 20,000,000 as the block-cycle capacity and T_c = 10,000,000 (50%) as the target; the node constant historically named BLOCK_CYCLES_TARGET actually holds the capacity value. This CIP uses CIP-3’s capacity/target terms and states headroom against the sustained target to avoid overstating.

​

3.8.8 Where the SNARK runs — registration vs per-call (proving-latency split)

• Registration / renewal (low frequency, ~7 days, §3.9). The full chip-root SNARK (§3.8.5 steps 3–4: vendor cert chain + TCB level) is generated and verified once per binding. On success the binding captures the ECDSA attestation key (AK) that signs the quote body (bound_quote_key) and the accepted measurements / TCB epoch. Proving latency is irrelevant here.

• Per call (high frequency). Result acceptance does not re-verify the SNARK. The runner’s per-job quote is checked with the light path: the quote signature verifies against the binding’s bound_quote_key (a single ECDSA), plus REPORTDATA binding (step 6), service signature (step 7), freshness (step 1) and replay (step 2). The cert chain / TCB were already proven at registration and are invariant within the TCB epoch.

Rationale. Proving-latency analysis (RISC Zero/SP1 DCAP ≈ 30 s–min) showed a per-call SNARK cannot fit the 75-block freshness window. Anchoring the heavy proof to the ~7-day binding cadence and binding the platform key keeps per-call acceptance cheap and latency-free while the cert chain / TCB are proven once per renewal period.

​

3.8.9 Nitro (P3) backend verification — COSE_Sign1, direct (no SNARK)

3-Nitro. Direct COSE verification (no proof; cae.cpu.quote = COSE_Sign1 doc):
   a. Decode COSE_Sign1; require protected.alg == ES384.
   b. Leaf sig:   verify ES384 over Sig_structure
        ["Signature1", protected, b"", payload] with the leaf cert's P-384 key  → else AttestFail
   c. Chain:      walk cabundle ‖ leaf; each cert ECDSA-verified by its issuer;
        the chain root MUST equal a cpu_root in snapshot.cpu_roots              → else AttestFail
        (the AWS Nitro root is governance-published collateral, §3.8.4 — the
         doc's self-carried root is NEVER trusted)
   d. Measurement: doc.pcrs[0] == cae.cpu.measurement   (PCR0 = launch digest)  → else RegistryMismatch
        AND doc.pcrs[i] == cae.cpu.pcr_extensions[k] for the bound PCR set
        (e.g. PCR1, PCR2), each 48 B
   e. Binding:    doc.user_data == REPORTDATA
        == keccak(cae.freshness.nonce ‖ service_pubkey ‖ gpu_measurement?)       → else NonceBindingFail
        (§3.5 / §3.8.5 step 6 — pins the freshness nonce AND the Ed25519
         service key inside the AWS-signed doc; the GPU term covers P2 jobs)
   f. tcb_status := UpToDate   (Nitro exposes no TCB; §3.8.5 step 4 is a no-op)
   g. Capture:    persist Active binding(service) ← { measurement(s),
        bound_quote_key := service_pubkey, operator_root, tcb_epoch }           # §3.9

• §3.8.5 step 7 — the service signature over task_id ‖ req_hash ‖ result_hash ‖ attest_digest, verified against service_pubkey (== binding.bound_quote_key);
• §3.8.5 step 5 / step 3′ — measurement whitelist; binding Active and unexpired.

​

3.9 Runner Registry Extension

pub struct MeasurementBinding {
    pub cpu_tee_type:             CpuTeeType,
    pub allowed_cpu_measurements: BTreeSet<[u8; 32]>,    // keccak(48-byte measurement)
    pub allowed_gpu_measurements: BTreeSet<[u8; 32]>,    // empty → GPU not required
    pub service_pubkey:           [u8; 32],
    pub bound_quote_key:          Vec<u8>,                // v3: ECDSA attestation key (AK) that signs the quote body; AK→QE→PCK→root chain verified by the SNARK at registration; per-call quote sigs verify against it (§3.8.8)
    pub operator_root_ref:        OperatorRootRef,        // v3: Proof-of-Cloud / deployment endorsement
    //   wire: OperatorRootRef { kind: u8, data: Vec<u8> } (matches cowboy_types::tee). `kind`
    //   discriminates the operator-root scheme (kind=1 = shipped governance-trusted-key model,
    //   §3.8.2); `data` is scheme-specific and opaque in P1 — a deliberate extension point,
    //   its layout defined per-`kind` as each Proof-of-Cloud scheme is specified.
    pub bound_at:                 u64,
    pub expires_at:               u64,                    // default bound_at + BINDING_RENEWAL_PERIOD
    pub status:                   BindingStatus,          // Active | Deprecated | Revoked
}

​

3.10 Dispatcher Filter (amends CIP-2 §5.4)

Implementation note: the shipped dispatcher still filters on self-declared tee_support (type-aware). Migrating the filter to measurement_binding is part of landing the chip-root path.

​

3.11 Result Verifier (amends CIP-2 §9)

• TeeAttested: committee = 1; the result MUST carry a CAE; 0x03 runs the light verify_cae and accepts on pass. No byte-match (the output is confidential).
• Deterministic: every result MUST carry a CAE; 0x03 runs the light verify_cae per result, then performs the byte-identical match on the (non-confidential) result payload — at/above the activation height this match keys on the canonical canonical_result_cbor(result.data) and applies the INVALID⇒excluded∧slashed rule of §3.5.1a / §3.5.2 (which govern the canonical form, the no-floats constraint, and the single verification-height reference). Any failure fails the whole job.
• Other modes MAY attach a CAE; if present it MUST pass the light path, except sgx CAEs which are rejected (UnsupportedTeeType).

​

3.12 Secrets Manager / CBSS Integration

CIP-24 coordination: the release gate now prefers the v3 measurement_binding (registered via VerifyCae, which checked chip ∧ operator) over the interim governance-key record — an Active, unexpired binding for the runner authorizes release, and re-checking it at release (not only at dispatch) enforces mid-epoch revocation: a DeprecateBinding (CVE / key compromise, §3.8.8) blocks every further release with no fall-through to the interim record. The interim record remains the fallback only while a runner has no v3 binding yet (chip-root transition). Requiring a fresh per-release CAE (the §3.5.1 secret-release preimages, carried alongside the runner-signed request) is the remaining hardening.

​

3.13 tee_call SDK Helper

​

3.14 The three-layer chain (defense in depth)

​

3.15 CIP-13 (delegation) interaction

​

3.16 Parameters

​

4. Rationale

• Two modes, not one. Confidential output (the whole point of TEE for privacy) and committee byte-match are mutually exclusive; conflating them (v1 §3.9) was unimplementable for the privacy case. TeeAttested makes attestation the verification; Deterministic keeps reproduction for public outputs.
• SNARK over hand-rolled chain. Moving X.509 + ECDSA + TCB evaluation into a circuit solves two problems at once: the on-chain non-determinism of time (collateral becomes a snapshot-anchored circuit input) and gas (verify a proof, not a 7-layer walk). It also reuses an industry-proven pattern.
• SNARK off the hot path (§3.8.8). zkVM DCAP proving is ~30 s–minutes — it cannot fit the 75-block freshness window per call. Verifying the chip-root SNARK at registration / renewal (~7 days) and binding the platform key (bound_quote_key) lets per-call acceptance be a single ECDSA + REPORTDATA / freshness / replay — cheap and latency-free — while the cert chain / TCB are proven once per renewal period.
• Multi-root. TEE.Fail proved a forged-but-root-valid quote is achievable with physical access. A second, operationally-rooted endorsement (Proof-of-Cloud) is the pragmatic mitigation; it also gives the already-shipped governance-key model a principled home.
• CPU + GPU via REPORTDATA binding. Without cross-binding, CPU and GPU attestations can be mixed and matched; the user_data rule makes the CPU quote worthless without the matching GPU report and service key.
• On-chain digest, off-chain body. Anchoring only attest_digest keeps state growth independent of attestation size; the full CAE lives on CIP-9.
• attest_digest excludes the signature. Otherwise the digest contains the signature that signs it — a circular definition that cannot be implemented.
• Unpredictable nonce. A publicly-derivable nonce offers no freshness against a key-extraction adversary; an on-chain beacon does.

​

5. Backwards Compatibility

• Non-TEE runners are unaffected; they cannot be selected for tee_required jobs.
• The interim trusted-key model (opcodes 60–63) keeps running and is reframed as the operator root — no migration needed for what exists today.
• The chip-root SNARK path and the dispatcher’s switch from self-declared tee_support to measurement_binding land incrementally; a one-release --tee-soft-fail flag warns instead of rejecting during cutover.
• CIP-10 BillingAttestation.tee_signature is Option<CompositeAttestation>, freshly generated per billing event with the byte-exact nonce/REPORTDATA/result_hash pinned in §3.5.1 (cert chain MAY be cached; the quote MUST be fresh within MAX_QUOTE_AGE).

​

6. Security Considerations

• Threat model (§3.6): chip-vendor root does not cover physical access + root (TEE.Fail). Mitigated by the operator root; remote/software adversaries are covered by the chip root.
• TEE.Fail / physical extraction: a forged quote can chain to a vendor root. Single-root acceptance is therefore disallowed; chip_root ∧ operator_root is required.
• Forged quotes (remote): rejected by the SNARK chip-root verification.
• Replay: nonce (with beacon) is bound inside REPORTDATA and checked against seen_nonces[task_id] for the dispute window.
• Vulnerable microcode / TCB: governance publishes a CollateralSnapshot whose TCBInfo marks the level unacceptable → step 4 (TcbOutOfDate). (This is what v1 §6 intended; it is done via UpdateCollateral/TCBInfo, not root-cert updates.)
• NRAS centralization: verified against snapshot.nras_root (no live call); a threshold multi-provider fallback is a follow-up.
• CAE availability: the on-chain attest_digest proves the receipt exists even if the CIP-9 body is unreachable; runners SHOULD pin to ≥ k Relay Nodes.
• GPU memory residue: addressed by CIP-10 §14.6.

​

7. Implementation Roadmap

​

Appendix A: Reference Mapping (PythonVM × TEE prior art ↔ Cowboy)

​

Appendix B: TEE landscape (snapshot, informative)

• TEE.Fail (2025-10): < $1,000 DDR5 interposer extracts keys from TDX/SGX/SEV-SNP (deterministic AES-XTS); forged TDX attestations on Ethereum BuilderNet. Vendors deem physical attacks out-of-scope → drives multi-root (§3.6).
• On-chain SNARK DCAP (Automata et al.): production SGX/TDX attestation on EVM with SNARK compression (~1/10 gas) and decentralized collateral caching → drives §3.8 SNARK pipeline.
• Proof-of-Cloud (Flashbots) / Intel POE: chip-root + operator-root composition → the operator_root of §3.6.
• NVIDIA Blackwell CC: B200/GB200 confidential mode (encrypted PCIe 5.0 / NVLink); CC deployment guide v7.1 (2026-04).