Attestation: four promises under one word

The word turns up in a processor specification, a GPU marketplace, a software build pipeline and the audit report of a gold-backed token. In each place somebody is being asked to accept a claim they cannot check themselves, and in each place the word is doing a different job. The confusion is not academic: it is how a reader ends up trusting a hardware signature to cover a question hardware was never asked.

What is being attested, and by whom

Only the first two are machine-checkable in the sense most readers assume. The last is a sentence in a document, and the gap between it and a proof is the gap that holders of a backed token are actually exposed to.

What does a hardware quote actually prove?

It proves a measurement: a hash of the software and configuration loaded into the enclave, signed by a key the manufacturer provisioned. Verifying it means checking that signature, following the certificate chain to a trusted root, and comparing the measurement against a value you already know is the right one. That last step is the one teams skip, because it requires reproducible builds and somewhere to publish known-good measurements.

What the quote does not cover is the world outside the enclave, and that world is explicitly hostile in the trusted-execution threat model. Trail of Bits set out the consequence for threshold signing: an implementation that stores pre-signatures on disk and deletes each after use can have the filesystem rolled back by the host, hand the same pre-signature back to the enclave, and watch the signer reuse its nonce share and disclose its private key share. The attestation was valid throughout.

Authenticated encryption gives integrity, not freshness. A backup that decrypts correctly is not thereby current, and nothing in a quote says which version of the state the enclave was handed.

The same review names the pitfalls that recur in audits: verification steps skipped because each vendor defines them differently, physical attacks including an interposer costing under $200 that silently drops DDR5 writes, and vendor tooling whose defaults accept known-vulnerable firmware for a year after disclosure. None of these make the signature invalid. They make the signature answer a smaller question than the reader thought they asked.

Why does attestation concentrate the trust it was meant to spread?

Multi-party computation exists to remove a single point of trust; a trusted execution environment puts one back, in the manufacturer and its attestation infrastructure. Where every party runs on one vendor's silicon or inside one cloud, the distribution the protocol was designed for is nominal.

Decentralised compute has the same problem in a different coat. Proving that a job ran as specified comes down to a choice between redundant execution, which doubles the cost, and trusted hardware attestation, which narrows the supplier pool to exactly the vendors the market was built to route around. That is not a token-design problem and no token design has solved it.

Why does it not transfer between markets?

Because each network attests in its own way. A buyer who has done the work to verify one marketplace's scheme cannot carry that work to another, and we have described this as the main thing keeping decentralised compute fragmented. The networks whose utilisation rose this year were the ones that solved verification in a form that survives a dispute; the ones still explaining their token were the ones that shipped half of it.

Half is the operative word. Settlement without attestation lets a seller take payment for work done on cheaper hardware. Attestation without settlement leaves an invoicing relationship, which is what the market was supposed to replace.

Where attestation is only a sentence

In a backed token, the chain of assurance ends in a document. OpenZeppelin's review of a gold-backed ERC-20 listed eight trust assumptions, and the first is the one holders should read before any of the findings: reserve backing rests on operator attestations rather than on trustless proof. Everything the contract enforces sits above that line, and nothing the contract does can reach below it.

Build provenance sits between the two poles. It is signed, so it is checkable, and it catches a class of attack that registry monitoring misses: a compromised build runner produces an artefact with a genuine signature from a legitimate pipeline, and downstream verification passes because the signature really is valid. Provenance attestation detects part of that and is spreading faster than reproducible builds, which detect more and remain rare.

What to ask of any attestation

• What exactly is measured, and what is deliberately outside the measurement?
• Against which known-good value is the measurement compared, and who publishes it?
• Which verification steps does the vendor require, and are all of them implemented rather than the convenient ones?
• Does anything here establish freshness, or only integrity?
• If this attestation is sound and the claim still turns out to be false, what would have caused that?

The last question is the useful one. An attestation is a narrow instrument that has been asked to carry a broad assurance, and the distance between the two is where every incident in this guide happened. Zero-knowledge proofs are beginning to close part of that distance for compliance work, where an auditor can learn a conclusion about a private ledger and nothing else, but proving remains expensive enough that the technique belongs to batches rather than to individual actions.