Bound DocsProtocol Lifecycle
The 12-stage end-to-end flow from building containment to certificate settlement.
Protocol Lifecycle
A containment certificate moves through 12 stages from creation to settlement. This page walks through each one.
Stage Overview
Stages in Detail
1. Build Containment Architecture
The operator designs and deploys the agent's containment system:
- Smart contracts with spending limits, time locks, permission boundaries
- Execution environment (TEE, HSM, MPC as applicable)
- Recovery mechanisms (kill switches, pause functions, reversibility windows)
Each constraint is classified as agent-independent or agent-influenceable.
2. Fund Reserve
The operator deposits:
- Reserve — collateral in exogenous assets (USDC) into a
ReserveVaultcontract
The reserve is locked for the certificate's lifetime plus a grace period.
3. Request Audit
For C2/C3 certificates, the operator engages an independent auditor:
- Defines audit scope based on certificate class
- Deposits audit fee into
FeeEscrow - Provides auditor with access to containment architecture and source code
4. Audit Containment
The auditor examines the containment system across five surfaces:
| Surface | What's Tested |
|---|---|
| Spending limits | Source code review, deployment verification, constraint testing |
| Permission model | Privilege escalation testing, agent independence assessment |
| Reserve | Balance verification, lock-up verification, exogeneity check |
| Execution environment | TEE attestation, HSM configuration, MPC threshold |
| Recovery mechanisms | Kill switch testing, pause functions, reversibility windows |
For C3 certificates, composition analysis is also required — mapping every path money can take and verifying constraints cover all paths.
5. Attest and Stake
The auditor:
- Produces an audit report with findings and recommendations
- Signs the certificate attestation (scoped to what was actually verified)
- Locks their stake in the
AuditorStakingcontract
The audit fee remains in FeeEscrow until the certificate expires and the grace period ends, at which point the auditor can claim it.
6. Compose Certificate
The full certificate object is assembled with all required fields:
- Identity (certificate ID, agent ID, operator ID, chain ID)
- Validity (issued timestamp, expiry timestamp, status)
- Constraints (each with type, value, enforcement mechanism, agent-independence flag)
- Reserve details (amount, denomination, contract address, exogenous flag)
- Derived metrics (containment bound, layer counts)
- Attestations (auditor signatures and scopes)
7. Publish
- Certificate data is uploaded to IPFS (content-addressed, immutable)
- The IPFS hash is registered on-chain via
CCPRegistry.publish() - On-chain event emitted for indexers and monitors
8. Certificate Goes Active
The registry returns isValid = true for this certificate. Counterparties can now query it.
9–10. Verification
When a counterparty wants to transact:
- Lookup — query
ICCPRegistrywith the agent's address - Retrieve — fetch full certificate from IPFS
- Validate — check signatures, schema, completeness
- Check status — confirm
ACTIVE(notREVOKEDorEXPIRED) - Evaluate — apply their own risk policy against certificate data
- Concentration check — optional check for auditor/contract concentration
- Decision — accept, reject, or require additional conditions
11. Termination
A certificate ends in one of three ways:
| Outcome | Trigger | Effect |
|---|---|---|
| Renewal | Operator submits updated certificate before expiry | New certificate replaces old; old marked EXPIRED |
| Revocation | Operator calls revoke() | Certificate marked REVOKED immediately |
| Expiry | Clock passes expires_at timestamp | Certificate marked EXPIRED automatically |
12. Settlement
After termination plus grace period:
- No challenge: Auditor stake released, reserve unlocked, escrowed fee released to auditor
- Successful challenge: Auditor stake slashed (30% challenger, 50% verifiers, 20% burned), escrowed fee clawed back to operator, certificate revoked
Typical Timeline (C2)
| Day | Event |
|---|---|
| 0 | Operator begins building containment architecture |
| 7–14 | Containment deployed, reserve funded, audit requested |
| 14–21 | Audit completed, attestation signed |
| 22 | Certificate published on-chain |
| 22–82 | Certificate active (60-day validity) |
| 75 | Renewal audit begins (if continuing) |
| 82 | Certificate expires |
| 82–96 | Grace period (challenges still possible) |
| 96 | Settlement — all funds released if no challenge |
State Machine
Certificate state transitions are recorded on-chain and are irreversible. An EXPIRED certificate cannot become ACTIVE again — the operator must publish a new one.