# Asset Contracts Source: https://docs.settlemint.com/docs/architects/components/asset-contracts DALPAsset is the recommended configurable contract type for new tokenization projects, with legacy specialized types remaining supported for existing deployments. You define identity, claim topics, and trusted issuers in the [claims and identity model](/docs/architecture/concepts/claims-and-identity). > Availability: DALPAsset is experimental and feature-gated. Enable the DALPAsset factory, the required token features, and their dependencies before you evaluate it. Do not treat enabled flags alone as production approval. ## DALPAsset: recommended for all new projects [#dalpasset-recommended-for-all-new-projects] DALPAsset is the configurable asset contract for new tokenization projects. You deploy one ERC-3643 token implementation and choose the instrument-specific policy at creation time: asset type, jurisdiction, compliance modules, token features, and initial metadata. Start here when designing an asset issuance flow or reviewing tokenized-instrument compliance responsibilities. ## What this section covers [#what-this-section-covers] This overview is for integrating developers and architects who need to understand what the asset contract owns before reading the full reference, and for auditors and compliance reviewers who need to map the contract surface. Use it to choose between DALPAsset and a legacy specialized type. The issuing organization owns the instrument policy, configuration choices, role assignments, and operational evidence. The factory deploys the contract from that submitted configuration. Each role holder owns the operations granted to that role: supply changes, custody operations, emergency controls, sale administration, or funds management. The section covers the on-chain token contract, per-asset policy, and governed roles. Use DALPAsset when the instrument needs runtime-configurable behavior. Choose a legacy specialized type only when the legal or compliance model requires the feature set fixed in the contract bytecode at deployment. Custody provider policy, issuer legal obligations, off-chain investor onboarding, market operations, bridge behavior, and non-EVM settlement are all outside the asset contract. Read the schematic below first, then continue to [DALPAsset](/docs/architects/components/asset-contracts/dalp-asset) for the full architecture: how configuration works, change impact, and relationship to legacy types. *** ## Asset contract model [#asset-contract-model] The schematic is the audit map for the asset-contract section. It separates policy input, deployed artifacts, governed roles, holder operations, and event evidence. The token contract is not one black box. The factory creates the token, its identity contract, and the per-asset access manager from a single submitted configuration. The Governance role handles later configuration changes; Supply Management handles minting and burning; the Custodian role controls freezes, forced transfers, and recovery. The Emergency role controls pause and recovery. Sale Admin and Funds Manager roles apply only when a token sale addon is attached. | Question | Answer | Detail page | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What does this section cover? | ERC-3643 asset tokens, DALPAsset configuration, legacy-equivalent presets, per-asset roles, and factory deployment. | [ERC-3643 compliance standard](/docs/architects/components/asset-contracts/erc-3643-compliance-standard) and [DALPAsset](/docs/architects/components/asset-contracts/dalp-asset) | | Who is it for? | Integrating developers, solution architects, auditors, and compliance reviewers who need to understand what the asset contract owns before reading implementation detail. | [Deployment Architecture](/docs/architects/components/asset-contracts/deployment-architecture) | | What runs and changes? | Compliance modules and token features run around mint, burn, transfer, redeem, update, and attach operations. Governed roles can change modules, features, metadata, and identity settings when the contract permits it. | [Token Features](/docs/architects/components/token-features) | | Who owns what? | The factory deploys the contract from the submitted configuration. The issuing organization owns the instrument policy, configuration choices, role assignments, policy approvals, and operational evidence. Each role holder owns the operations granted to that role. | [RBAC](/docs/architects/components/asset-contracts/rbac) | | What is out of scope? | This section does not define legal instrument terms, custody provider approval policy, investor onboarding, exchange operations, bridge behavior, or non-EVM settlement. | [Claims and identity](/docs/architecture/concepts/claims-and-identity) | | Which page is next? | Read DALPAsset for the configurable contract, Legacy-Equivalent Presets for instrument profiles, Legacy Types for fixed-bytecode contracts, or RBAC for ownership and control boundaries. | [Legacy-Equivalent Presets](/docs/architects/components/asset-contracts/instrument-profiles) | *** ## Smallest deployable shape [#smallest-deployable-shape] Create a DALPAsset through the asset factory with a `DALPAssetConfig`. The factory validates the configuration, creates a per-asset access manager, and deploys the asset proxy. It then attaches compliance modules and any requested token features, and emits `DALPAssetCreated` with the token address and OnchainID address. ```solidity IDALPAssetFactory.DALPAssetConfig memory config = IDALPAssetFactory.DALPAssetConfig({ name: "Example Bond 2029", symbol: "EB29", decimals: 18, assetTypeName: "Bond", countryCode: 56, complianceModules: complianceModules, features: features, initialMetadata: initialMetadata }); (address tokenAddress, address onchainIdAddress) = dalpAssetFactory.create(config); ``` `assetTypeName` is part of the deterministic salt for both the token and access manager addresses. If you need to predict the access-manager address before deployment, use the asset-type-specific predictor rather than the generic token-factory predictor. *** ## Production requirements [#production-requirements] Before you issue a DALPAsset in production, make these decisions explicit: * DALPAsset is experimental and feature-gated. Enable DALPAsset, the requested token features, and required directory dependencies before testing. Confirm the target deployment policy before live issuance. * Define trusted issuers, claim topics, jurisdiction rules, and compliance modules before minting or transferring tokens. * Set `assetTypeName` and the ISO 3166-1 numeric `countryCode` at creation time so deployment addresses and policy records match the intended instrument. * Separate governance, supply management, custodian, emergency, sale administration, and funds-management duties. Do not assign every role to one operational signer. * Attach only features the instrument needs, and record who can change each feature after deployment. * Keep the deployed token address, OnchainID address, access-manager address, compliance-module set, feature set, and role assignments with the instrument file. *** ## Legacy-equivalent presets at a glance [#legacy-equivalent-presets-at-a-glance] | Preset | Token features to attach | Compliance modules | | ------------- | -------------------------------------------------------------- | ------------------ | | Bond | Fixed Treasury Yield, Maturity Redemption, Historical Balances | Capped | | Equity | Voting Power, Historical Balances | Per jurisdiction | | Fund | AUM Fee, Voting Power, Historical Balances | Per jurisdiction | | StableCoin | Historical Balances | Collateral | | Deposit | Historical Balances | Per jurisdiction | | RealEstate | Historical Balances | Capped | | PreciousMetal | Historical Balances | Per jurisdiction | See [Legacy-Equivalent Presets](/docs/architects/components/asset-contracts/instrument-profiles) for the full configuration spec, including token features, compliance modules, and legacy equivalents per instrument. *** ![Asset contract details showing on-chain parameters](/docs/screenshots/bonds/bonds-detail-1.webp) ## When to choose [#when-to-choose] Use DALPAsset for runtime flexibility. You can attach and reconfigure token features after deployment when the contract and governance policy permit it. DALPAsset is the recommended choice for new projects. See [DALPAsset](/docs/architects/components/asset-contracts/dalp-asset) for details and [Legacy-Equivalent Presets](/docs/architects/components/asset-contracts/instrument-profiles) for configuration guidance. Use a legacy specialized type for compile-time immutability. Features embedded at deployment cannot change. Choose this path when compliance or legal frameworks require post-issuance immutability guarantees. See [Legacy Types](/docs/architects/components/asset-contracts/legacy-types) for the full decision checklist. *** ## Common foundation [#common-foundation] Every asset type shares the same SMART Protocol foundation, whether you deploy DALPAsset or a specialized contract. ERC-3643 compliance enforces transfers on-chain via compliance modules. ERC-20 compatibility gives standard wallet, DEX, and tooling support. OnchainID connects the identity registry for KYC/AML claims. ERC-2771 meta-transactions enable gasless operations via trusted forwarders, and ERC-165 introspection lets external systems query supported capabilities. Unified RBAC provides seven per-asset roles with separation of duties. See [RBAC](/docs/architects/components/asset-contracts/rbac) for the role identifiers and duties. *** ## Further reading [#further-reading] * [DALPAsset](/docs/architects/components/asset-contracts/dalp-asset): the recommended configurable contract type * [Legacy-Equivalent Presets](/docs/architects/components/asset-contracts/instrument-profiles): pre-built configurations per instrument type * [Legacy Types](/docs/architects/components/asset-contracts/legacy-types): compile-time types, decision checklists, and coexistence guidance * [RBAC](/docs/architects/components/asset-contracts/rbac): per-asset role model and separation-of-duties invariants * [Deployment Architecture](/docs/architects/components/asset-contracts/deployment-architecture): factory pattern, invariants, and failure modes * [Token Features](/docs/architects/components/token-features): runtime-pluggable feature catalog * [Compliance Modules](/docs/compliance-security/compliance): transfer and supply rule engine