Write your compliance policy once
Package a compliance policy (identity, jurisdictions, supply caps, approvals) once and apply it to every asset in a program, enforced at every transfer.
On DALP, compliance is not a checklist a human runs before a transfer. Rules are enforced on-chain on every transfer, automatically. A compliance template packages those rules once. Every instrument in the program reuses them.
In most digital asset programs, policy lives in two places at once: a document the compliance team maintains, and a set of controls the asset team manually reconstructs for each new instrument. That split is where drift begins. A jurisdiction gets added to the document but missed on an asset. A cap is updated in one place but not the other. A transfer clears that shouldn't have. Compliance templates close that gap by making the policy itself the deployable artifact. The compliance team configures it once; every asset selects and inherits the current version of the rules.
A compliance template is a versioned policy the chain enforces on every transfer
Holdings, transfers and investor caps all run through a compliance policy deployed on-chain. A template is the reusable, versioned form of that policy: jurisdiction rules, identity requirements, supply limits, and approval gates. The compliance team configures it once; the asset team applies it consistently, from the same configuration.
- Standard
- ERC-3643
- Enforced
- On every transfer
- Frameworks
- Nine templates
- Reuse
- Any asset
A template specifies which identities can hold the instrument, which jurisdictions are allowed, and which limits or approvals apply. Review those choices for the instrument before publishing the template.
An on-chain policy enforces the configured checks. Legal review and the correctness of external claims remain separate responsibilities.
- A reviewer runs a manual checklist before each transfer.
- The policy lives in a document; enforcement depends on people reading it.
- Each new asset rebuilds the same controls from scratch, with drift.
- A policy update means finding and updating every asset individually.
- Rules are enforced on-chain on every transfer, automatically, with prior approval when the policy requires it.
- The compliance team owns the template once; the asset team applies it consistently.
- New assets inherit the current policy by selecting a published template.
- Integration teams read the active controls through the API and CLI without touching on-chain state directly.
How it works
- 1Define
The compliance team configures identity requirements, jurisdiction rules, supply caps, approval gates, and collateral controls in a draft template.
- 2Publish
Publishing makes the template available for asset creation. Drafts can be edited freely; a published template is the version the asset team selects.
- 3Apply
The asset team selects the published template during asset creation. DALP copies the module configuration into the asset's on-chain compliance policy.
- 4Enforce
Every transfer runs through the deployed policy on-chain. Configured approval rules can require review before the on-chain checks allow a transfer.
Each template is a versioned collection of compliance modules: individual rule primitives that govern investor eligibility, geographic reach, supply caps, and approval gates. A template groups the modules that belong together in a regulatory context, so the asset team doesn't rebuild the same pattern for every instrument.
The two-team workflow is deliberate. The compliance team owns the template lifecycle: configure, review, publish. The asset team never touches the controls directly. They select a published template during asset creation, and DALP copies the full module configuration into the on-chain policy. That boundary lets the asset team move fast without making compliance decisions, and lets the compliance team update the framework in one place knowing every new asset picks it up correctly.
Built on the ERC-3643 standard
DALP uses ERC-3643 interfaces for permissioned tokens, with OpenZeppelin contract primitives.
What ERC-3643 is
ERC-3643 defines how a regulated security token enforces transfer rules directly at the contract level. An ERC-3643 token is a controlled token: every operation (mint, move, burn) must clear a compliance check before it settles on-chain. That check is embedded in the token's transfer logic, not layered on top. If the compliance policy says no, the transfer does not happen. The rules fire at the chain level, automatically, with no path around them.
The identity registry
Central to ERC-3643 is the identity registry: an on-chain record that maps each investor wallet to a verified identity and a set of claims written by trusted issuers. When a transfer is attempted, the token queries the registry: is this wallet registered? Does the holder carry the required claims: KYC cleared, AML passed, accreditation confirmed, jurisdiction eligible? Wallets without the right credentials from the right issuers are rejected at the token level. In DALP, the registry is the same infrastructure that powers the on-chain identity surface: shared claim topics, shared issuer configuration, and the same per-wallet eligibility record feeds the policy.
Modular compliance
ERC-3643 separates the token from its compliance rules through a dedicated compliance contract. DALP extends that into a fully modular architecture. Each module is a discrete rule over one dimension of policy: identity eligibility, jurisdiction allowlists and blocklists, supply and investor caps, transfer approvals, and collateral requirements. Modules compose into a policy template at creation time; the on-chain compliance contract calls each in sequence on every transfer. Adding or removing a module changes the policy without touching the token contract. Compliance templates are precisely that: named, versioned rule compositions, packaged once and applied consistently to every asset that selects the template.
Why an open standard matters
The published ERC-3643 specification lets an integrator inspect the expected interfaces. A custody provider or exchange must still support the token's active controls and operating requirements.
What the compliance team configures
A template is assembled from modules, each a discrete and configurable rule over a single dimension of policy. The compliance team sets them together in a draft, reviews the full picture, then publishes. What the asset team sees is the template name; what goes on-chain is the full module set behind it, locked in at creation time. Each module addresses one dimension:
Name the trusted issuers whose claims you accept and the topics they must cover: KYC, AML, accreditation, suitability, or a custom claim topic. Transfers from holders who don't meet the configured verification threshold are rejected on-chain.
Allow specific investor jurisdictions or block them. Templates for MiCA, MAS, Japan FSA, and other regimes encode the residency requirements for their framework; clone and adjust for your exact footprint.
Cap total token supply and maximum investor count. Reg D 506(b)'s 35-non-accredited-investor ceiling and Reg CF's $5M annual limit are encoded in the built-in templates; set your own values when you clone.
Require maker-checker review (one operator proposes the transfer, a second must approve it) before a transfer settles, or require collateral evidence before issuance. The approval gate is part of the on-chain policy; it doesn't live in a workflow that someone can bypass.
Nine regulatory templates, or your own
We ship nine built-in templates, each encoding a real regulatory regime's identity checks, residency requirements, and supply constraints. Clone the closest one and shape it to your own: set the trusted issuers, adjust jurisdictions, and dial in the caps and approvals your program requires.
Review each template against the instrument's legal requirements. The template configures platform controls; selecting it does not establish regulatory compliance.
Markets in Crypto-Assets: identity verification, EU jurisdiction rules, and a rolling supply cap.
Private placement: up to 35 non-accredited sophisticated investors, no general solicitation.
Accredited-only, with general solicitation and verified accreditation status.
Crowdfunding: retail raises up to $5M a year through registered funding portals.
Regulated securities: identity verification and UK residency requirements.
Capital markets: identity verification, residency rules, and holding-period restrictions.
Crypto assets: strict identity verification and Japan residency requirements.
Digital assets: identity verification and Australian regulatory rules.
Virtual assets across the UAE regimes: identity verification and jurisdiction rules.
Scope each rule, or set one for the whole system
A compliance policy is rarely one blunt setting. In 3.0, each module can be scoped to the cases it governs: specific countries by ISO country code, specific identity claims, or both. The same module type applies with different reach across programs. A jurisdiction block can target one set of countries while an accreditation check keys off a different claim, all inside one policy.
Rules can also live above any single instrument. Global compliance rules sit at the system level and apply to every token bound to the system. Configure the rule once and the chain enforces it everywhere, instead of reconfiguring the same constraint on each asset. Program-wide policy and per-instrument policy compose, so a control you want everywhere is set once, and a control you want for one asset stays local to it.
A rejection tells you why
When the chain blocks a mint or transfer, DALP 3.0 returns the specific cause rather than a generic failure message. The platform classifies the rejection: holder not registered, required claim missing or expired, or a specific module blocking the operation. Exact claim topics are named. The operator can use that cause to identify the required remediation. An integration branches on the typed reason to drive the right remediation.
Reading the active policy through the API
Once a template is applied to an asset, integration teams can read the deployed controls without touching on-chain state directly. The Platform API exposes the full template (modules, jurisdictions, required controls, draft or published status, and module-set version) through a single endpoint.
GET /api/v2/settings/compliance-templates/{id}The same surface is reachable through the CLI and the MCP tool, so the active policy is queryable by any integration that needs to act on the result. Read the template and deployed policy to confirm which controls apply.
Compatibility
Compliance templates are new capability. They change no existing API behavior and deprecate nothing: an asset already deployed under a hand-configured policy keeps enforcing that policy unchanged, and applying a template stays a choice, not a requirement.
Asset templates
Turn a proven asset setup into a reusable template, so the next instrument starts from a standard instead of a blank form.
Custody & signing
Sign through your own custody provider while DALP prepares, broadcasts, and tracks every transaction to confirmation, with keys that never leave the vault.