DALPAsset: configurable asset contract reference

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. Each deployed token represents one instrument scope with its own name, symbol, decimals, asset type, jurisdiction code, metadata, identity registry, compliance contract, access manager, and ordered feature list.

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.

Composition model

Rendering diagram...

The factory creates the asset proxy, token identity, access manager, and per-token compliance engine from DALPAssetConfig. Every deployed token includes SMART core behaviour together with metadata and configurable feature management. Custodian controls, pause controls, and burn controls each ship as separate extensions. The access manager places each authority on a distinct role, keeping policy changes, supply operations, custodian tasks, and emergency operations separate. This separation means a governance key change does not affect custody or supply authority, and an emergency action does not require governance credentials.

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

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 hooks through the configured feature order. Hook types span the full token lifecycle: mint, burn, transfer, redeem, update, and attach.
You are responsible for feature order. Misordering can change fee, approval, transfer-rewrite, or analytics semantics.

See the token features catalog for feature-specific behaviour when you need to select or configure features.

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.

See Claims and identity for the wallet-to-OnchainID model, claim topics, trusted issuers, and claim-expression checks. See identity and compliance architecture for the broader compliance flow around that model.

Metadata

Governance can set metadata entries with setMetadata(...) and remove entries with removeMetadata(string key).

Token metadata describes the instrument context. It does not by itself prove off-chain custody, reserve backing, legal title, or regulatory status. If your compliance or legal process requires those proofs, verify them through separate evidence outside the token's state.

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.

Roles are scoped to each contract's access manager. A role you assign on one asset does not automatically grant the same authority on another.

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 verify nothing outside the token's own state. Off-chain reserves, custody documents, and insurance all require separate evidence; so does legal ownership.
Governance changes affect subsequent behaviour. Existing balances remain unchanged. Whether an operation succeeds later depends on the checks active at that moment: the role gate, identity gate, compliance gate, and pause and custody gates, together with any checks the current feature configuration adds.
In production, assign each role to a separate key: governance, supply management, custodian, and emergency authority each carry different risk. Assigning all roles to a single key removes the access separation the model provides.

Relationship to legacy types

Legacy specialized contracts (DALPBond, DALPEquity, DALPFund, DALPStableCoin, DALPDeposit, DALPRealEstate, and DALPPreciousMetal) predate the configurable DALPAsset model.

These older contracts remain documented for existing deployments and fixed contract shapes. Use DALPAsset when you need composable features and per-asset policy configuration for new instruments. If you are working with an existing deployment that uses one of these contracts, consult the legacy types documentation before migrating.

See instrument profiles for legacy-equivalent DALPAsset configurations and legacy types for the older contract families.

DALPAsset