# ERC-3643 compliance standard Source: https://docs.settlemint.com/docs/architects/components/asset-contracts/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. ERC-3643 is the regulated-token standard behind DALP's SMART Protocol foundation. In DALP, an ERC-3643 token keeps ERC-20-compatible balances and transfers, then adds on-chain identity and compliance gates before ordinary regulated mints and transfers complete on an EVM network. The standards map below separates what the token standard does from the platform controls, custody policy, identity checks, and legal requirements that surround it. ## Development stack and standards scope [#development-stack-and-standards-scope] DALP asset contracts are Solidity contracts built and tested with Hardhat. The current contract workspace pins Solidity compiler `0.8.35`, Hardhat `3.4.5`, OpenZeppelin Contracts `5.6.1`, OpenZeppelin upgradeable contracts `5.6.1`, and viem `2.49.2`. Deployments use Hardhat Ignition modules and DALP's factory/proxy architecture for repeatable EVM deployments. The regulated asset model is ERC-20-compatible and based on ERC-3643 concepts through SMART Protocol contracts. DALP uses ERC-734 and ERC-735-style identity and claim primitives for OnchainID, ERC-2771 trusted forwarders for meta-transaction support, and ERC-165 interface checks where contracts need capability discovery. DALP's public token model chooses ERC-3643 over ERC-1400. It does not publish ERC-1400 partitions or ERC-1404 restriction codes as supported token-standard behaviour. | Standard or primitive | DALP use | Compliance control enabled | | --------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | ERC-20 | Balance, allowance, transfer, and metadata compatibility for issued tokens | Standard wallet and tooling interoperability around a regulated token balance | | ERC-3643 / SMART Protocol | Identity-aware regulated token operations on configured EVM networks | Ordinary transfer and mint checks through identity resolution, trusted issuers, claim topics, and compliance modules | | ERC-734 / ERC-735-style identity claims | OnchainID key and claim model | Wallet-to-identity linkage and verifier-issued eligibility claims | | ERC-2771 | Trusted forwarder support | Gasless or sponsored transaction flows when the asset and forwarder policy allow them | | ERC-165 | Interface detection | Contract and factory capability checks during deployment and integration | | ERC-1400 / ERC-1404 | Not published as a DALP-supported token standard | Do not assume partitioned-token or ERC-1404 restriction-code behaviour unless a project-specific contract extension is explicitly supplied | Dependency versions are pinned in the contract package manifest and repository lockfile. A customer or bank evidence pack can include the release-specific dependency manifest or SBOM for the delivered contract codebase. This page states the public standards scope, not a substitute for a deployment-specific software bill of materials. ## Security implications of ERC-20 compatibility [#security-implications-of-erc-20-compatibility] DALP tokens expose the standard ERC-20 surface (balances, allowances, transfer calls, and token metadata) so external tooling can recognize the asset. That compatibility does not make the asset an unrestricted bearer token. DALP wraps the ERC-20 surface with ERC-3643 and SMART Protocol controls. Identity checks, compliance rules, and role and feature gates together decide whether a regulated operation can change token state. | Surface | What external systems can expect | Control implication | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ERC-20 balance and metadata | Standard token name, symbol, decimals, balances, allowances, and transfer calls | A standard call can still revert when the asset's identity, compliance, pause, freeze, or feature rules do not allow the operation | | ERC-3643 / SMART Protocol enforcement | Identity-aware regulated token execution on configured EVM networks | Ordinary mints and transfers are permissioned by the token's identity registry, trusted issuers, claim topics, compliance modules, and feature hooks | | Administrative servicing paths | Role-gated custody and emergency operations for freeze, forced-transfer, wallet-recovery, pause, burn, and ERC-20 recovery cases | These are exceptional servicing controls, not ordinary investor transfers. Assign the custodian, emergency, supply-management, and governance roles to separate keys. | | Other token standards | ERC-1400 partitions, ERC-1404 restriction-code behaviour, and native non-EVM standards are not published as DALP's standard token surface | Do not assume those behaviours unless a deployment includes a project-specific extension | For operators and auditors: ERC-20 compatibility tells you how the token is recognized and called. ERC-3643/SMART controls tell you who may complete a regulated state change. Review both layers before approving integrations, custody runbooks, or secondary-market workflows. ## How DALP applies ERC-3643 enforcement [#how-dalp-applies-erc-3643-enforcement] DALP uses ERC-3643 as the on-chain enforcement model for ordinary regulated asset movement. Standard mints and transfers pass identity resolution, the configured compliance modules, and any token-feature hooks before token balances change. Trusted-issuer claim checks apply when the asset's identity policy or identity-verification module requires claim topics. For the per-asset view of those checks, use [asset policy](/docs/architecture/concepts/asset-policy). That page shows you how wallet identity records, module settings, lifecycle hooks, and governance roles form the rule set DALP evaluates for one token. Burns and forced servicing operations have separate rules. You can find those rules in the enforcement sequence section below. ## Standards map [#standards-map] | ERC-3643 concept | DALP implementation | What it decides | Where to read next | | ----------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Regulated token | SMART Protocol token, usually deployed as a configurable DALPAsset | Owns balances, token metadata, roles, transfer execution, and the compliance hook path for one issued asset | [SMART Protocol integration](/docs/architects/components/asset-contracts/smart-protocol-integration) and [DALPAsset](/docs/architects/components/asset-contracts/dalp-asset) | | Identity registry | Wallet-to-OnchainID registry with country and recovery state | Whether DALP can resolve the wallet to an active on-chain identity before checking claims | [Claims and identity](/docs/architecture/concepts/claims-and-identity) | | Claim topic | Numeric topic that names an eligibility fact, such as KYC, AML, accreditation, or an asset-specific rule | Which facts the token requires before a wallet can satisfy the policy | [Identity verification module](/docs/compliance-security/compliance/identity-verification) | | Trusted issuer | Issuer identity trusted for one or more claim topics | Whether a claim counts for a token's eligibility policy | [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers) | | Compliance engine | The on-chain component that asks configured modules whether an operation is allowed | Whether the operation can continue before balances or lifecycle state change | [Compliance transfer flow](/docs/architects/flows/compliance-transfer) | | Compliance module | Reusable rule contract configured per asset with module parameters | Country, supply, investor-count, time-lock, approval, identity, and other asset rules | [Compliance modules](/docs/compliance-security/compliance) | | Burns and recovery operations | Controlled servicing paths, separate from the ordinary investor transfer path | Whether a role-gated burn, recovery, or forced-transfer operation can be performed | [Identity and compliance](/docs/compliance-security/security/identity-compliance) | ## Enforcement sequence [#enforcement-sequence] The ordinary ERC-3643 transfer path is fail-closed. If one required gate cannot approve the operation, the transaction reverts and no partial token state is created. 1. The token receives a mint or transfer request from an authorized DALP path. 2. The token or compliance engine resolves the relevant wallet through the identity registry. 3. The identity registry maps the wallet to an OnchainID contract and jurisdiction data. 4. The compliance path evaluates required claim topics against trusted issuers when the asset configuration requires claim enforcement. 5. Configured compliance modules evaluate their rule parameters against the token, the sender and recipient addresses, and the transfer amount. 6. Runtime token features can add their own validation hooks when the asset configuration includes them. 7. Only after the checks pass does the token update balances and emit the resulting on-chain events. Burns and forced servicing operations are not ordinary investor transfers. Burns are role-gated supply operations that update module accounting through the post-burn compliance hook. Forced transfers are explicit administrative servicing steps that bypass ordinary transfer compliance by design. When you model these in your runbooks, treat them as controlled operations with their own role and audit requirements, not as standard transfer checks. ## Contract-address validation and unsafe external-token registration [#contract-address-validation-and-unsafe-external-token-registration] DALP treats token addresses as EVM contract addresses, not as proof of an asset class. For assets issued through DALP factories, the system uses its own factory and registry state as the source of truth. For externally deployed tokens, inspect the address before registration. Register only an address that has deployed bytecode on the active network, is not already recorded in the external token registry, and is not a DALP system-managed contract or factory-deployed token. When in doubt, verify the address on a block explorer before you register it. The platform records the external contract address and assigned token type, detects SMART interfaces declared by the contract, and indexes available ERC-20 metadata. When that data is available, the external token list can show the contract address, symbol, type, decimals, supply, status, detected compatibility, registration time, and links to the detail page, event log, and block explorer. Registration does not certify the issuer's contract or copy external compliance rules. Historical balances, issuer records, reserve evidence, custodian attestations, off-platform holder history, and holder onboarding controls stay outside the registration. Registration also does not guarantee proxy-target safety or make non-standard token hooks and event emissions behave like a DALP-issued asset. Treat external-token onboarding as a registry and monitoring workflow for an existing EVM contract. Review the source contract, issuer controls, and deployment evidence separately when your operating model requires that review. For API-level preflight fields and registration errors, see [External tokens](/docs/api-reference/external-tokens/external-tokens). For the Console workflow, see [Register external tokens](/docs/operators/asset-servicing/register-external-token). ## What ERC-3643 does not decide [#what-erc-3643-does-not-decide] ERC-3643 is the token and compliance standard, not the whole operating model. | Area | What DALP handles outside the standard | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication and API access | Sessions, API credentials, SSO, passkeys, authorization checks, and wallet-verification challenges run before execution reaches the token path. | | Off-chain verification work | KYC, KYB, AML, sanctions, and accreditation review evidence stays with the verifier and operator workflow. The chain records the resulting identity links and claims needed for enforcement. | | Custody approval | MPC, signer, HSM, and custody-provider policy decide whether a prepared transaction can be signed after platform and compliance checks pass. | | Non-EVM networks | DALP's ERC-3643 enforcement applies to configured EVM networks. Native non-EVM asset standards are outside this token model. | | Legal suitability | ERC-3643 provides programmable compliance controls. The customer and their advisers still define the legal policy, issuer responsibilities, and jurisdiction-specific requirements. | ## Design implications [#design-implications] * Each issued asset has its own token contract, compliance configuration, dedicated roles and supply, holder set, and lifecycle state. * Shared identity infrastructure can support multiple assets, but each asset decides which claim topics, trusted issuers, and modules apply. * A registered wallet can still fail a token operation. The asset may require a claim the wallet lacks, an untrusted issuer for that claim, or reject the wallet for a country rule, a supply or investor-count limit, or a time-lock or transfer-approval rule. * Sender-side checks depend on the configured module. The default identity verification path focuses on the recipient address; additional modules can enforce sender constraints when the asset requires them. * Recovery and forced-transfer paths are administrative servicing operations. Do not model them as ordinary investor transfers. Treat them as controlled operations with their own audit requirements, and assign your custodian role to a separate key from your governance and supply roles. ## Related pages [#related-pages] * [SMART Protocol integration](/docs/architects/components/asset-contracts/smart-protocol-integration) for the DALP implementation model. * [Identity and compliance](/docs/compliance-security/security/identity-compliance) for the two-layer identity and policy model. * [Claims and identity](/docs/architecture/concepts/claims-and-identity) for wallet registration, OnchainID, claim topics, and trusted issuers. * [Compliance modules](/docs/compliance-security/compliance) for the module catalog. * [Compliance transfer flow](/docs/architects/flows/compliance-transfer) for the validation sequence. * [External tokens](/docs/api-reference/external-tokens/external-tokens) for external-token address preflight checks, the registration API, and error fields.