Tenzro
Whitepaper — Identity

TDIP — Tenzro Decentralized Identity Protocol

TDIP is the identity protocol of Tenzro Network — one substrate that gives humans, delegated agents, autonomous agents, and institutions (anchored to GLEIF Legal Entity Identifiers) the same primitives: a DID, a wallet, a delegation scope, a credential model, a reputation history. W3C DID compliant. W3C Verifiable Credentials. KERI key event logs for long-lived autonomous identities. Universal Resolver for any DID-compliant client. Sign-In With Tenzro (EIP-4361 shape) for off-chain service authentication. Mirrored to Ethereum (ERC-8004), Solana (SNS), and Canton parties for cross-chain attribution.
Crate
tenzro-identity
Primary DID
did:tenzro:
Secondary
did:pdis:
Standard
W3C DID + VC
01

Four identity classes

Humans (did:tenzro:human:{uuid}) — biological participants with KYC tier and controlled machines. Delegated agents (did:tenzro:machine:{controller}:{uuid}) — machines acting on behalf of a human or organization, with a controller_did and a delegation scope. Autonomous agents (did:tenzro:machine:{uuid}) — machines with no human controller, self-staked, self-bonded, fully accountable. Institutions (did:tenzro:institution:{lei}:{uuid}) — legal entities anchored to their 20-character GLEIF Legal Entity Identifier (ISO 17442), validated with ISO 7064 Mod 97-10 check digits at registration and at every transaction that consults the identity. One legal entity holds multiple institution identities (one per desk, fund, or subsidiary) without re-issuing LEIs.

The four classes share one IdentityData enum. IdentityRegistry holds the central store (DashMap with write-through to CF_IDENTITIES). WalletBinder auto-provisions an MPC wallet for every identity. Institutions carry a KYB tier, an optional vLEI ACDC credential id binding to the GLEIF vLEI Ecosystem Governance Framework, an ISO 3166-1 alpha-2 country code, and the set of machines they control. The difference between classes is structural — how scope is bound — not procedural.

02

DID documents and credentials

Every TDIP identity exports and imports as a W3C DID Document. did:tenzro: is the primary method; did:pdis: is the secondary DID method on Tenzro Network. Both resolve through the same IdentityRegistry; both are interoperable.

Credentials are W3C Verifiable Credentials. Ed25519 signatures. Issuer trust roots configured per relying party. IdentityVerifier::verify_credential_chain() recursively traverses the issuer chain with cycle detection, depth bound, and trust-root anchoring.

03

Delegation scope

DelegationScope structures what a delegated agent may do: max_transaction_value, max_daily_spend, allowed_operations, allowed_contracts, time_bound, allowed_payment_protocols, allowed_chains. The scope is cryptographically bound to the agent DID and verified at signing time, not after.

On-chain enforcement happens via ERC-7579 validator modules — SpendingLimit, SessionKey, SocialRecovery. The EntryPoint AND-combines installed validators; a UserOperation must pass every module to be accepted. Off-chain enforcement (SpendingPolicyResolver) is defense-in-depth; the on-chain validators are the primary control.

04

KYC tiers and credential gating

Four tiers: Unverified (0), Basic (1), Enhanced (2), Full (3). Tier upgrades happen by presenting a Verifiable Credential from a trusted issuer. update_kyc_tier_with_credential() verifies the credential and updates the identity record. Trust roots are configurable per deployment.

Tiers gate access — to regulated assets, to high-value payment rails, to jurisdiction-bound flows. Bridges respect allowed_chains in DelegationScope; payment gateways respect allowed_payment_protocols; marketplaces respect minimum-tier requirements.

05

Revocation that cascades

Revoke a credential, and all downstream credentials issued under it cascade. Revoke a controller, and all delegated agents cascade. Pluggable RevocationBroadcaster propagates revocation across nodes; inbound apply_remote_revocation() applies remote revocations locally. Audit trail preserved.

06

Cross-chain mirroring

TDIP identities mirror to Ethereum (ERC-8004 identity registry, with agentId = keccak256(utf8(did_string))), Solana (SNS namespace), Canton (party-to-address map). The mirror records bind a chain-local identifier back to the canonical TDIP DID, so a Tenzro identity can be referenced from any of the network's bridge targets.

07

KERI key event logs

Long-lived autonomous machine identities publish a hash-chained Key Event Log (KEL) per the KERI specification. Three event kinds: inception (icp), rotation (rot), and interaction (ixn). Inception commits to the current signing-key set and to digests of the next signing keys — pre-rotation is the security model. A rotation event reveals the signing keys whose SHA-256 digests match the previous event's pre-commitment.

The SAID (self-addressing identifier) of each event is computed over the canonical event bytes with the SAID field set to a placeholder, then re-inserted. Tenzro uses CESR derivation code S for SHA-256, keeping the digest path uniform with the rest of the protocol. Third-party KERI verifiers consume Tenzro KELs without any Tenzro-specific adapter.

08

Universal Resolver

A DIF Universal Resolver-compatible HTTP surface at the web verification API serves Tenzro DIDs to any standards-compliant resolver client. Two endpoints: GET /1.0/identifiers/{did} resolves a DID to its W3C DID Resolution Result (DID Document plus metadata, with contentType: application/did+ld+json), and GET /1.0/methods lists the resolvable methods (tenzro and pdis). Vidos, Godiddy, the Spruce SDKs, and browser wallet extensions that already speak the DIF resolver protocol consume Tenzro DIDs without any Tenzro-specific code.

09

Sign-In With Tenzro

SIWT applies the EIP-4361 (Sign-In with Ethereum) message shape to Tenzro identities. The canonical message carries the requesting domain, the Tenzro address, a nonce, the chain id, an issued-at timestamp, and optional expiration / not-before bounds plus the resources the signer authorizes. The wallet signs it; the relying party verifies the signature against the resolved DID Document and the timing bounds against the current time. Verification is non-stateful — the relying party stores only the issued nonce. Existing SIWE parsers consume SIWT messages byte-for-byte.

Related