Asset Contracts

You define identity, claim topics, and trusted issuers 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 you evaluate it. 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.

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 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. 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.

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.

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 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

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

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 for details and Legacy-Equivalent Presets 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 for the full decision checklist.

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 for the role identifiers and duties.

Further reading

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