Tokenization modeling
A concepts guide to how DALP turns an asset class and instrument template into token metadata, token features, compliance rules, and an issued asset.
This Concepts guide explains how DALP models a tokenized asset before issuance. A DALP asset is a configured asset definition issued as a SMART Protocol token. DALP uses SMART Protocol as its 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, enum values, mutability, or validation constraints |
| 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 |
Tokenization modeling choices
The base asset type supplies the deployable asset behaviour for the selected template. It is the starting point for deployment, not the whole asset model. Metadata fields describe the instrument. Token features add runtime behaviour. Compliance modules decide whether regulated actions are allowed.
| Design choice | What it changes | What it does not change | Read next |
|---|---|---|---|
| Base asset type | The deployment path and core asset behaviour | It does not replace template metadata, feature configuration, or compliance rules. | Instrument templates |
| Metadata schema | The facts collected and maintained for the asset | It does not create transfer behaviour or enforce investor eligibility by itself. | Create asset |
| Required token feature | Runtime token behaviour attached during issuance | It does not change the business asset class unless the template and asset economics also support it. | Token features |
| Compliance template | Reusable policy controls for eligibility checks | It does not define the legal terms, custody policy, accounting treatment, or off-chain settlement rules. | Compliance modules |
This separation is useful when an organisation needs a custom asset pattern. If the existing base asset type fits the deployment behaviour, the customisation usually belongs in the instrument template, metadata schema, token features, or compliance template rather than in a new token type.
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, economics, and compliance are separate
Keep these 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.
- Asset economics describe how value moves or accrues for the instrument. Pricing, settlement allowances, fees, yield, maturity, redemption, and conversion settings belong here when the selected template or feature set supports them.
- 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.
Where asset economics fit
Asset economics in DALP come from the selected instrument template, token metadata, token features, live price data, and the lifecycle operations available on the issued asset. DALP does not replace the legal, accounting, or custody systems that define off-chain obligations.
| Economic concept | DALP layer | What DALP captures or enforces | Read next |
|---|---|---|---|
| Price or valuation input | Data feed or token price route | Token pricing workflows accept a positive decimal price and ISO 4217 currency code. | Token price resolution and Data feeds |
| Settlement allowance | ERC-20-compatible token operation | Settlement flows can require senders to grant an ERC-20 allowance before the settlement contract calls transferFrom. | XvP settlement and Token lifecycle API |
| Transaction fee | Token feature | The token can deduct a per-transfer fee before the recipient receives the net amount. | Transaction Fee |
| External transaction fee | Token feature | The token can charge a fixed fee in a separate ERC-20 asset during token operations. | External Transaction Fee |
| AUM fee | Token feature | The token can calculate a management fee over time and mint fee tokens to a configured recipient. | AUM Fee |
| Fixed treasury yield | Token feature | Holders can claim fixed-rate yield from a treasury when historical balances establish entitlement. | Fixed Treasury Yield and Corporate bonds |
| Maturity and redemption | Token feature | The token can block post-maturity transfers and let holders redeem against a denomination asset. Treasury-backed workflows can require feature-specific allowance and funding checks before holder redemption. | Maturity Redemption and Lifecycle after issuance |
| Conversion | Token feature pair | Configured conversion logic can burn one instrument token and mint another. | Conversion |
Use this split when reviewing a product design. Templates and metadata describe the instrument. Token features implement supported economics. Compliance modules decide eligibility. Lifecycle operations then apply those settings during issuance, settlement, servicing, yield claims, redemption, conversion, and reconciliation. External systems remain responsible for legal terms, accounting treatment, custody policy, and off-chain cash movements.
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.
Asset policy
Understand how DALP combines identity records, compliance modules, lifecycle hooks, and governance controls to decide whether regulated token operations can execute.
Component Catalog
Map DALP component layers from entry surfaces to infrastructure services, asset contracts, token features, and optional capabilities, with the owner, control scope, exclusions, and next detail page for each layer.