SettleMint
ArchitectureComponentsAsset Contracts

DALPAsset

Reference for the configurable DALP asset contract: factory inputs, always-included controls, feature ordering, role gates, and operating boundaries.

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

AreaDALPAsset behaviour
Token coreExposes ERC-20 behaviour through SMART Protocol identity and compliance checks.
ConfigurationThe 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 controlsCustodian controls, pause controls, burn controls, metadata, configurable feature management, and treasury payer support are part of the DALPAsset interface.
Feature orderingGovernance 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 gatesGovernance 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 modelDALPAsset can run behind the factory/proxy deployment architecture. See deployment architecture.

Composition model

Rendering diagram...

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

DALPAssetConfig defines the initial asset shape:

FieldWhat it controls
name and symbolERC-20 display values. Governance can update them after deployment.
decimalsToken precision set during initialization.
assetTypeNameHuman-readable asset type name, such as bond, equity, fund, or deposit. DALP hashes it to the token's assetTypeId.
countryCodeISO 3166-1 numeric jurisdiction code emitted when the asset is created.
complianceModulesInitial compliance module configuration for the per-token compliance contract.
featuresFeature type names and encoded configuration data to attach during creation.
initialMetadataInitial 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

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 for feature-specific behaviour.

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 for the wallet, OnchainID, and claim boundary.

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

RoleDALPAsset operations
GOVERNANCE_ROLESet token OnchainID, name, symbol, identity registry, compliance contract, metadata, and ordered feature list.
SUPPLY_MANAGEMENT_ROLEMint, batch mint, burn, and batch burn.
CUSTODIAN_ROLEFreeze addresses, freeze partial balances, unfreeze balances, force transfers, batch forced transfers, and recover tokens from a lost wallet to a new wallet.
EMERGENCY_ROLEPause 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

  • 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

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 for legacy-equivalent DALPAsset configurations and legacy types for the older contract families.

See also

On this page