Identity recovery

Identity recovery replaces a holder's wallet on the identity registry while keeping the holder's OnchainID, registered claims, and existing token balances intact. Use the flow when a verified holder loses access to their original wallet, an operator approves a replacement, and the registered identity must continue to satisfy compliance checks against the new wallet.

This flow is distinct from an ordinary transfer. It runs through identity-recovery-specific controls, retains the holder's claim record rather than re-issuing claims, and updates balances through a forced path that compliance modules treat as recovery-scope rather than holder-initiated movement.

When this flow applies

Identity recovery applies when all of the following are true:

• The holder's original wallet is unrecoverable (key loss, hardware failure, credential compromise) and the operator has confirmed the holder's identity through the platform's verification process.
• The holder has a registered identity in the identity registry with claims that compliance modules already accept.
• The operator has the platform role required to initiate a recovery and submit the new wallet address.

Recovery does not apply to wallet-level key rotation that the holder can perform themselves through smart-wallet signer changes, nor to claim updates that an operator can issue directly against the holder's existing wallet.

Sequence

What the flow preserves

The identity-recovery path retains data that an ordinary delete-and-re-issue cycle would lose:

• OnchainID and claims: the holder's identity contract address and the claims signed by trusted issuers continue to apply to the new wallet. Compliance modules read the same claim records they did before recovery.
• Compliance state: claim-driven modules (identity verification, country restrictions, identity allow or block lists) remain in effect. The recovery does not bypass compliance — it points compliance checks at the replacement wallet.
• Asset holdings: every position the holder had on the original wallet transfers to the replacement wallet through a forced path. Indexed balance history reflects the recovery as a recovery event, not as a holder-initiated transfer.

What the flow does not bypass

• Operator authorization: only platform users with the recovery role can initiate a recovery. The role is granted explicitly, separately from ordinary transfer authority.
• Holder identification: the operator must complete the platform's verification step before the wallet replacement reaches the chain. The verification step is operating policy; DALP does not define the identification standard, but it does require that the recovery workflow record evidence of the step.
• Audit-log emission: every recovery emits identity-registry and per-token events that the indexer surfaces in the Asset Console, the operator runbook view, and the events catalogue. The events are the durable audit trail.
• Per-asset roles: recovery does not grant the operator the ability to mint, burn, or otherwise act on the holder's tokens beyond the recovery transfer. Asset-level roles still gate other operations.

Operating ownership

Recovery as evidence

Identity recovery is operating evidence in two directions. For the operator, the recovery confirms the platform replaced the holder's wallet correctly and preserved their compliance posture. For the auditor or reviewer, the indexed events plus the workflow record show who initiated the recovery, when it executed, which wallet was replaced, which balances moved, and how the compliance modules treated the operation. Preserve the recovery event timestamps, the original and replacement wallet addresses, and the workflow operator identity in the environment's audit evidence pack.

Read next

• Recover user identity for the console workflow.
• Identity recovery API for the dapi-side integration shape.
• Claims and identity for the data model behind OnchainID claims and the registry.
• Compliance modules overview for how recovery interacts with per-asset policy.