Token Lifecycle

Tokens in dregg follow a one-way lifecycle: they are minted, attenuated (restricted), delegated to other agents, presented for verification, and eventually expire or are revoked. Tokens can never be amplified -- only narrowed.

Mint

A root token is created with cclerk.mint_token(root_key, service). The root key is the HMAC secret that anchors the entire token chain. Anyone with the root key can forge tokens for that service.

Attenuate

Attenuation adds cryptographic caveats (restrictions) to a token. The Attenuation struct supports:

Delegate

Delegation = attenuation + packaging for transmission. The delegatee receives an attenuated token without the root key (they cannot forge new roots).

Present

Presentation generates a proof (trusted clearance, selective disclosure, or full STARK) and returns an AuthorizationPresentation that the verifier can check.

Verify

Verification checks the presentation against an expected federation root. For trusted mode, this is local Datalog evaluation. For STARK modes, this is proof verification (~2ms).

Tokens in Sovereign Mode

In sovereign mode, capabilities are part of the agent's local cell state. The federation never sees your capability set. Exercising a capability on another agent's cell works peer-to-peer: you prove "I hold this cap" via a Merkle witness into your own state, and the target verifies locally. The federation is only needed if you want to prove capability possession to a stranger who requires an attested root anchor.

For an animated walk-through of a delegation envelope (issue → attenuate → revoke → expire), see the capabilities page; the v2 envelope structure and authority-policy decision graph are covered there. Token-error edge cases (expired, malformed, revoked, mis-scoped) surface as typed errors from dregg_token::verify — match on the variant rather than the message string.