# ERC-3643 compliance standard Source: https://docs.settlemint.com/docs/architecture/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 token-standard behaviour from the platform, custody, identity, and legal controls that sit around 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 and 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. It is 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 keep the ERC-20 balance, allowance, transfer, and metadata surface so wallets, custodians, explorers, and indexers can recognize the asset as a token balance. That compatibility does not make the asset an unrestricted bearer token. DALP uses ERC-3643 and SMART Protocol controls around the ERC-20 surface so configured identity, compliance, feature, and role checks 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 actions 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 separately | | 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 an operator or auditor, the practical test is simple: ERC-20 compatibility tells you how the token is recognized and called; ERC-3643/SMART controls tell you who is allowed to complete a regulated state change. Review both before approving integrations, custody runbooks, or secondary-market workflows. ## How DALP applies ERC-3643 [#how-dalp-applies-erc-3643] 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. Burns and forced servicing operations have separate rules described 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/architecture/components/asset-contracts/smart-protocol-integration) and [DALPAsset](/docs/architecture/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/architecture/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/user-guides/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/architecture/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/architecture/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/architecture/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 for the token, sender, recipient, and 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 actions and bypass ordinary transfer compliance by design. Treat both 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, operators should 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. The platform records the external contract address and assigned token type. It detects SMART interfaces declared by the contract. It also indexes available ERC-20 metadata. Registration does not certify the issuer's contract or copy external compliance rules. Registration does not guarantee that a proxy target is safe. Registration also does not 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/developer-guides/api-integration/external-tokens). For the dApp workflow, see [Register external tokens](/docs/user-guides/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. It is 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] * One issued asset has its own token contract, compliance configuration, roles, holders, supply, and lifecycle state. * Shared identity infrastructure can support multiple assets, but each asset decides which claim topics, trusted issuers, and modules apply. * A wallet can be registered and still fail a token operation when the asset requires a claim the wallet does not have, uses an untrusted issuer for that claim, violates a country rule, exceeds a supply or investor-count limit, or is subject to 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. ## Related pages [#related-pages] * [SMART Protocol integration](/docs/architecture/components/asset-contracts/smart-protocol-integration) for the DALP implementation model. * [Identity and compliance](/docs/architecture/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/architecture/security/compliance) for the module catalog. * [Compliance transfer flow](/docs/architecture/flows/compliance-transfer) for the validation sequence. * [External tokens](/docs/developer-guides/api-integration/external-tokens) for external-token address preflight, registration, and API fields.