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

Two kinds of attestation feed a candidate binding for an output: independent GitHub Actions builds (provenance proven by an OIDC token) and Vega's own independent reproduction. An owner's local push with vega push stays in that owner's own namespace and never feeds the candidate. A build is signed into the globally-trusted shared cache only after it clears the promotion gates: distinct owners agree on the same output, a trusted Vega rebuild matches, a settling window passes, 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.