Institutional asset tokenization architecture
See how DALP structures institutional asset tokenization across asset templates, SMART Protocol contracts, identity, compliance controls, custody routing, settlement, monitoring, and APIs.
DALP structures institutional asset tokenization as one controlled path from instrument design to issued SMART Protocol asset. The architecture separates the product template, deployable token behaviour, metadata, identity, compliance rules, custody-aware signing, settlement coordination, monitoring, and API integration points so each regulated operation has a clear control surface.
The practical rule is simple: do not treat every product variation as a new token type. Most variations belong in an instrument template, metadata schema, token feature configuration, compliance template, or surrounding operating workflow. DALP covers the EVM tokenization path. Custody policy, external payment rails, accounting treatment, and legal terms stay in the institution's target operating model.
Institutional architecture at a glance
Institutional tokenization needs more than a token factory. The operating architecture has to explain where the instrument is modelled, which rules can stop an action, who signs privileged transactions, how settlement is coordinated, and where operators read evidence after the action.
| Architecture layer | What DALP represents | Where to go next |
|---|---|---|
| Asset model | Asset classes, base asset types, instrument templates, metadata, required token features, and compliance template choices. | Asset issuance |
| Issued token | A SMART Protocol asset with token extensions, attached runtime features, token identity, and compliance engine bindings. | DALPAsset |
| Compliance controls | Identity claims, scoped compliance modules, transfer validation, approval controls, and collateral checks where configured. | Compliance modules |
| Custody and signing | Platform roles, transaction preparation, approval state, and the configured signing path for privileged actions. | Signing flow |
| Settlement | PvP, DvP, or XvP workflows when the deployment uses settlement addons. External payment rails still need their own reconciliation model. | XvP settlement |
| Monitoring and audit | Events, indexed token reads, API monitoring, reporting, exports, and operational evidence for review. | API monitoring |
| API integration | Versioned API surfaces that let external systems create, service, monitor, and reconcile tokenized assets without bypassing controls. | API integration |
The asset model at a glance
Asset class, base asset type, and template are different things
These terms are easy to blur because they meet in the Asset Designer. They answer different questions.
| Layer | What it answers | Examples | Why it matters |
|---|---|---|---|
| Asset class | How should operators understand and browse the instrument? | Fixed income, equity, fund, stable value, deposit, real estate, precious metal | It is the business grouping shown to users. Custom classes can exist without requiring a custom token contract. |
| Base asset type | Which deployable behaviour and pricing fields should DALP use? | bond, equity, fund, stablecoin, deposit, real-estate, precious-metal | It drives the concrete creation flow, type-specific fields, and post-creation rendering. |
| Instrument template | Which reusable configuration starts the asset creation flow? | A system template or an organisation-specific template | It binds asset class, base asset type, required token features, metadata fields, and default feature settings. |
| Issued asset | What exists on-chain after creation? | A SMART Protocol asset with metadata, features, compliance modules, and identity integration | This is the token users mint, transfer, service, monitor, and audit. |
For a custom instrument, start by asking whether an existing base asset type already provides the deployable behaviour. If it does, model the customisation as a template and attach the right metadata, features, and compliance controls.
Published templates freeze the deployable asset path. You can update template details that remain compatible with the published model, but baseAssetType and typeId cannot change after publication because they determine the pricing fields, wizard steps, summary rendering, and asset creation route. If a new product needs different deployable behaviour, create a new template instead of mutating a published one.
The smallest working example
A fixed-income asset can be modelled without creating a new contract type:
- Choose the fixed-income asset class.
- Select an instrument template whose base asset type is
bond. - Fill required metadata such as name, symbol, issuer, maturity date, denomination asset, and face value.
- Attach required token features such as historical balances and maturity redemption when the template requires them.
- Choose a compliance template or add compliance modules manually.
- Create the asset. DALP routes the completed template configuration through the DALP asset factory and issues a SMART Protocol asset.
That flow produces one issued asset. The template describes how to create it. The base asset type supplies the deployable behaviour. The token features add runtime behaviour. Compliance modules decide whether regulated actions are allowed.
Token extensions and token features are not the same thing
DALP uses two related terms that should stay separate in documentation and integrations.
| Term | What it means | Where it is used | Examples |
|---|---|---|---|
| Token extension | A contract-level capability exposed by the asset itself. These are discovered as interfaces and describe what the token contract supports. | Asset capability checks, UI filtering, and contract compatibility. | Access managed, burnable, capped, collateral, configurable, custodian, historical balances, metadata, pausable, redeemable, yield. |
| Token feature | A runtime-attached behaviour created from a feature factory and attached during asset creation. These are selected by templates and encoded into the factory create call. | Instrument template requiredFeatures, feature configuration, and DALP asset creation. | Historical balances, maturity redemption, fixed treasury yield, voting power, AUM fee, transaction fee, transaction fee accounting, external transaction fee, conversion, conversion minter, permit. |
historical-balances appears in both worlds because DALP has a contract-level historical-balance capability and a runtime feature factory for historical-balance behaviour. That overlap does not make the two lists interchangeable.
When you model a new template-backed asset, use the template's requiredFeatures and featureConfigs to select runtime behaviour. Use token extensions to describe the asset contract capabilities that DALP discovers from the factory or issued token. A factory response can expose tokenExtensions such as PAUSABLE, BURNABLE, or CUSTODIAN, but that list is not the input list for feature factories.
Asset-version filtering applies at the read surface, not in the template model. Current SMART Protocol token reads expose indexed facts about the issued token: extensions, implementsSMART, smartInterface, complianceContract, complianceModuleConfigs, identity, and collateral. Legacy assets can still appear through compatibility paths, but they do not gain current configurable hooks merely because a template names a similar behaviour.
| If you need to decide... | Use this model |
|---|---|
| Whether an issued asset contract exposes pause, burn, custody, or cap | Token extensions discovered from indexed contract state or the factory response. |
| Which behaviours the Asset Designer must attach during creation | Token features selected by the instrument template and encoded into the DALP asset factory create call. |
| Whether a token supports current configurable behaviour | The token read response: implementsSMART, smartInterface, and fields such as extensions and complianceContract. |
| Whether two runtime behaviours can be enabled together | Token feature compatibility rules. DALP checks the template's required features and configured feature IDs before it starts the creation workflow. |
| Whether a transfer, mint, burn, or servicing action is allowed | Compliance modules and token feature hooks. Extensions describe what the token can support; compliance and runtime features decide what happens at action time. |
| How collateral is represented | As token identity claims and indexed collateral stats exposed on the token read response, with collateral compliance modules enforcing the required claim and ratio during actions. |
The current creation path
New template-backed assets use the DALP asset factory path. The creation request carries the selected template, metadata values, compliance module pairs, and per-feature configuration. DALP resolves the template's required feature list, expands supported direct feature dependencies, drops unknown feature IDs from the on-chain feature list, encodes feature configuration, and passes the resulting feature array to the asset factory.
The factory then:
- Validates the token name, symbol, and concrete asset type name.
- Derives the on-chain asset type identifier from the concrete asset type name.
- Deploys the SMART Protocol asset proxy and on-chain identity.
- Installs scoped compliance modules on the token compliance engine.
- Creates the requested token features from registered feature factories.
- Attaches all created features to the asset in the submitted order.
The order of token features matters because attached features can affect token-operation semantics. Templates should therefore keep a deliberate required-feature order rather than treating the list as a cosmetic tag set.
Feature configuration at asset design time
Required token features are not just labels on a template. They decide which runtime behaviours DALP attaches when the asset is created.
Some features can attach from the template alone. Others need issuer input in the Asset Designer before DALP can encode the creation request.
Use this split when designing or reviewing a template:
| Feature decision | Where it belongs | Why it matters |
|---|---|---|
| The behaviour must exist on every asset | Add the feature to the instrument template's required feature list. | DALP resolves the template feature list before the creation workflow starts. |
| The behaviour needs per-asset parameters | Keep the feature required, then expose the supported configuration fields in the Asset Designer. | The issuer supplies maturity, yield, management-fee, conversion, or accounting settings. |
| Two behaviours should not run together | Model the combination against the feature compatibility rules before publishing the template. | DALP rejects incompatible feature combinations before asset creation dispatch. |
| The rule decides whether an action may pass | Use a compliance module or compliance template rather than a token feature. | Compliance controls eligibility; token features change token behaviour. |
| The information is descriptive | Capture it in the metadata schema instead of feature configuration. | Metadata records instrument facts. It does not create runtime hooks. |
A bond-like template might require maturity redemption and fixed treasury yield because each issued asset needs redemption and yield behaviour. A managed-fund template might require AUM fee when management fees accrue over time and are collected to a configured recipient. A fee-bearing template might require transaction fee or transaction fee accounting when fees should run as part of token operations. A governance-oriented template might require historical balances or voting power.
Keep the template narrow enough that every required feature is genuinely mandatory for the product shape.
Legacy factory path
DALP also contains legacy per-asset-type factories. A legacy equity factory, for example, exposes an equity-specific create function, uses the equity factory type, deploys an equity proxy, and accepts initial compliance module pairs directly in that fixed equity path.
Use the legacy model only when reading older assets, migrations, or compatibility surfaces. For new template-backed modelling, document and integrate against the DALP asset factory model:
| Question | Legacy per-type factory | Current template-backed model |
|---|---|---|
| How is the asset routed? | Through a factory dedicated to one asset type. | Through the DALP asset factory using the selected template and concrete asset type name. |
| Where does variation live? | Mostly in the specialised factory and token implementation. | In the instrument template, metadata schema, feature configuration, and compliance template. |
| How are token features attached? | The factory path is fixed for that asset type. | The template supplies requiredFeatures; DALP encodes and attaches the requested runtime features. |
| How are compliance rules represented? | Initial module pairs are passed into the specialised factory path. | Scoped compliance module pairs are installed on the issued asset's compliance engine. |
| What should public docs prefer? | Mention only for compatibility or migration context. | Use as the default model for new asset creation and template design. |
Compliance belongs beside features, not inside them
Token features change token behaviour. Compliance modules decide whether an action is allowed. Keep that split clear.
A maturity-redemption feature can define redemption behaviour. A transfer-approval or country-control module decides whether a transfer or other regulated action may proceed. A collateral module can enforce collateral constraints. These controls may all be present on the same issued asset, but they answer different questions.
Compliance modules are represented as module bindings on the token's compliance engine. The creation API carries initial compliance module pairs separately from featureConfigs, and token-level compliance routes install or reconfigure one binding at a time after issuance. The API exposes the token's compliance contract and configured module bindings on token reads. Scoped bindings include a scope object plus module parameters, so the same module type can govern different transfer populations when the token has a dedicated compliance engine.
Collateral is represented through the token's on-chain identity, indexed collateral state, and a compliance module binding. It is not a token feature and does not belong in featureConfigs or tokenExtensions. A collateral claim records the amount and expiry that the collateral check can evaluate. The token read response exposes reconstructed identity claims and, when available, the current collateral value. Collateral compliance modules use that representation to decide whether the configured collateral ratio is met before the regulated action proceeds.
| Concern | Model it as | Example |
|---|---|---|
| Instrument facts | Metadata schema | ISIN, issuer, maturity date, currency, denomination asset, face value. |
| Runtime token behaviour | Token feature | Maturity redemption, fixed treasury yield, transaction fee, permit. |
| Eligibility or policy check | Compliance module | Identity verification, country allow list, investor limit, transfer approval. |
| Collateral requirement | Compliance module | A collateral module backed by token identity claims and indexed collateral. |
| Business grouping | Asset class | Fixed income, equity, fund, deposit. |
| Deployable behaviour | Base asset type | bond, equity, fund, stablecoin, deposit. |
What this means for production design
Production asset design should start from the smallest stable model that represents the instrument honestly.
- Reuse a system base asset type when it matches the deployable behaviour.
- Create or adapt an instrument template when the difference is business terminology, metadata, economics, or required feature configuration.
- Use token features for behaviour the token must run at transfer, servicing, governance, fee, yield, redemption, or approval time.
- Use compliance modules for eligibility, jurisdiction, investor, collateral, holding-period, approval, or supply controls.
- Treat legacy factories as compatibility context, not the normal design target for new template-backed assets.
- Keep off-chain obligations, custody policy, accounting treatment, pricing methodology, and legal terms in the surrounding operating model. DALP can capture and enforce the parts represented by configured templates, features, metadata, compliance modules, and SMART Protocol contracts.
Read next
- Digital asset platform overview for the buyer-level view of DALP across issuance, compliance, custody-aware signing, settlement, servicing, and operating evidence.
- Tokenization modeling for the concept-level model behind asset design.
- Asset issuance for the operational flow from request to issued token.
- Token features for the feature catalogue, feature hooks, and feature-specific behaviour.
- Feature constraints for feature dependency and incompatibility checks.
- Compliance modules for transfer and eligibility controls.
- Custody providers for custody-provider routing and signing responsibilities.
- XvP settlement for PvP, DvP, and XvP settlement coordination.
- Compliance modules API for token-level install, scoped binding, parameter update, and indexing behaviour.
- Token lifecycle API for token creation inputs, token operation hooks, and lifecycle reads.
- Instrument templates for the operator-facing template workflow.
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.
System context
System context for DALP architecture, including external actors, operating scopes, trust boundaries, and the contract layers that keep assets, identities, compliance rules, and factory registries separated by system.