Skip to main content
The Credential Manager is the protocol’s root of trust. It registers deposit vaults across chains, binds each operator to a dual key — an operator identity key plus a hardware-attested key, both required — and pins the approved TEE code measurements. Operator and governance roles trace back to it; see the trust model.

Vault registry

Each registered vault carries a ChainConfig of per-chain confirmation-policy overrides applied on top of the protocol defaults (confirmation times). Live vault addresses are also served offchain by GET /registry/vaults.

Attestation

The Credential Manager pins which TEE software may run and verifies hardware attestations against it.
  • Measurement profiles are the approved code measurements. mrtd must always match; each rtmr is checked only when non-zero, so one profile can admit several attestation patterns (e.g. different TEE providers). Profiles are added or toggled by the council under a 7-day timelock.
  • Operator keys. Each operator binds an identity key (an EOA) to a hardware-attested key with registerAttestedKey; both are required, and the leader must have a registered attested key.
  • Quote verification is delegated to an external DCAP verifier (automataVerifier): an SP1 ZK proof establishes that a TDX quote came from genuine Intel hardware running the measured code, and the contract then matches the quote’s mrtd and rtmr values against an active profile. The verifier address is itself replaceable only under a 7-day timelock.
On-chain quote verification is used by the restart flow below; live node-to-node attestation instead runs over the attested-TLS handshake between TEEs.

Restart

After a full quorum outage the protocol restarts from a checkpoint, and the Credential Manager certifies which recovered node becomes leader. It holds an epoch (an era counter bumped on every restart) and the latestCheckpointHash. Certification is a permissionless three-step window:
  1. initiateRestart opens a one-hour gathering window and clears any prior candidate. Anyone may call it.
  2. submitRestartProof submits a recovered node’s ZK-attested TDX quote, with the claimed leader, checkpoint hash, and epoch bound into the quote’s report data. The contract verifies the proof and measurements, requires the quote’s epoch to be strictly newer than the current on-chain epoch, and keeps the highest-epoch candidate. Two candidates at the same epoch with different checkpoint hashes mark the restart ambiguous — a detected split brain.
  3. resolveRestart, callable once the window closes, installs the best candidate as the new leader, stores its checkpoint hash, and advances epoch — unless the restart is ambiguous, in which case it reverts and no leader is certified.
The epoch-monotonicity rule prevents replaying a stale state, and the ambiguity check prevents two conflicting recovered states from both being certified. This is the onchain half of recovery; the offchain half — fetching the checkpoint and re-supplying its decryption shares — runs in the quorum.

Governance

High-risk changes are timelocked: Vault registration, operator-set changes, and committee thresholds are quorum-gated council operations. Operator constraints, attestation, and the recovery council: trust model.