# Institutional asset tokenization architecture

Source: https://docs.settlemint.com/docs/architects/architecture/start-here/asset-model
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-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.

<Mermaid
  chart="`flowchart TD
  DESIGN[&#x22;Asset design\nClass, template, metadata&#x22;] --> FACTORY[&#x22;DALP asset factory\nIssued SMART Protocol asset&#x22;]
  FACTORY --> TOKEN[&#x22;Issued asset\nToken, identity, features&#x22;]

  POLICY[&#x22;Compliance controls\nIdentity, eligibility, policy&#x22;] --> TOKEN
  CUSTODY[&#x22;Custody-aware signing\nRoles, approvals, signer path&#x22;] --> ACTIONS[&#x22;Lifecycle actions\nMint, burn, transfer, service&#x22;]
  TOKEN --> ACTIONS
  POLICY --> ACTIONS

  ACTIONS --> SETTLEMENT[&#x22;Settlement workflows\nPvP, DvP, XvP when configured&#x22;]
  ACTIONS --> EVIDENCE[&#x22;Monitoring and evidence\nEvents, API reads, exports&#x22;]
  SETTLEMENT --> EVIDENCE
  API[&#x22;Unified API\nExternal systems integrate&#x22;] --> ACTIONS
  EVIDENCE --> API

  style DESIGN fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#2a2540
  style FACTORY fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#2a2540
  style TOKEN fill:#2a2540,stroke:#5fc9bf,stroke-width:2px,color:#fff
  style POLICY fill:#4f7f65,stroke:#345943,stroke-width:2px,color:#fff
  style CUSTODY fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style ACTIONS fill:#d99a5f,stroke:#a66e38,stroke-width:2px,color:#2a2540
  style SETTLEMENT fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style EVIDENCE fill:#2f6f9f,stroke:#1f4d70,stroke-width:2px,color:#fff
  style API fill:#44546a,stroke:#2f3b4b,stroke-width:2px,color:#fff`"
/>

| 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](/docs/architects/architecture/flows/asset-issuance)               |
| Issued token         | A SMART Protocol asset with token extensions, attached runtime features, token identity, and compliance engine bindings.                 | [DALPAsset](/docs/architects/architecture/components/asset-contracts/dalp-asset)   |
| Compliance controls  | Identity claims, scoped compliance modules, transfer validation, approval controls, and collateral checks where configured.              | [Compliance modules](/docs/compliance-security/security/compliance)                |
| Custody and signing  | Platform roles, transaction preparation, approval state, and the configured signing path for privileged actions.                         | [Signing flow](/docs/architects/architecture/flows/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](/docs/architects/architecture/flows/xvp-settlement)               |
| Monitoring and audit | Events, indexed token reads, API monitoring, reporting, exports, and operational evidence for review.                                    | [API monitoring](/docs/developers/developer-guides/api-integration/api-monitoring) |
| API integration      | Versioned API surfaces that let external systems create, service, monitor, and reconcile tokenized assets without bypassing controls.    | [API integration](/docs/developers/developer-guides/api-integration)               |

## The asset model at a glance [#the-asset-model-at-a-glance]

<Mermaid
  chart="`flowchart TD
  CLASS[&#x22;Asset class\nWhat business category is this?&#x22;] --> TEMPLATE[&#x22;Instrument template\nWhich configuration should operators start from?&#x22;]
  TEMPLATE --> BASE[&#x22;Base asset type\nWhich deployable behaviour and pricing fields apply?&#x22;]
  TEMPLATE --> META[&#x22;Metadata schema\nWhich instrument facts must be captured?&#x22;]
  TEMPLATE --> FEATURES[&#x22;Required token features\nWhich runtime behaviours are attached?&#x22;]
  TEMPLATE --> COMPLIANCE[&#x22;Compliance template or manual rules\nWhich controls apply before regulated actions?&#x22;]

  BASE --> FACTORY[&#x22;DALP asset factory&#x22;]
  META --> FACTORY
  FEATURES --> FACTORY
  COMPLIANCE --> FACTORY
  FACTORY --> TOKEN[&#x22;Issued SMART Protocol asset&#x22;]

  style CLASS fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#2a2540
  style TEMPLATE fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#2a2540
  style BASE fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#2a2540
  style META fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#2a2540
  style FEATURES fill:#d99a5f,stroke:#a66e38,stroke-width:2px,color:#2a2540
  style COMPLIANCE fill:#4f7f65,stroke:#345943,stroke-width:2px,color:#2a2540
  style FACTORY fill:#2f6f9f,stroke:#1f4d70,stroke-width:2px,color:#fff
  style TOKEN fill:#2a2540,stroke:#5fc9bf,stroke-width:2px,color:#fff`"
/>

## Asset class, base asset type, and template are different things [#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 [#the-smallest-working-example]

A fixed-income asset can be modelled without creating a new contract type:

1. Choose the fixed-income asset class.
2. Select an instrument template whose base asset type is `bond`.
3. Fill required metadata such as name, symbol, issuer, maturity date, denomination asset, and face value.
4. Attach required token features such as historical balances and maturity redemption when the template requires them.
5. Choose a compliance template or add compliance modules manually.
6. 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 [#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 [#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:

1. Validates the token name, symbol, and concrete asset type name.
2. Derives the on-chain asset type identifier from the concrete asset type name.
3. Deploys the SMART Protocol asset proxy and on-chain identity.
4. Installs scoped compliance modules on the token compliance engine.
5. Creates the requested token features from registered feature factories.
6. 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 [#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 [#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 [#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 [#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 [#read-next]

* [Digital asset platform overview](/docs/business/executive-overview/digital-asset-lifecycle-platform) for the buyer-level view of DALP across issuance, compliance, custody-aware signing, settlement, servicing, and operating evidence.
* [Tokenization modeling](/docs/architects/architecture/concepts/tokenization-modeling) for the concept-level model behind asset design.
* [Asset issuance](/docs/architects/architecture/flows/asset-issuance) for the operational flow from request to issued token.
* [Token features](/docs/architects/architecture/components/token-features) for the feature catalogue, feature hooks, and feature-specific behaviour.
* [Feature constraints](/docs/architects/architecture/components/token-features/feature-constraints) for feature dependency and incompatibility checks.
* [Compliance modules](/docs/compliance-security/security/compliance) for transfer and eligibility controls.
* [Custody providers](/docs/architects/architecture/integrations/custody-providers) for custody-provider routing and signing responsibilities.
* [XvP settlement](/docs/architects/architecture/flows/xvp-settlement) for PvP, DvP, and XvP settlement coordination.
* [Compliance modules API](/docs/developers/developer-guides/api-integration/compliance-modules) for token-level install, scoped binding, parameter update, and indexing behaviour.
* [Token lifecycle API](/docs/developers/developer-guides/api-integration/token-lifecycle) for token creation inputs, token operation hooks, and lifecycle reads.
* [Instrument templates](/docs/operators/user-guides/asset-creation/instrument-templates) for the operator-facing template workflow.