Documentation
Trust tiers
The journal schema is frozen; only the verifier behind IJournalVerifier changes. Every launch certificate is permanently labeled with the tier it verified under. Presenting an attestation-tier deployment as zero-knowledge would misstate its trust model, which is why the protocol's name contains no "zk" and its clients render the tier everywhere.
| Tier | What verifies the journal | What you trust | Status |
|---|---|---|---|
| T0 | k-of-k signatures from named operators who each deterministically re-execute the pinned guest and sign the journal bytes | Non-collusion of all k listed operators | Current |
| T1 | TEE attestation: the identical guest binary in attested enclaves, quote chain checked on-chain | The enclave vendor | Planned |
| T2 | Groth16-wrapped zkVM receipt of the guest execution, verified cryptographically | Proof-system soundness only | Target — gated on a production Solidity-compilation-in-zkVM pipeline, which nobody has published yet |
Upgrading a deployment from T0 to T2 changes no state machine, no schema, and migrates no data: a new verifier contract is pointed at behind an immutable interface. Old campaigns keep their honest tier label forever; certificates never retroactively strengthen. Feasibility analysis and cycle estimates: paper Section 6.