Tokenization modeling
How DALP composes a deployable digital asset from an instrument template, metadata, token features, and compliance rules without requiring a new contract for every business case.
DALP models a tokenized asset before it reaches issuance. Each asset is a configured SMART Protocol token: DALP's ERC-3643 layer with ERC-20-compatible balances and transfers. Asset class, instrument template, metadata fields, token features, and compliance rules together define what gets issued.
For the issuance workflow, see Asset issuance. For component details, see SMART Protocol integration, Instrument profiles, Token features, Asset policy, and Compliance modules.
The short version
A DALP asset is a SMART Protocol token configuration, not a standalone token contract. It combines asset 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 layer. 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. That base type is the starting point for deployment, not the whole asset model. Metadata fields describe the instrument. Token features add runtime behaviour. Asset policy combines the configured compliance modules, identity records, and parameters DALP evaluates before regulated operations are permitted. Stateful modules then use lifecycle hooks after successful token operations to update counters, approval usage, holding periods, or issuance trackers.
| 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. | Asset policy |
These distinctions matter when your organisation needs a custom asset pattern. If the existing base asset type fits the deployment behaviour, your changes usually belong 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 setup. 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 input to drive the issuance flow.
Keep the four layers separate
Keep these layers separate when you design 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, or reporting behavior at the token layer, and some act as approval helpers.
Asset economics describe how value moves or accrues for the instrument. Pricing, settlement allowances, fees, yield, maturity dates, and redemption or conversion settings belong here when the selected template or feature set supports them.
Compliance modules decide which regulated operations are permitted. They enforce rules covering identity, jurisdiction, supply caps, investor counts, collateral, capital-raise thresholds, transfer approval, and holding periods.
Keeping these layers distinct 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 govern 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 you review a product design. Templates and metadata describe the instrument. Token features cover supported economics. Compliance modules enforce eligibility. Lifecycle operations then apply those settings across 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 the instrument requires. The examples below show common patterns for DALPAsset, not separate token types that force a new contract for every use 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 configuration, external transaction fee configuration, 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 inputs.
Use this table as a design aid, then review the detailed feature and compliance pages before you create 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? | Asset policy and Compliance modules |
| How does identity-backed compliance work? | Identity & Compliance |
Design checklist
Before you issue 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 eligibility and transfer controls you need.
- The initial operators have the required platform and on-chain roles for issuance and later servicing.
Capability docs matrix
Map DALP capabilities to the public documentation pages that explain the architecture, operator workflow, API integration path, and review notes for each capability.
Component catalog
Use the DALP component catalog to find the platform surface, infrastructure service, asset contract layer, token feature, or capability that owns an architecture decision, integration handoff, control, or evidence trail.