No public coordinator attestation endpoint; substrate claim conflicts across project docs

[amiller]

Summary

CLAUDE.md, the deploy runbook, and the research paper Figure 1 all state that the production coordinator runs in a TEE — paper Fig 1 specifically labels it Intel TDX, with the supplementary papers/diagram-test.pdf saying "EigenCompute (Intel TDX TEE)". However, there is no public endpoint where an outside auditor can fetch a TEE quote for the coordinator. GET /v1/coordinator/attestation returns 404.

This is the load-bearing piece of the trust model: when sealed mode is not used (the default — Content-Type: application/eigeninference-sealed+json is opt-in per coordinator/internal/api/sender_encryption.go), every prompt is decrypted by the coordinator before being re-encrypted to the chosen provider. The coordinator-as-TEE claim is the only thing keeping Eigen Labs from seeing plaintext at that boundary, and there is no way for an outside party to verify it.

Substrate claim is internally inconsistent across the project's own docs:

Source	Substrate claim
papers/dginf-private-inference.pdf Figure 1	Intel TDX
papers/diagram-test.pdf	EigenCompute (Intel TDX TEE)
coordinator/internal/api/server.go:11	GCP Confidential VM (AMD SEV-SNP)
coordinator/cmd/coordinator/main.go:8	GCP Confidential VM (AMD SEV-SNP)
CLAUDE.md Infrastructure	EigenCloud (TEE), substrate unspecified
eigencloud.xyz	no substrate disclosure

Host platform acknowledges trustless execution is not yet implemented. From Layr-Labs/ecloud README, Mainnet Alpha Limitations:

"Developer is still trusted — Mainnet Alpha does not enable full verifiable and trustless execution. A later version will ensure developers can not upgrade code maliciously, and liveness guarantees."

For comparison, every other CVM-backed inference provider in the broader cohort publishes its TEE quote:

• Tinfoil: https://atc.tinfoil.sh/attestation (SEV-SNP report + Sigstore-signed predicate)
• Phala dstack apps: 8090 endpoint per app
• NEAR Private AI Verifier: same dstack pattern, plus on-chain anchor

Reproduce

curl -sS -o /dev/null -w '%{http_code}\n' https://api.darkbloom.dev/v1/coordinator/attestation
# 404
curl -sS -o /dev/null -w '%{http_code}\n' https://api.darkbloom.dev/v1/coordinator
# 404

Paper concordance

Findable from the paper alone as an omission. §7 covers provider attestation in detail (four layers, §7.1–§7.4) and §7.3.3 explicitly describes a public-API endpoint for provider chains. There's no parallel section for the coordinator. Figure 1 shows the coordinator in Intel TDX with "Container Image Attested" but the attestation surface is never described.

A reader would ask: "§7 gives the provider's verification API in detail. Where's the equivalent for the coordinator's TDX VM? What does an outside party fetch to verify the running image?" No answer in the paper.

Suggested fix

Add GET /v1/coordinator/attestation returning, at minimum:

• The TEE quote (Intel TDX per the paper)
• The image digest the coordinator is running (matched against coordinator/Dockerfile build pipeline)
• A signed predicate from the build pipeline (Sigstore is the obvious choice if EigenCloud doesn't already provide one) tying the image digest to a Git commit hash on this repo

A close-enough first version: even just publishing the EigenCloud-provided attestation document + the source commit it was built from would let an outside auditor compare to a Git tag and coordinator/Dockerfile. If EigenCloud's attestation surface is itself opaque, that fact should be documented in docs/ARCHITECTURE.md so the trust model is honest about where the chain ends.

---