# DALPAsset Source: https://docs.settlemint.com/docs/architecture/components/asset-contracts/dalp-asset Reference for the configurable DALP asset contract: factory inputs, always-included controls, feature ordering, role gates, and operating boundaries. ## What DALPAsset is [#what-dalpasset-is] DALPAsset is the configurable asset contract for new DALP instruments. One deployed token represents one instrument scope. The scope has its own name, symbol, decimals, asset type, jurisdiction code, metadata, identity registry, compliance contract, access manager, and ordered feature list. ## At a glance [#at-a-glance] | Area | DALPAsset behaviour | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Token core | Exposes ERC-20 behaviour through SMART Protocol identity and compliance checks. | | Configuration | The factory creates the token from `DALPAssetConfig`, including the asset type name, ISO 3166-1 numeric country code, initial metadata, compliance modules, and feature configuration. | | Always-included controls | Custodian controls, pause controls, burn controls, metadata, configurable feature management, and treasury payer support are part of the DALPAsset interface. | | Feature ordering | Governance can replace the ordered feature list with `setFeatures(address[] orderedFeatures)`. Feature order is part of the asset policy because hooks can change mint, burn, transfer, redeem, update, and attach behaviour. | | Role gates | Governance manages token identity, metadata, compliance address, and feature list. Supply Management mints and burns. Custodian manages freezes, forced transfers, and wallet recovery. Emergency pauses the token and recovers ERC-20 tokens sent to the contract. | | Deployment model | DALPAsset can run behind the factory/proxy deployment architecture. See [deployment architecture](/docs/architecture/components/asset-contracts/deployment-architecture). | ## Composition model [#composition-model] The factory creates the asset proxy, token identity, access manager, and per-token compliance engine from `DALPAssetConfig`. The token always includes SMART core behaviour, metadata, configurable feature management, and separate custodian, pause, and burn controls. The access manager keeps policy changes, supply operations, custody actions, and emergency actions on separate roles. ## Factory configuration [#factory-configuration] `DALPAssetConfig` defines the initial asset shape: | Field | What it controls | | ------------------- | -------------------------------------------------------------------------------------------------------------------- | | `name` and `symbol` | ERC-20 display values. Governance can update them after deployment. | | `decimals` | Token precision set during initialization. | | `assetTypeName` | Human-readable asset type name, such as bond, equity, fund, or deposit. DALP hashes it to the token's `assetTypeId`. | | `countryCode` | ISO 3166-1 numeric jurisdiction code emitted when the asset is created. | | `complianceModules` | Initial compliance module configuration for the per-token compliance contract. | | `features` | Feature type names and encoded configuration data to attach during creation. | | `initialMetadata` | Initial metadata entries stored on the token. | The factory emits the token address, token OnchainID address, asset type name, and country code when it creates the asset. ## Runtime controls [#runtime-controls] ### Token features [#token-features] * DALPAsset stores an ordered feature list through `SMARTConfigurable`. * `setFeatures(address[] orderedFeatures)` replaces the complete ordered list and requires `GOVERNANCE_ROLE`. * The contract routes mint, burn, transfer, redeem, update, and attach hooks through the configured feature order. * The caller is responsible for feature order. Misordering can change fee, approval, transfer-rewrite, or analytics semantics. See the [token features catalog](/docs/architecture/components/token-features) for feature-specific behaviour. ### Compliance and identity [#compliance-and-identity] DALPAsset initializes with an identity registry and a compliance contract. Governance can update the identity registry with `setIdentityRegistry(address)` and update the compliance contract with `setCompliance(address)`. Transfers go through SMART Protocol transfer logic, which checks identity and compliance before token state changes. Use [identity and compliance architecture](/docs/architecture/security/identity-compliance) for the wallet, OnchainID, and claim boundary. ### Metadata [#metadata] Governance can set metadata entries with `setMetadata(...)` and remove entries with `removeMetadata(string key)`. Metadata describes the token and its asset context. Metadata does not by itself prove off-chain custody, reserve backing, legal title, or regulatory status. ## Role boundaries [#role-boundaries] | Role | DALPAsset operations | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GOVERNANCE_ROLE` | Set token OnchainID, name, symbol, identity registry, compliance contract, metadata, and ordered feature list. | | `SUPPLY_MANAGEMENT_ROLE` | Mint, batch mint, burn, and batch burn. | | `CUSTODIAN_ROLE` | Freeze addresses, freeze partial balances, unfreeze balances, force transfers, batch forced transfers, and recover tokens from a lost wallet to a new wallet. | | `EMERGENCY_ROLE` | Pause transfers, unpause transfers, and recover ERC-20 tokens sent to the asset contract. | The roles are scoped to the asset contract's access manager. A role on one asset does not automatically grant the same authority on another asset. ## Operating boundaries [#operating-boundaries] * A DALPAsset is an EVM token contract. It does not make DALP native to non-EVM networks. * Feature and compliance configuration must use registered, supported contracts. An arbitrary feature is not safe just because governance can place it in the ordered feature list. * Metadata and collateral claims are attestations inside the token workflow. They do not independently verify off-chain reserves, custody documents, insurance, or legal ownership. * Governance changes affect subsequent behaviour. Existing balances remain token balances; whether an operation succeeds later depends on the active role, identity, compliance, pause, custody, and feature checks at that time. * Production deployments should separate governance, supply, custody, and emergency authority according to the operator's control model. ## Relationship to legacy types [#relationship-to-legacy-types] Legacy specialized contracts such as DALPBond, DALPEquity, DALPFund, DALPStableCoin, DALPDeposit, DALPRealEstate, and DALPPreciousMetal predate the configurable DALPAsset model. Those legacy types remain documented for existing deployments and fixed contract shapes. DALPAsset is the flexible path for new instruments that need composable features and per-asset policy configuration. See [instrument profiles](/docs/architecture/components/asset-contracts/instrument-profiles) for legacy-equivalent DALPAsset configurations and [legacy types](/docs/architecture/components/asset-contracts/legacy-types) for the older contract families. ## See also [#see-also] * [Asset contracts overview](/docs/architecture/components/asset-contracts) for the full asset-contract catalogue. * [Token features](/docs/architecture/components/token-features) for runtime feature behaviour and ordering. * [Compliance modules](/docs/architecture/security/compliance) for transfer and supply-rule enforcement. * [RBAC](/docs/architecture/components/asset-contracts/rbac) for per-asset role separation. * [Deployment architecture](/docs/architecture/components/asset-contracts/deployment-architecture) for the factory and proxy model.