# SMART Protocol integration (ERC-3643) Source: https://docs.settlemint.com/docs/architecture/components/asset-contracts/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, and the token updates state only after those checks pass. For the ERC-3643 concept map, see [ERC-3643 compliance standard](/docs/architecture/components/asset-contracts/erc-3643-compliance-standard). Identity, claim topics, and trusted issuers are defined in the [claims and identity model](/docs/architecture/concepts/claims-and-identity). ## What is SMART protocol? [#what-is-smart-protocol] **SMART** (SettleMint Adaptable Regulated Token) Protocol is an ERC-3643 implementation that DALP uses as its on-chain compliance foundation. ERC-3643 defines a specification for security tokens where transfers are only permitted when a compliance engine, consisting of one or more modular rules, approves them. SMART provides three layers that DALP builds on: | 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 | DALP extends these layers with access control, proxy architecture, infrastructure integration, runtime token features, and system-seeded compliance templates. *** ## Enforcement context [#enforcement-context] The asset token is the enforcement point. For each supported lifecycle action, the token resolves identity context, calls the compliance engine, runs configured feature hooks, and then updates token state. *** ## DALP implementation model [#dalp-implementation-model] DALP uses ERC-3643 as the enforcement model for regulated asset movement: the token contract owns balances and transfer execution, while the identity registry, compliance engine, and token-feature hooks all participate in deciding 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 operator-visible parts: 1. **Token contract** - one asset contract represents one instrument or asset class, with its own supply, holders, roles, and lifecycle settings. 2. **Identity registry** - the asset resolves recipient wallet addresses to OnchainID identities before regulated transfer-path operations. 3. **Trusted issuers and claim topics** - approved claim issuers define which identity attestations count for the asset's compliance policy. 4. **Compliance engine** - the asset calls the compliance engine during the transfer path, and the engine evaluates the configured rule set. 5. **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 OnchainID lookup for the `to` address. The default identity verification path is recipient-side only. Sender-side constraints on the `from` address apply only when an additional compliance module explicitly enforces them. Burns and redemptions use lifecycle-specific hooks. Burns destroy token balances and notify compliance 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. They are explicit administrative actions, not the normal investor transfer path. *** ## What DALP adds to SMART [#what-dalp-adds-to-smart] | 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](/docs/architecture/components/asset-contracts/deployment-architecture) | | **Compliance rules** | System-seeded templates and module configuration per asset | Rule evaluation engine and module interface | [Compliance Modules](/docs/architecture/security/compliance) | | **Identity verification** | Claim issuance workflow and trusted issuer management | Identity registry and OnchainID claim storage | [Identity & Compliance](/docs/architecture/security/identity-compliance) | | **Token features** | Runtime-pluggable features such as fees, yield, governance | Extension hook points through `SMARTConfigurable` | [Token Features](/docs/architecture/components/token-features) | | **Access control** | Asset roles and multi-tenant authority model | Role-checking hooks | [RBAC](/docs/architecture/components/asset-contracts/rbac) | | **Transfer enforcement** | Policy design: which modules run with which parameters | On-chain enforcement that reverts non-compliant operations | [Compliance Transfer Flow](/docs/architecture/flows/compliance-transfer) | | **Multi-asset organization** | Instrument profiles and shared identity infrastructure | Separate contract per instrument | [Legacy Types](/docs/architecture/components/asset-contracts/legacy-types) | *** ## Organizing multiple assets [#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 configuration 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 **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 a modular compliance engine, OnchainID integration, and a maintained implementation pattern for permissioned asset movement. *** ## DALP's recommended approach [#dalps-recommended-approach] **DALPAsset** is the recommended contract type for all new deployments. The contract extends SMART Protocol with `SMARTConfigurable`. Operators with the right asset roles can attach supported [token features](/docs/architecture/components/token-features) at runtime after deployment. * [DALPAsset](/docs/architecture/components/asset-contracts/dalp-asset): full architecture and configuration model * [Legacy Types](/docs/architecture/components/asset-contracts/legacy-types): compile-time types and when they still apply * [Legacy-Equivalent Presets](/docs/architecture/components/asset-contracts/instrument-profiles): pre-built configurations per instrument type *** ## Where to read next [#where-to-read-next] * **How ERC-3643 concepts map to DALP**: [ERC-3643 compliance standard](/docs/architecture/components/asset-contracts/erc-3643-compliance-standard) * **How identity enforcement works**: [Identity & Compliance](/docs/architecture/security/identity-compliance) * **What each compliance rule does**: [Compliance Modules](/docs/architecture/security/compliance) * **Transfer enforcement step by step**: [Compliance Transfer Flow](/docs/architecture/flows/compliance-transfer)