Identity recovery
How DALP replaces a holder's wallet on the identity registry while keeping their OnchainID, claims, and token balances intact.
Use this flow when a verified holder loses access to their original wallet, an operator approves a new address, and the registered entry must continue to satisfy compliance checks against the new address. DALP replaces the wallet pointer on the identity registry, transfers all asset balances through a recovery-scoped path, and records indexed proof of the operation. If you are building a recovery integration or auditing a past case, this page covers the full path from the operator's approval to the final indexed state.
This flow is distinct from an ordinary transfer. It runs through 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 a holder-initiated move.
When this flow applies
Use identity recovery only when all three conditions hold: the original wallet is unrecoverable, the holder has a registered entry with valid claims, and the operator holds the recovery role. All three must be 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 entry in the identity registry with claims that compliance modules already accept.
- The operator holds the platform role required to initiate a recovery and submit the new wallet address.
This flow 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
An ordinary delete-and-re-issue cycle loses the holder's established claim records and prior compliance history. The recovery path avoids that by preserving:
- 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 (KYC checks, country restrictions, allow or block lists) remain in effect. The recovery does not bypass compliance. It directs all checks at the new wallet.
- Asset holdings: every position the holder had on the original wallet transfers to the new wallet through a forced path. Indexed balance history records the operation as a recovery event, not as a holder-initiated transfer.
What the flow does not bypass
Only platform users with the recovery role can initiate a recovery. The role is granted explicitly, separately from ordinary transfer rights.
The operator must complete the platform's verification step before the wallet swap reaches the chain. That step is operating policy. DALP does not define the identification standard, but it does require that the recovery workflow record proof of the step.
Every recovery emits identity-registry and per-token events that the indexer surfaces in the Console, the operator runbook view, and the events catalogue. These events form the durable audit trail.
The recovery operation does not give the operator the ability to mint, burn, or otherwise act on the holder's tokens beyond the transfer itself. Asset-level roles still gate all other operations.
Operating ownership
| Layer | Owns | Read next |
|---|---|---|
| Console / API | Recovery initiation, holder selection, replacement-wallet entry | Recover user identity |
| Workflow Engine | Workflow durability, retries, balance enumeration, forced transfer orchestration | DALP Workflow Engine |
| Identity registry | Wallet replacement on the holder's registered identity | Claims and identity |
| Compliance modules | Recovery-scope evaluation paths, holder-initiated checks remain unchanged for normal use | Compliance modules overview |
| Asset contracts | Forced balance transfer per holding, recovery-event emission | Asset contracts |
| Chain indexer | Recovery and balance events surfaced into operating evidence and API reads | Chain indexer |
Recovery as evidence
Recovery produces two kinds of records. If you are the operator, the indexed events confirm that the platform replaced the wallet correctly and preserved the holder's standing. If you are an auditor or reviewer, the workflow record shows who initiated the recovery, when it ran, which wallet was replaced, which balances moved, and how compliance modules evaluated the operation. Preserve the event timestamps, the original and new wallet addresses, and the name of the operator who ran the workflow in your audit pack.
Read next
- Recover user identity for the console workflow.
- Identity recovery API for the Platform API 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.
Compliance Transfer
Step-by-step sequence for how DALP validates token transfers through recipient identity checks, token-specific compliance modules, global compliance policy, and post-transfer state hooks.
Feeds update flow
How DALP accepts issuer-signed feed updates, validates them on chain, indexes accepted rounds, and exposes current values to contracts, APIs, and the Console.