Write your compliance policy once

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 tokenization 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.

Every tokenization program stalls on the same questions: who is allowed to hold this, in which jurisdictions, up to what supply, behind which approvals, against what collateral. A template settles those answers once. You name the trusted issuers whose claims you accept and the identity topics they must cover: KYC, AML, accreditation, suitability, or a custom eligibility claim. You allow or block investor jurisdictions, cap supply and investor count, and require collateral evidence when it matters.

The standard approach to compliance in a tokenization program is procedural. A human runs a checklist before a transfer. A document records the policy. Enforcement depends on every reviewer following the same steps every time. That model breaks under volume and breaks silently: a transfer clears that shouldn't have, or a policy update doesn't reach every active asset.

How it works

Each template is a versioned collection of compliance modules: individual rule primitives that control eligibility, geography, supply, and approval. 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

The on-chain compliance and identity model behind DALP is not a proprietary invention. DALP implements ERC-3643, the open Ethereum standard for permissioned tokens and regulated security tokens, built on OpenZeppelin's battle-tested contract libraries. That choice has precise consequences for every institution running on DALP.

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, 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

ERC-3643 is an open, ratified Ethereum standard, not a vendor format. Any custody provider, exchange, or integration that understands ERC-3643 understands DALP tokens without bespoke adapters. External auditors can evaluate the compliance architecture against the published specification. The regulated security token standard is public, implemented by DALP on OpenZeppelin primitives, and readable by anyone. For institutions building on infrastructure that needs to outlast any single vendor, that matters.

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:

Frameworks for nine jurisdictions, or your own

We ship nine built-in templates, each encoding a real regulatory regime's identity, residency, and supply rules. 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.

Getting the framework right before an asset launches matters more than it might seem. MiCA's rolling supply caps, Reg D 506(b)'s 35-investor ceiling, and Reg CF's annual raise limit each carry legal consequences if breached. Breaches in on-chain programs happen instantly, not gradually. A built-in template encodes those thresholds in the module configuration: not as a number someone types from memory, but as a constraint that fires at the chain level on every mint and transfer.

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 resolves the issue in one step. 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 active 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. Policy defined once by the people qualified to define it. Enforced automatically at the chain level. Inspectable by any integration that needs to act on the result.

Apply compliance templates → · Compliance templates API →