Compliance overview
Choose the DALP compliance controls that govern asset eligibility, transfer approvals, supply limits, collateral checks, and trusted verification issuers.
DALP compliance is for asset issuers, compliance operators, Identity Managers, and auditors who need to understand which controls govern a regulated asset. It combines asset-level modules, reusable policy templates, and trusted verification issuers.
Asset issuers configure the controls an asset must enforce. Identity Managers review participant evidence. Trusted issuers add on-chain verification claims. Transfers, minting, and holder eligibility then pass only when the configured controls approve the action.
What is DALP compliance?
Compliance controls sit between participant onboarding and asset activity. DALP enforces policy conditions that the platform can verify on-chain or through configured verification claims. Your organisation still owns the legal policy, KYC provider, custody provider, and off-chain evidence process.
Quickstart
Use this sequence when you prepare a regulated asset:
- Decide the policy requirement for the asset, such as KYC eligibility, country restrictions, transfer approval, investor caps, supply caps, or collateral backing.
- Select a compliance template or configure individual modules during asset creation.
- Configure the trusted issuers that can issue the verification topics your controls require.
- Review participant or asset evidence off-chain where required, then issue the matching on-chain verification claim.
- Operate the asset. DALP checks every configured module for the relevant action.
Who owns what
| Area | Owner in DALP | What DALP enforces | What stays with your organisation |
|---|---|---|---|
| Compliance policy | Asset issuer or governance role | The selected modules, thresholds, lists, approval authority, and template copied into the asset configuration. | The legal policy, regulatory interpretation, approval procedure, and decision to change controls. |
| Participant evidence | Identity Manager | KYC submission status, review actions, and the path to issuing an on-chain verification after approval. | Evidence collection standards, document validation, data protection duties, and escalation process. |
| Verification trust | Verification Policy Manager or platform administrator | Which issuer identities are trusted for each verification topic at system or inherited registry level. | Issuer selection, independence checks, and periodic review of issuer authority. |
| Verification claims | Trusted issuer | On-chain claims for topics such as KYC, accreditation, AML, or collateral when the issuer is trusted for that topic. | Source evidence, renewal cadence, revocation decisions, and external provider monitoring. |
| Asset activity | Compliance modules | Whether a mint, transfer, or holder eligibility check passes all configured controls. | Business decisions after a blocked action, customer communication, and off-chain remediation. |
Choose a compliance control
Start from the rule you need to enforce, then choose the DALP control that matches that rule. Use a compliance template when the same policy pattern should be reused across assets. Use individual modules when one asset needs a specific control.
| Policy need | DALP control | Where to configure it | Read next |
|---|---|---|---|
| Require holders to pass KYC, accreditation, or another OnchainID claim | Identity verification | Add the module directly or include it in a compliance template. | Verify KYC |
| Allow or block specific identities or addresses | Identity lists or address block list | Configure the list during asset creation or update it later with the asset governance role. | Compliance module index |
| Restrict holders by country | Country restrictions | Select allowed or blocked countries in the compliance step. | Compliance module index |
| Limit supply, investor count, capital raised, or issuance volume | Supply and investor limits, capital raise limit, or issuance volume limit | Configure the numeric limit and period before the asset is used by holders. | Create asset |
| Enforce a holding period before transfers | Time lock | Configure the hold period and any identity-based exemptions for the asset. | Time lock architecture |
| Require transfer review before execution | Transfer approval | Configure the approval authority and approval conditions for the asset. | Transfer approval architecture |
| Require collateral evidence before minting | Supply cap and collateral or collateral requirement | Configure collateral controls for assets that need backing evidence. | Collateral requirement |
If your workflow depends on a third-party KYC, KYB, AML, sanctions, or travel-rule provider, use provider-issued claims alongside these controls. The on-chain compliance module enforces the claim or policy condition. The provider integration supplies the external screening or monitoring signal. See compliance provider integrations.
How modules work together
When multiple compliance modules are enabled, every enabled module must pass for the action to proceed. A transfer that satisfies KYC but fails a country restriction is blocked. A mint that satisfies role checks but lacks enough collateral evidence is blocked. A transfer approval requirement stays separate from KYC or collateral claims, so the asset can require both prior approval and verified holder eligibility.
Compliance modules can validate different parts of the lifecycle. Burns are role-gated asset operations; compliance modules may update accounting after a burn, but they are not the approval path that blocks the burn.
| Control family | Typical check point | Example result |
|---|---|---|
| Identity and country controls | Holder eligibility and transfers | Recipient must have a trusted KYC claim and an allowed country claim. |
| Lists and address controls | Sender or recipient checks | A blocked address or identity cannot participate while the control applies. |
| Supply and issuance controls | Minting, investor-count checks, and lifecycle accounting | Minting stops when a supply cap, capital raise limit, or issuance-volume rule would be exceeded. A transfer to a new holder stops when it would exceed an investor-count limit. |
| Transfer approval | Transfer execution | The transfer must have the required approval before it executes. |
| Collateral controls | Minting | The asset identity must have a valid collateral verification with enough backing for the post-mint supply. |
Verification system
Verifications are on-chain attestations that confirm facts about investors, issuers, assets, or contracts. A verification only satisfies compliance when the issuer is trusted for the relevant topic.
Each verification contains:
- Topic: what is being verified, such as KYC, accreditation, AML, or collateral.
- Scheme: the signature scheme used for the claim.
- Issuer: the identity that issued the verification.
- Signature: the cryptographic signature for the verification.
- Data: verification details, often represented in a privacy-preserving form.
- URI: an optional reference to supporting data.
Verifications do not have expiration dates by default. If a topic needs renewal, revocation, or expiry handling, define that in your operating process and issue or revoke claims accordingly. Collateral verifications are an example of a workflow where expiry matters because minting depends on current backing evidence.
Trusted issuers
Any identity with an on-chain presence can technically issue a verification. DALP compliance controls only count the verification when the issuer is trusted for the required topic.
Trust is organisation-specific and topic-specific:
- One issuer can be trusted for KYC but not for collateral.
- One organisation can trust an issuer that another organisation does not trust.
- System-level trust entries can inherit from a parent global registry when configured.
- Removing a system-managed trusted issuer stops that system trust entry from satisfying checks, while inherited global trust can still apply until changed in the parent registry.
Use Configure trusted issuers to manage the issuers and topics your assets rely on.
Verification topics
Common topics include investor eligibility, asset evidence, issuer status, and contract identity. The exact topics your organisation uses should match the policy controls configured on each asset.
| Topic area | Examples | Used for |
|---|---|---|
| Investor-level topics | KYC, AML, accredited investor, professional investor, Regulation S | Holder eligibility and transfer checks. |
| Asset-level topics | Collateral, classification, base price, unique identifier, issuer, location | Asset evidence and minting or reporting controls. |
| Issuer-level topics | Prospectus filed, prospectus exempt, licensed, reporting compliant, jurisdiction | Issuer qualification and review evidence. |
| Contract topics | Contract identity | Contract-level identity verification. |
Production checklist
Before holders use the asset, confirm that:
- The asset uses the compliance template or individual modules that match the policy.
- Governance roles can update lists, thresholds, approval authorities, and module settings when policy changes.
- Trusted issuers are configured for every verification topic the asset requires.
- Identity Managers know which evidence to review before a trusted issuer adds a claim.
- Provider-issued screening or monitoring signals map to the verification topics your controls enforce.
- Collateral-backed assets have a renewal, revocation, and evidence review process for collateral verifications.
- Your operations team knows how to respond when a configured module blocks a mint, transfer, or holder check.
Related guides
- Compliance templates explains how to group modules into reusable policy patterns.
- Configure trusted issuers explains how to trust issuer identities for specific verification topics.
- Manage KYC data explains how Identity Managers review participant submissions before verification.
- Verify KYC explains how a trusted issuer adds a KYC verification.
- Collateral requirement explains how collateral verification blocks or allows minting.
- Compliance module index lists the available module-level architecture pages.