Architecture

How Vega turns "trust the cache" into "verify the cache" — the trust model, end to end.

Vega trust model: attestation inputs and Vega's own independent reproduction form a candidate binding that, only after clearing the shared-tier promotion gates, is signed with the master key and recorded in the public RFC 9162 Merkle transparency log, where a consumer verifies it with proofs rather than trusting the operator.
The trust flow, not the infrastructure. A build reaches the globally-trusted shared key only after independent reproduction and the promotion gates; every attestation is recorded in the public transparency log, and you verify a build with proofs rather than trusting the operator. Owner pushes stay in their own namespace and never imply shared trust.

The flow

Three kinds of attestation feed a candidate binding for an output: a GitHub Actions build (its provenance proven by an OIDC token), an owner's local push with vega push (kept in that owner's own namespace), and Vega's own independent reproduction. A build is signed into the globally-trusted shared cache only after it clears the promotion gates: distinct builders agree on the same output, Vega's independent rebuild matches, a settling window passes, the path is in demand, and it is fresh and not revoked.

Every attestation and every signed binding is recorded in the public, append-only RFC 9162 Merkle transparency log. A consumer does not have to trust Vega: they check an inclusion proof against a signed tree head and re-derive the NAR hash to confirm the bytes match what was attested.

This is the trust model, not the deployment. It deliberately omits the implementation — the control plane, storage, key custody, and internal endpoints — because Vega's security comes from verification, not from hiding how it is built.