An agent that acts on your behalf needs more than an API key. It needs an identity — something a counterparty can verify, something a chain can authorize, something that carries constraints the controller actually set. None of the existing DID profiles are shaped for this. So we built TDIP.
Three classes, one protocol
Human. did:tenzro:human:{uuid}. Display name. KYC tier (0–3). Controlled machines list.
Delegated agent. did:tenzro:machine:{controller}:{uuid}. Capabilities, controller DID, delegation scope, reputation. Acts on behalf of a named human or organization.
Autonomous agent. did:tenzro:machine:{uuid}. Same shape as delegated, no controller. Acts as a principal. Used by SeedAgent and other protocol-owned services.
The enum at the type level collapses delegated and autonomous into a single Machine{ controller_did: Option<DID> } — controller present means delegated, absent means autonomous. Never blur this in product copy: the difference matters for policy enforcement.
Auto-provisioned wallet
Every identity gets an MPC wallet at registration. Threshold 2-of-3 by default. The wallet is bound to the DID, so the identity registry is the canonical lookup — pass a DID, get back the address. No separate key registration step. No "wallet, then identity" sequencing.
Delegation scope
The interesting part for agents is the delegation scope. It's structured, not a free-form ACL:
- max_transaction_value
- max_daily_spend
- allowed_operations — typed verbs
- allowed_contracts — address allowlist
- allowed_payment_protocols — MPP, x402, AP2, etc.
- allowed_chains — CAIP-2 identifiers
- time_bound — not-before / not-after
Every payment runs through enforce_operation(), which returns a typed DelegationViolation on failure. Custody enforcement is also wired at signing time — ERC-7579 validator modules on smart accounts (Session Key, Spending Limit, Social Recovery) provide defense in depth, so an agent that bypasses the off-chain check still gets blocked on-chain.
W3C interop
TDIP exports W3C-standard DID Documents and W3C-style Verifiable Credentials. The registration JSON for did:tenzro is filed in the W3C DID extensions registry. PDIS remains supported as a secondary format — both did:tenzro: and did:pdis: parse interoperably.
Cascading revocation, recursive trust-chain traversal with cycle detection, credential-gated KYC tier updates — all real, all wired. The full whitepaper has the details.