One identity surface per participant

We unified the full KYC lifecycle onto one surface. The asset checks a verified on-chain claim at transfer time. The reviewer audits a versioned history. The participant's full picture is never more than one screen away.

Identity & KYC

Claims, not documents: the whole lifecycle in one place

On DALP, a trusted provider verifies a participant and attests the verdict on-chain as an identity claim. The asset's compliance rules check that attestation at every transfer. The underlying documents never touch the asset layer. In 3.0 we pulled every part of that lifecycle (intake, versioned history, monitoring, recovery) onto one surface, closing the gap between verification and enforcement.

Standards

ERC-734 / ERC-735

Checked

At every transfer

Documents

Never on-chain

History

Versioned

The claim is what the asset checks

1. 1
   Verify

   A supported KYC or AML provider checks the participant and produces a verdict: passed, accredited, or cleared for a jurisdiction.

2. 2
   Attest

   The platform maps that verdict into a typed on-chain identity claim, signed by the trusted issuer and recorded on the ledger.

3. 3
   Check

   At every transfer, the asset's compliance rules read the claim. The underlying documents never leave the provider's custody.

4. 4
   Audit

   The versioned claim history and KYC profile stay available for review at any point: what was attested, when, and by whom.

Identity verification in regulated assets typically spans several systems: a KYC provider portal, a separate AML monitoring feed, a manual wallet-recovery process, and a compliance database someone assembled by hand. Keeping those in step is continuous work. The audit trail is only as good as whoever last remembered to update it.

In DALP 3.0, the platform maps verdicts directly into on-chain identity claims and enforces them automatically at transfer. The full participant record lives on a single screen: account, wallets, claims, verification topics, and onboarding status. Nothing to reconcile across systems, and nothing to export before the asset can act.

The design separates what the asset layer needs to know from what the verification provider knows. The asset never receives a passport scan, an address document, or an accreditation certificate. It receives a typed, provider-signed attestation that a specific participant passed a specific check. That claims-not-documents model has a practical consequence: sensitive material stays in the provider's custody, and the stakes for an auditor or regulator are different from the stakes for a developer. What matters is not whether a participant is verified today but whether they were verified when the transfer in question happened, and whether the record can prove it.

A point-in-time audit trail only holds up if it is complete, tamper-evident, and tied to the same identity the asset layer checked at execution time. That is what versioned history is for.

KYC profiles keep a complete versioned history. Each review, each verdict change, and each data update is recorded with a timestamp. A reviewer or auditor can see exactly what was on file at any point in time, not just the current state. Uploaded documents get application-layer encryption at rest, so the material backing a claim is protected independently of the storage infrastructure.

Built on open on-chain identity standards

The claims-not-documents model is not an abstraction invented for DALP. The approach is grounded in open Ethereum standards that define what on-chain identity is, how keys are managed, and how claims are structured and verified. Understanding those standards makes clear why enforcement is trustworthy.

ERC-734 defines an on-chain key holder. An identity contract holds a set of cryptographic keys, each assigned a purpose: management, execution, or claim-signing (purpose 3). When a claim issuer attests a fact about a participant, it does so by signing with a key registered on its own identity contract. The asset layer can verify that signature without trusting the issuer's word. It queries the issuer's identity contract to confirm the signer held claim-signing authority at the moment of attestation. DALP's contracts implement this check directly when validating issuer-signed attestations.

ERC-735 defines an on-chain claim holder. A participant's identity contract stores typed claims, each a tuple of a topic identifier, the issuer's address, a cryptographic signature, and a data payload. The topic identifies what is being attested: KYC clearance, AML screening result, accreditation status, jurisdiction eligibility, or any custom claim a compliance team defines. The signature ties the attestation to a specific issuer key. A transfer check reads the claim from the identity, verifies the signature against the issuer's registered keys, and either passes or blocks the transfer. The original documents play no part in that check.

ERC-3643 is the token standard for regulated assets that pairs directly with the on-chain identity pattern. It specifies that every transfer must pass a compliance check: a registry lookup confirms the recipient holds a verified identity, and claim verification runs against an authorised issuers list. That list records which claim issuer contracts are permitted to attest specific claim topics for a given asset. DALP implements the registry interfaces specified in ERC-3643 and extends them with additional verification logic.

DALP's issuer configuration is subject-aware: it supports both global issuers trusted across every token in a deployment and per-token overrides. Each asset can enforce its own compliance perimeter without a shared configuration becoming a bottleneck. At transfer time, the compliance layer walks the required claim topics, calls verification on the issuer registered for each topic, and only allows the transfer when every required topic resolves to a valid, issuer-confirmed claim on the recipient's identity contract. The claim is what the asset checks, not a database field, not an off-chain signal, not a manual gate.

For institutions, the value of open standards is not only technical. Any custody provider, exchange, or audit firm that understands the on-chain identity standard understands DALP tokens without bespoke adapters. External auditors can evaluate the compliance architecture against the published specification. The standard is public, readable by anyone, and independent of any single vendor's continued existence.

Why it matters for a regulated book

Supported providers

We map verdicts from KYC and AML providers directly into on-chain identity claims. No custom integration work is required for any provider in this set.

KYC and identity verification: Sumsub · Jumio · Middesk · Onfido · Persona · Trulioo · Veriff

AML and transaction screening: ComplyAdvantage · Elliptic · Sumsub

Recovery when a wallet is lost

Standard account recovery flows assume a user can authenticate. When a participant has lost access to a wallet, those flows cannot help. Identity recovery restores access through a dedicated in-platform path that preserves the full identity ownership record and produces an audit trail for the event.

Recover an organization identity squatted on-chain

An organization's on-chain identity can be pre-empted: deployed to a squatted address before the legitimate one is. DALP 3.0 recovers it. The operator deploys a legitimate replacement bound to the organization's recovery salt and re-links it atomically in a single transaction. The recovery is indexed immediately. Every downstream consumer sees the corrected identity at once, with no window where two identities compete.

Verify participant identity → · Manage KYC data → · Configure trusted issuers →