# Identity and compliance control model

Source: https://docs.settlemint.com/docs/architecture/security/identity-compliance
How DALP links wallets to OnchainID identities, keeps evidence off chain, trusts claim issuers by topic, and evaluates claims before regulated token operations execute.




DALP separates account access from asset eligibility. A caller can be authenticated, authorised, and still be unable to receive or move a regulated asset until the relevant wallet is registered to an identity and that identity carries claims from trusted issuers for the asset's configured rules.

For the canonical concept model behind wallets, OnchainID contracts, claim topics, and trusted issuers, start with [Claims and identity](/docs/architecture/concepts/claims-and-identity).

## System context [#system-context]

<Mermaid
  chart="`classDiagram
  direction LR
  class WalletAddress {
    +submitAssetOperation()
    +mapToIdentity()
  }
  class OnchainIDIdentity {
    +holdERC734Keys()
    +holdERC735Claims()
  }
  class ComplianceClaim {
    +uint256 topic
    +bytes issuerSignature
    +bytes claimData
  }
  class ExternalEvidenceSystem {
    +holdKycAmlEvidence()
    +recordProviderDecision()
  }
  class ProviderOrManualIssuer {
    +reviewEvidence()
    +issueOrRevokeClaim()
  }
  class TrustedIssuerRegistry {
    +approveIssuer()
    +allowTopic()
  }
  class IdentityRegistry {
    +bindWalletToIdentity()
  }
  class TokenComplianceModules {
    +evaluateAssetRules()
    +gateMintAndTransfer()
  }
  class ConfiguredEVMNetwork {
    +executeTokenStateChange()
  }

  WalletAddress --> IdentityRegistry : registered in
  IdentityRegistry --> OnchainIDIdentity : resolves
  ExternalEvidenceSystem --> ProviderOrManualIssuer : supplies decision evidence
  ProviderOrManualIssuer --> ComplianceClaim : issues or revokes
  OnchainIDIdentity --> ComplianceClaim : stores
  TrustedIssuerRegistry --> ComplianceClaim : accepts issuer/topic
  TokenComplianceModules --> IdentityRegistry : checks holder identity
  TokenComplianceModules --> TrustedIssuerRegistry : checks issuer trust
  TokenComplianceModules --> ConfiguredEVMNetwork : gates operation

