Asset Contracts

Identity, claim topics, and trusted issuers are defined in the claims and identity model.

Availability: DALPAsset is experimental and feature-gated. Enable the DALPAsset factory, the required token features, and their dependencies before evaluation. Do not treat enabled flags alone as production approval.

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. Use the overview to choose between DALPAsset and a legacy specialized type. The section covers the on-chain token contract, per-asset policy, and governed roles.

What this section covers

This overview is for integrating developers, solution architects, auditors, and compliance reviewers who need to understand what the asset contract owns before reading implementation detail.

The issuing organization owns the instrument policy, configuration choices, role assignments, approvals, and operational evidence. The factory deploys the contract from that submitted configuration. Each role holder owns the actions granted to that role, such as supply changes, custody actions, emergency controls, sale administration, or funds management.

Use DALPAsset when the instrument needs runtime-configurable behavior. Use a legacy specialized type only when the legal or compliance model requires the feature set to be 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 stay outside the asset contract.

Read the schematic below first, then continue to DALPAsset for the full architecture: how configuration works, change impact, and relationship to legacy types.

Asset contract model

The schematic is the audit map for the asset-contract section. The view separates policy input, deployment artifacts, governed roles, holder actions, and event evidence. The token contract is not treated as one black box.

The factory creates the token, token identity, and per-asset access manager from one configuration. Governance controls later configuration changes. Supply Management controls minting and burning. Custodian controls freezes, forced transfers, and recovery. Emergency controls pause and recovery actions. Sale Admin and Funds Manager apply only when a token sale addon is attached.

Smallest deployable shape

Create a DALPAsset through the asset factory with a DALPAssetConfig. The factory validates the configuration, creates a per-asset access manager, deploys the asset proxy, attaches compliance modules, attaches any requested token features, and emits DALPAssetCreated with the token address and OnchainID address.

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

Before issuing a DALPAsset in production, make these decisions explicit:

• Experimental, feature-gated deployment: enable DALPAsset, the requested token features, and required directory dependencies before evaluation. Confirm the target deployment policy before production issuance.
• Identity and compliance policy: define trusted issuers, claim topics, jurisdiction rules, and compliance modules before minting or transferring tokens.
• Asset type and jurisdiction: set assetTypeName and the ISO 3166-1 numeric countryCode at creation time so deployment addresses, metadata, and policy records match the intended instrument.
• Role custody: separate governance, supply management, custodian, emergency, sale administration, and funds-management duties. Do not give one operational signer every role by convenience.
• Feature configuration: attach only features that the instrument needs, and record who can change each feature after deployment.
• Audit evidence: 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

See Legacy-Equivalent Presets for the full configuration spec: token features, compliance modules, parameters, and legacy equivalents per instrument.

When to choose

• DALPAsset: runtime flexibility. Attach and reconfigure token features after deployment when the contract and governance policy permit it. Recommended for new projects that need configurable instrument behavior. See DALPAsset for details and Legacy-Equivalent Presets for configuration guidance.
• Legacy specialized type: 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 for the full decision checklist.

Common foundation

Every asset type, including DALPAsset and specialized contracts, shares the same SMART Protocol foundation:

• ERC-3643 compliance: on-chain transfer enforcement via compliance modules
• ERC-20 compatibility: standard wallet, DEX, and tooling support
• OnchainID integration: identity registry for KYC/AML claims
• ERC-2771 meta-transactions: gasless operations via trusted forwarders
• ERC-165 introspection: external systems query supported capabilities
• Unified RBAC: seven per-asset roles with separation of duties (see RBAC)

Further reading

• DALPAsset: recommended configurable contract type
• Legacy-Equivalent Presets: pre-built configurations per instrument type
• Legacy Types: compile-time types, decision checklists, coexistence guidance
• RBAC: per-asset role model and separation-of-duties invariants
• Deployment Architecture: factory pattern, invariants, failure modes
• Token Features: runtime-pluggable feature catalog
• Compliance Modules: transfer and supply rule engine