Skip to content

cip: add TEE-Attested Confidential Compute Receipts (Standards Track / Daml)#203

Open
hilarl wants to merge 1 commit intocanton-foundation:mainfrom
hilarl:tenzro/cip-tee-receipts
Open

cip: add TEE-Attested Confidential Compute Receipts (Standards Track / Daml)#203
hilarl wants to merge 1 commit intocanton-foundation:mainfrom
hilarl:tenzro/cip-tee-receipts

Conversation

@hilarl
Copy link
Copy Markdown

@hilarl hilarl commented May 3, 2026

cip: add TEE-Attested Compute Receipts (Standards Track / Layer: Daml)

Summary

This PR opens a Standards Track CIP specifying a meta-key envelope
and a registry-side validation predicate for hardware-attested
confidential-compute receipts on CIP-56 transfer instructions.

The CIP normatively supports four attestation families: Intel TDX,
AMD SEV-SNP, AWS Nitro Enclaves, and NVIDIA Confidential Compute. It
fixes a meta-key namespace, defines a vendor-agnostic receipt
body that delegates the quote encoding to each vendor's specification,
and specifies a 7-clause registry-side validation predicate that
verifies the chain-of-trust, the measurement allowlist, the bound
payload, and the freshness window in constant on-ledger time.

The CIP is filed as Draft. Per CIP-0000, the author has not
self-assigned a number; the editor will assign one on merge.

This is the fourth in a four-part stack of contributions covering, in
order: (A) Multi-VM CIP-56 Bridge Pattern; (B) AI Training & Inference
Settlement; (C) Agentic Identity & Mandate-Bound Payments; (D) the
TEE-attested compute receipts in this PR. CIP-B's optional
tenzro.network/ai.attestation key references receipts of the form
specified by this CIP; the bidirectional binding is documented in
§Backwards compatibility / Composition with CIP-B.

What this CIP specifies

  • A meta-key namespace tenzro.network/tee.* (§2) with 10 normative
    keys covering family, receipt commitment, codec, off-ledger URI,
    measurement digest, measurement algorithm, bound-payload commitment,
    policy-root commitment, attestation time, and an optional GPU
    measurement.
  • A vendor-agnostic ReceiptBody schema (§3) with 9 fields, including
    the vendor-native quote bytes, the X.509 cert chain, the
    measurement, and a 32-byte bound-payload digest.
  • Family-specific quote encodings (§4) that delegate to each vendor's
    specification: Intel TDX Quote v4 (with v5 supported where the
    DCAP library exposes it) with QE P-256 ECDSA; AMD SEV-SNP
    attestation report with VCEK P-384 ECDSA; AWS Nitro COSE_Sign1
    ES384 per RFC 9052 §4.4 (RFC 9053 algorithm registration; RFC 9052
    obsoletes RFC 8152); NVIDIA NRAS JWT.
  • A 7-clause registry-side validation predicate (§5) covering family
    enumeration, receipt-root commitment, vendor-root chain anchoring,
    signature verification, allowlist + policy-root binding,
    bound-payload binding, and per-vendor freshness windows (24h Nitro;
    1h TDX/SEV-SNP/NVIDIA).
  • Failure modes table (§6) — nine enumerated paths.
  • Composition rule with CIP-B: when both key namespaces co-occur on
    a transfer, the AI receipt root MUST equal the TEE bound-payload,
    and the AI attestation MUST equal the TEE receipt root. The
    bidirectional binding closes the loop between the AI compute and
    the TEE attestation.

What this CIP does NOT propose

  • No changes to CIP-56, the DAML standard library, the Canton
    protocol, or the Global Synchronizer.
  • No new on-chain templates or choices.
  • No specific allowlist policy. Operators configure their allowlist;
    this CIP fixes the format and the on-ledger commitment.

Reference implementation

The pattern is shipped and operating on the Tenzro Network testnet.
Live endpoints documented in §Reference implementation of the CIP
body, including the /verify/tee-attestation HTTP endpoint that
runs the §5 predicate over the public web API.

The four family-specific implementations live at
crates/tenzro-tee/src/{intel_tdx,amd_sev_snp,aws_nitro,nvidia_gpu}.rs.
The shared signature and cert-chain verification helpers live at
crates/tenzro-tee/src/{attestation,certs}.rs. AES-256-GCM enclave
encryption with vendor-specific key derivation lives at
crates/tenzro-tee/src/enclave_crypto.rs. The Canton adapter that
populates the meta keys at submission time lives at
crates/tenzro-bridge/src/canton.rs.

File layout

The CIP lives at cips/cip-hilarl-TEE-Receipts.md. The directory
convention used by numbered CIPs (cip-XXXX/) is also acceptable,
with the file moved on number assignment.

Process notes

  • Status: Draft (author-controlled per CIP-0000).
  • Type: Standards Track.
  • Layer: Daml.
  • License: Apache-2.0 (per CIP-0000 acceptable-license list).
  • Number: not self-assigned. Slug: cip-hilarl-TEE-Receipts.
  • Composes against: CIP-0056.
  • Composes with: CIP-B (filed in parallel as a separate PR).
  • Forward-composes against: CIP-0112 (v2 packages).

Signed-off-by: Hilal Agil hilal@tenzro.com

…/ Daml)

Specifies how hardware-attested confidential-compute receipts produced
inside trusted execution environments are carried in the meta field of
CIP-56 transfer instructions, so that confidential AI inference,
training, and key-custody operations settle natively against CIP-56
holdings under hardware-rooted integrity.

Defines a vendor-neutral attestation envelope covering Intel TDX
(Quote v4 / v5), AMD SEV-SNP, AWS Nitro Enclaves (COSE_Sign1 ES384 per
RFC 9052 §4.4 + RFC 9053), and NVIDIA Confidential Computing (NRAS
JWT). Each attestation binds the workload measurement, the input/
output hashes, and the receipt-commitment hash to the holding of the
TEE provider.

Fixes a normative meta-key namespace (tenzro.network/tee.*, 9 keys),
specifies the four vendor-specific attestation schemas, and defines a
6-clause registry-side validation predicate.

Filed as Draft. No number self-assigned. Slug: cip-hilarl-TEE-Receipts.

Signed-off-by: Hilal Agil <hilal@tenzro.com>
@hilarl hilarl requested a review from a team as a code owner May 3, 2026 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant