TDIP — Tenzro Decentralized Identity Protocol

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.

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.

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.

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.

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.

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.

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.

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.

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.

A machine identity has to be answerable to something other than itself — an identity that answers only to itself is a self-issued claim, indistinguishable from ten thousand more minted by the same script. Tenzro admits a machine under one of two anchors, and there is no third: delegated, where a human or institution registered it and remains accountable, or hardware-rooted, where an attestable root of trust stands in the delegating party’s place — a TPM endorsement key, a Secure Enclave, an SEV-SNP VCEK, an SGX/TDX provisioning id, a StrongBox or QFPROM key, an ATECC608 or SE050 element, an ESP32 signature peripheral.

The distinction that carries the weight is attestable versus merely per-unit. Identifier sources are graded in three tiers. Model sources (Arm MIDR_EL1, x86 CPUID) name a design, not a unit. Fused sources (Intel and AMD PPIN, Apple ECID, Rockchip OTP, Raspberry Pi serial, SMBIOS UUID) are per-unit but readable— anything running on the machine can read them and anything anywhere can then claim them. Only attestable sources prove possession without disclosing a secret. Accepting a fused serial would make the anchor rule cosmetic.

Accelerator identifiers are never identity. A GPU is the most-swapped component in a machine; rooting identity in one makes the identity follow the card out of the chassis.

A machine that holds its own signing key seals it to that hardware rootrather than writing a keyfile. A key in a file is copyable by anything that can read it — a backup, a stolen disk, a container escape — and copying it makes you the machine, with no human to notice. A host that cannot seal is refused rather than degraded to a plaintext keyfile.

Ownership moves on whatever anchors the machine. A delegated machine transfers on its controller’s authority; a hardware-rooted one on proof of its root. The two are not interchangeable — holding the hardware cannot take a machine that has an accountable party, because that is a compromise rather than an acquisition. Authorisations are time-bounded so they cannot be replayed against a machine that has since changed hands.

A Tenzro identity links devices the way a platform account links them — except the link is not a platform account. No Apple, Google or Microsoft sign-in is an identity authority here. What the network trusts is a signature from vendor-placed hardware over a challenge Tenzro chose, verified against a root the operator pinned and matched by AAGUID through the FIDO Metadata Service.

A device counts as hardware-boundonly when both hold: the credential cannot be replicated off the device, and an attestation says its key lives in a TEE or secure element. Neither implies the other. A credential advertising backup-eligibility is disqualified outright — one that may sync proves control of a cloud account, not possession of a device. Where the certificate chain cannot be verified the grade is degraded rather than the parse failing, so an operator who has pinned no roots gets an honest answer instead of a silent pass.

For a phone there is no readable per-unit serial to collect — Apple and Google removed them from application reach years ago, deliberately. The attested credential key is the device identity, which is why the attestation and not the serial is what gets checked.

A wallet cannot be created behind a single device. The machine the user is already on is the first; a genuinely separate hardware-bound device — a phone, another machine — must be bound before there is anything to lose. Two passkeys on one laptop are two ways into one box that a single failure takes together.

Sessions name the bound device that authorised them, not merely the identity. A session recording only that a user is signed in cannot be revoked when they lose a phone without signing them out everywhere, including from the laptop still in their hands. Unbinding a device therefore ends exactly the sessions it granted, and both happen in one action.