SMART Protocol integration
How DALP uses SMART Protocol (ERC-3643) for identity-aware asset tokens, per-asset compliance checks, and regulated transfer enforcement.
SMART Protocol is the regulated token layer underneath DALP asset contracts. Each asset uses an ERC-3643 transfer model. The identity registry checks the recipient wallet. The compliance engine evaluates configured modules. Feature hooks run when attached. The token updates state only after all those checks pass.
The ERC-3643 compliance standard page maps each protocol concept to its DALP equivalent. Identity, claim topics, and trusted issuers are defined in the claims and identity model.
What is SMART protocol?
SMART (SettleMint Adaptable Regulated Token) Protocol implements ERC-3643, which DALP uses as its on-chain compliance layer. ERC-3643 specifies security tokens where transfers are permitted only when a compliance engine, consisting of one or more modular rules, approves them. SMART provides three layers that DALP builds on. Each layer is extended with access control, proxy architecture, infrastructure integration, runtime token features, and system-seeded compliance templates when you deploy an asset.
| Layer | What it provides |
|---|---|
| Token | ERC-20 compatible contracts with compliance hooks and modular extensions |
| Compliance | Orchestration engine that evaluates configurable rule sets before each transfer |
| Identity | On-chain identity management via OnchainID (ERC-734/735), storing KYC/AML claims |
Enforcement context
The diagram below shows how the asset token connects to each enforcement layer. Each arrow represents a call the token makes during a transfer or mint.
The asset token is the enforcement point. For each supported lifecycle operation, the token resolves identity context, calls the compliance engine, runs configured feature hooks, and then updates token state. Any gate in that chain can revert before token state changes.
DALP implementation model
DALP uses ERC-3643 as the enforcement model for regulated asset movement. The token contract owns balances and executes transfers. The identity registry, compliance engine, and token-feature hooks all decide whether standard mints and transfers may proceed before token state changes. Any of those gates can revert with its own error instead of creating a partial lifecycle state.
The model has five parts you work with as an operator:
- Token contract: one asset contract represents one instrument or asset class, with its own supply, holders, roles, and lifecycle settings.
- Identity registry: the asset resolves recipient wallet addresses to OnchainID identities before regulated transfer-path operations.
- Trusted issuers and claim topics: approved claim issuers define which identity attestations count for the asset's compliance policy.
- Compliance engine: the asset calls the compliance engine during the transfer path, and the engine evaluates the configured rule set.
- Compliance modules and feature hooks: reusable rule contracts, such as identity, country, supply, investor-count, time-lock, and approval rules, are configured per asset; runtime token features may add their own validation hooks.
Standard transfers and mints follow three gates: recipient-side identity resolution, compliance engine evaluation, and feature canUpdate hooks. The identity gate includes an OnchainID lookup for the to address.
The default identity check is recipient-side only. Sender-side constraints on the from address apply only when you add a compliance module that explicitly enforces them.
Burns and redemptions use lifecycle-specific hooks. Burns destroy token balances and notify the compliance engine after the supply change. Bond redemption checks maturity, amount, and denomination-asset funding before burning the redeemed balance and paying the holder.
Forced transfers are separate custodian operations. The platform executes them as explicit administrative steps, not through the normal investor transfer path.
What DALP adds to SMART protocol
| Concern | DALP adds | SMART provides | Where to read next |
|---|---|---|---|
| Token lifecycle | Factory deployment, proxy upgrades, role assignment | ERC-20 token logic and compliance hook calls | Deployment Architecture |
| Compliance rules | System-seeded templates and module configuration per asset | Rule evaluation engine and module interface | Compliance Modules |
| Identity verification | Claim issuance workflow and trusted issuer management | Identity registry and OnchainID claim storage | Identity & Compliance |
| Token features | Runtime-pluggable features such as fees, yield, governance | Extension hook points through SMARTConfigurable | Token Features |
| Access control | Asset roles and multi-tenant authority model | Role-checking hooks | RBAC |
| Transfer enforcement | Policy design: which modules run with which parameters | On-chain enforcement that reverts non-compliant operations | Compliance Transfer Flow |
| Multi-asset organization | Instrument profiles and shared identity infrastructure | Separate contract per instrument | Legacy Types |
Organizing multiple assets
ERC-3643 uses a separate-contract-per-instrument model. Each financial instrument, such as a bond tranche, equity share class, or fund unit, is deployed as its own token contract with independent compliance settings and lifecycle.
This provides:
- Lifecycle isolation: one bond can mature while related equity continues trading.
- Compliance independence: each instrument has its own module configuration and investor restrictions.
- Upgrade independence: one instrument can be upgraded without changing another.
- Clear accounting: each token has its own
totalSupply, holder list, and transaction history.
Related assets are linked through on-chain references, when behavior depends on another asset, or through identity claims, when assets share an issuer or program for reporting.
DALP uses ERC-3643 rather than ERC-1400 because ERC-3643 gives each token you deploy a modular compliance engine, built-in OnchainID integration, and a maintained pattern for permissioned asset movement.
DALP's recommended approach
DALPAsset is the recommended contract type for all new deployments. It extends SMART Protocol with SMARTConfigurable. When you hold the right asset roles, you can attach supported token features at runtime after deployment.
- DALPAsset: full architecture and configuration model
- Legacy Types: compile-time types and when they still apply
- Legacy-Equivalent Presets: pre-built configurations per instrument type
Where to read next
- ERC-3643 compliance standard: how ERC-3643 concepts map to DALP
- Identity & Compliance: how identity enforcement works
- Compliance Modules: what each compliance rule does
- Compliance Transfer Flow: transfer enforcement step by step
- SMART Protocol architecture moved: keeps bookmarked overview links connected to this canonical page
Asset Contracts
DALPAsset is the recommended configurable contract type for new tokenization projects, with legacy specialized types remaining supported for existing deployments.
ERC-3643 compliance standard
How ERC-3643 maps to DALP's SMART Protocol token model, including the Solidity and Hardhat contract stack, supported ERC standards, permissioned token controls, identity registries, trusted issuers, claim topics, compliance modules, and EVM-only transfer enforcement.