> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tplus.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Credential Manager

> The protocol's root of trust: vault registry, operator keys, attestation, restart certification, and timelocked governance.

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](/security/trust-model#trust-hierarchy).

## Vault registry

```solidity theme={null}
struct ChainConfig {
    uint64 blockTimeMs;
    uint8  defaultConfirmations;
    uint8  depositIngestConfirmations;
    uint8  withdrawalIngestConfirmations;
    uint8  settlementIngestConfirmations;
}

struct Vault {
    uint8   routingId;
    uint64  vmId;
    bytes32 vaultAddress;
    ChainConfig config;
}

function getVaults(uint16 start, uint16 end) external view returns (Vault[] memory);
```

Each registered vault carries a `ChainConfig` of per-chain confirmation-policy overrides applied on top of the protocol defaults ([confirmation times](/funds/deposits#chains-and-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.

```solidity theme={null}
struct MeasurementProfile {
    bool    active;
    bytes32 mrtd;   // code identity, mandatory
    bytes32 rtmr0;  // runtime registers, optional
    bytes32 rtmr1;  // (a zero value skips that check)
    bytes32 rtmr2;
    bytes32 rtmr3;
}
```

* **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](/security/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](/security/consensus#what-a-restart-recovers); the offchain half — fetching the checkpoint and re-supplying its decryption shares — runs in the quorum.

## Governance

High-risk changes are timelocked:

| Change                              | Timelock |
| ----------------------------------- | -------- |
| Risk parameters                     | 48 hours |
| Registry changes                    | 72 hours |
| Code measurements and delay changes | 7 days   |

Vault registration, operator-set changes, and committee thresholds are quorum-gated council operations. Operator constraints, attestation, and the recovery council: [trust model](/security/trust-model).