Asset model
How DALP models an issued asset from an asset class and instrument template through token metadata, token features, and compliance rules.
A DALP asset is a configured asset definition issued as a SMART Protocol token, DALP's ERC-3643 implementation with ERC-20-compatible balances and transfers. Asset class, instrument template, metadata fields, token features, and compliance rules define the issued asset.
For the issuance workflow, see Asset issuance. For component details, see SMART Protocol integration, Instrument profiles, Token features, and Compliance modules.
The short version
A DALP asset is a SMART Protocol token configuration, not a standalone token contract. It combines business classification, token metadata, optional runtime token features, and compliance rules.
Underlying token standard
DALP issues new assets as SMART Protocol tokens. SMART Protocol is DALP's ERC-3643 implementation. It keeps ERC-20-compatible balances and transfers, then adds the identity registry, compliance engine, and token-feature hooks that regulated assets need before mints or transfers complete.
Layers in the model
| Layer | What it answers | Examples |
|---|---|---|
| Token standard | Which on-chain standard underlies the issued asset? | SMART Protocol, DALP's ERC-3643 implementation with ERC-20-compatible balances and transfers |
| Asset class | What business category does this asset belong to? | Fixed income, equity, fund, stable value, deposit, real estate, precious metal |
| Instrument template | Which deployable configuration should the Asset Designer start from? | A system template or organization-specific template with a base asset type |
| Metadata fields | Which asset-specific facts must be captured? | Identifier, classification, dates, numeric bounds, addresses, or enum values |
| Token features | Which token behavior should run at the asset layer? | Historical balances, maturity redemption, fixed treasury yield, voting power, fees, conversion, permit |
| Compliance rules | Which eligibility, supply, approval, or jurisdiction controls apply? | Identity verification, country controls, investor limits, transfer approval, collateral, supply caps, time locks |
How templates shape issuance
Instrument templates are the bridge between business language and deployable configuration. A template can define:
- the asset class shown to operators,
- the base asset type used by the deployment flow,
- required token features,
- metadata fields and validation rules,
- feature-specific configuration fields.
During asset creation, operators fill in the configurable fields exposed by the selected template. DALP then uses that completed configuration as the input to the issuance flow.
Metadata, features, and compliance are separate
Keep these three layers separate when designing an asset:
- Metadata records asset facts. It describes the instrument and can include required fields, mutability rules, and field-level validation.
- Token features extend token behavior. They add economic, governance, lifecycle, reporting, or approval-helper behavior at the token layer.
- Compliance modules decide whether regulated actions are allowed. They enforce identity, jurisdiction, supply, investor-count, collateral, capital-raise, approval, or holding-period rules.
Separating the layers lets teams change the right control without treating every product question as a new token type.
Composition patterns
DALPAsset is the runtime-configurable asset contract: it combines the template-selected layers needed for the instrument. The examples below show common patterns for DALPAsset, not separate token types that force a new contract for every business case; legacy specialized asset types cannot use this feature-composition system.
| Pattern | Typical token features | Typical compliance controls | What this enables |
|---|---|---|---|
| Fixed income | Fixed Treasury Yield, Maturity Redemption, Historical Balances | Supply cap and jurisdiction-specific controls | Coupon-style yield, maturity date handling, and holder snapshots on one issued asset. |
| Equity | Voting Power, Historical Balances | Identity, country, and investor-count controls as required by the offering | Governance voting and shareholder-record snapshots with transfer eligibility checks. |
| Managed fund | AUM Fee, Voting Power, Historical Balances | Identity and jurisdiction controls | Management-fee collection, investor governance, and balance snapshots for NAV or reporting workflows. |
| Stable value asset | Historical Balances | Collateral, identity, country, or other jurisdiction controls | Collateral-aware issuance controls with audit snapshots for holder and supply reporting. |
| Precious metal | Historical Balances | Jurisdiction controls selected for the issuance context | Custody and ownership reporting while supply can grow as backing changes. |
Configurable features add guided Asset Designer inputs when the selected template needs them. Current configurable feature inputs include maturity redemption terms, AUM fee settings, external transaction fee settings, and conversion terms. Self-contained features can still change token behavior, but they do not always add a separate setup step unless the template supplies defaults or related settings.
Use this table as a design aid, then review the detailed feature and compliance pages before creating the asset configuration.
When to read the detailed pages
| Question | Read next |
|---|---|
| Which asset profile should I choose? | Instrument profiles |
| What happens during deployment? | Asset issuance |
| Which optional token behavior is available? | Token features |
| Which rules can restrict transfers or issuance? | Compliance modules |
| How does identity-backed compliance work? | Identity & Compliance |
Design checklist
Before issuing an asset, confirm:
- The selected asset class matches the business instrument.
- The template's base asset type matches the deployment behavior you need.
- Required metadata fields are known and can be maintained by the right operators.
- Token features are necessary for the asset behavior, not a substitute for compliance policy.
- Compliance modules and parameters match the intended eligibility and transfer controls.
- The initial operators have the required platform and on-chain roles for issuance and later servicing.
System context
DALP system boundary, external actors, trust boundaries, and the five-layer smart contract architecture that underpins the platform.
Lifecycle after issuance
How DALP operators manage an issued asset after deployment, from the asset detail workspace through supply, transfer, pause, role, compliance, feature, and audit operations.