`"
/>

## The model [#the-model]

Identity and compliance use four linked concepts:

| Concept        | Scope                                            | What it decides                                                                                   |
| -------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| Wallet         | User, participant, issuer, or service account    | Which blockchain address submits, receives, or signs an operation                                 |
| Identity       | OnchainID contract linked to one or more wallets | Which on-chain identity the asset contract checks for a wallet                                    |
| Claim          | Topic-specific statement stored on an identity   | Whether the identity has evidence such as KYC, AML, jurisdiction, accreditation, or issuer status |
| Trusted issuer | Claim issuer approved for one or more topics     | Whether a claim source is accepted for the topic an asset rule requires                           |

A wallet address by itself is not enough for regulated asset operations. The token's identity registry resolves the wallet to an identity contract. Compliance modules then evaluate the claims and rule parameters configured for the asset.

## Identity binding [#identity-binding]

A DALP identity is an OnchainID contract. The identity can hold ERC-734 keys and ERC-735 claims. DALP registers wallet addresses against identities in the asset identity registry so token contracts can resolve the identity behind a sender or recipient during execution.

Two common paths create the binding:

1. Self-service or admin-led onboarding registers a user's wallet to an identity.
2. System and provider workflows create participant identities for organisations, claim issuers, or provider-controlled issuer accounts.

Pending-identity registration is replay-safe for partial retries. When DALP registers an existing or newly created identity as pending, the workflow first authorises the trusted-issuers registry on the identity. If that authorisation was already written by an earlier partial attempt, the workflow continues instead of failing the retry.

## Registry and network scope [#registry-and-network-scope]

Address reuse does not make a wallet globally eligible. Identity and claim checks run in the active registry context: the configured EVM network, identity registry, trusted-issuers registry, and topic-scheme registry used by the asset operation.

The same wallet or OnchainID can appear in more than one registry context. For each request, the compliance modules evaluate decoded claim values and issuer trust against the registries configured for that asset. A claim visible in one registry context does not satisfy a rule in another unless the identity is registered there and the issuer is trusted for the required topic.

For multi-network programmes, onboard participants per configured EVM network. Register the participant wallet for the network where the asset lives, configure trusted issuers and claim topics for that network's registries, and issue or import the claims that the asset's compliance modules require. Reusing the same wallet address across networks does not replace those checks.

For the execution path, see [Compliance transfer flow](/docs/architecture/flows/compliance-transfer). For the privacy boundary between public EVM state and off-chain evidence, see [Public chain privacy](/docs/architecture/security/public-chain-privacy).

## Claims and topics [#claims-and-topics]

A claim is scoped by topic. Topics represent the kind of statement being made, such as KYC status, AML screening, investor qualification, jurisdiction, or issuer licensing. The topic identifier is the value the compliance rule checks, not the display label shown to an operator.

Claims live on the identity contract. The claim stores the topic, issuer, signature, data, and URI fields defined by the OnchainID claim model. DALP keeps identity evidence and provider documents off chain. The on-chain claim is the verification signal that token contracts can evaluate.

## Trusted issuers [#trusted-issuers]

A trusted issuer is an identity that DALP accepts as a claim source for selected topics. The trusted-issuers registry stores the issuer identity and its allowed topic set. A claim only helps a transfer or mint when the issuer is trusted for the topic the asset rule requires.

DALP supports two current issuer patterns:

| Issuer pattern            | How it is used                                                                                                                                                               |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Manual or internal issuer | A compliance operator or internal service issues claims after reviewing evidence. Use this when the organisation owns the final decision.                                    |
| Provider issuer           | A compliance-provider integration provisions a tenant-scoped issuer identity and EOA. Provider events can then issue, update, or revoke claims for the mapped DALP identity. |

Provider issuers are tenant-scoped and provider-scoped. DALP registers the provider's OnchainID identity as the trusted issuer, while the provider EOA is the operational key used for downstream claim transactions.

## Transfer and mint eligibility [#transfer-and-mint-eligibility]

When a regulated token operation runs, the SMART Protocol checks identity and compliance before allowing the state change.

| Operation                   | Identity lookup                                                       | Compliance result                                                                                  |
| --------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Transfer                    | Sender and recipient wallets resolve through the identity registry.   | The operation executes only when configured modules accept the identities and transfer parameters. |
| Mint                        | Recipient wallet resolves through the identity registry.              | Minting executes only when the recipient satisfies the asset's configured eligibility rules.       |
| Burn or redemption          | Sender identity is evaluated when a configured module requires it.    | The operation executes only when the applicable modules accept it.                                 |
| Forced transfer or recovery | Uses the ERC-3643 recovery path rather than the normal transfer path. | Do not treat ordinary transfer compliance checks as the control that blocks recovery operations.   |

The same claim can be valid for one asset and insufficient for another. Eligibility depends on the asset's configured claim topics, trusted issuers, and compliance modules.

## Two-layer policy model [#two-layer-policy-model]

DALP separates platform permission from asset eligibility:

1. Platform controls decide who can request an action in DALP. This layer includes authentication, role-based authorization, wallet verification, custody policy, and signer configuration.
2. Asset controls decide whether the regulated token operation can execute. This layer resolves wallets to identities, checks required claims from trusted issuers, and applies the asset's compliance modules.

Passing the first layer does not bypass the second. A user may be allowed to request a transfer while the token contract still rejects the operation because the sender, recipient, claim source, or transfer parameters do not satisfy the asset policy.

## Verification lifecycle [#verification-lifecycle]

Identity verification is not a single global status. A participant can have multiple claims, issued by different trusted issuers, for different topics. Compliance-provider intake can issue, update, or revoke provider-backed claims when the provider sends new evidence. Manual or internal issuer workflows can issue claims after the organisation reviews evidence outside the provider flow.

For operators, the lifecycle is: collect or receive evidence, map it to the correct DALP identity, issue the claim from a trusted issuer for the relevant topic, and let token operations evaluate the current claim set at execution time. Revoked, missing, or untrusted claims do not satisfy rules that require that topic.

## Audit and privacy scope [#audit-and-privacy-scope]

Use the identity registry and trusted-issuer registry as the inspection points for eligibility. The identity registry shows whether a wallet is registered and which identity contract it resolves to. It also points to the registries that define trusted issuers and valid topics. The identity-verification module evaluates the recipient against the configured claim expression before the token operation can continue.

The claim does not put the underlying KYC, AML, accreditation, or provider documents on chain. It records the on-chain verification signal that the token contract can evaluate. Keep the evidence pack in the connected compliance provider, custody provider, or organisation evidence system. Use the on-chain identity, claim, issuer, and module configuration as the DALP execution scope.

For production review, check these facts together:

| Check               | What to verify                                                                                                |
| ------------------- | ------------------------------------------------------------------------------------------------------------- |
| Wallet registration | The sender or recipient wallet resolves to the expected OnchainID identity.                                   |
| Claim expression    | The asset's identity-verification module is configured with the required claim topics and logical expression. |
| Issuer trust        | The claim issuer is trusted for the topic the rule requires.                                                  |
| Evidence location   | Supporting documents remain in the external evidence system, not in the public EVM state.                     |
| Revocation path     | Revoked, missing, expired, or untrusted claims fail the rule instead of becoming a soft warning.              |

For example, an investor can pass platform authentication and still fail a token mint when their OnchainID lacks the required KYC topic, when the claim issuer is not trusted for that topic, or when the latest provider event revoked the claim. Review the identity registry entry, trusted issuer topic set, and current claim state together before treating the wallet as transfer-ready.

## Provider event ordering [#provider-event-ordering]

Compliance-provider intake maps provider subjects to DALP identities before applying provider events. DALP orders events for the same provider subject, so a duplicate or older event for that subject cannot overwrite a newer applied event.

Distinct provider aliases can map to the same DALP identity. Treat alias reconciliation as an integration concern: send stable provider subject identifiers where possible, and review unmapped events instead of assuming DALP can merge every alias automatically.

Provider events carry timestamps, sequence values, or provider event identifiers depending on the provider. DALP uses those values to skip duplicates and avoid applying older evidence over newer evidence for the same provider subject. Unmapped events are recorded for review instead of silently issuing claims to an unknown identity.

## What this model does not decide [#what-this-model-does-not-decide]

Identity and compliance claims decide asset eligibility. They do not replace the other security layers:

* Authentication decides who is calling DALP.
* Authorization decides whether the caller can perform the requested platform action.
* Wallet verification confirms sensitive browser-session actions.
* Custody-provider policy and signer configuration decide whether a prepared transaction can be signed.
* Public EVM execution still exposes on-chain addresses, balances, and transactions according to the network's visibility rules.

Use this page as the conceptual model for claims and identities. Use the task and reference pages below for operator steps and API details.

## See also [#see-also]

* [Configure trusted issuers](/docs/developer-guides/compliance/configure-trusted-issuers) for the API workflow that approves issuers by topic.
* [Choose a KYC issuance path](/docs/developer-guides/compliance/choose-kyc-issuance-path) for choosing manual claim issuance or provider-driven intake.
* [How compliance provider intake works](/docs/architecture/integrations/compliance-providers) for provider claim-source flows.
* [Compliance modules](/docs/architecture/security/compliance) for the rule modules that evaluate claims during token operations.
* [Public chain privacy](/docs/architecture/security/public-chain-privacy) for what identity and asset activity remains visible on public EVM networks.
* [Signing flow](/docs/architecture/flows/signing-flow) for the transaction path after authorization and compliance checks pass.