# Instrument templates Source: https://docs.settlemint.com/docs/operators/asset-creation/instrument-templates Create, reuse, and publish instrument templates for the Asset Designer. Instrument templates help asset teams turn a repeatable product shape into a safe Asset Designer starting point. A template groups the asset class, deployable asset type, required token features, feature defaults, and metadata fields that DALP should collect during issuance. DALP includes 24 system product templates plus the Configurable Asset starter across fixed income, equity, funds, cash, real assets, and structured instruments. Use **From scratch** when your product needs a blank template rather than a product-template starting point. Use instrument templates when you want repeatable setup for a family of assets, such as bonds with maturity and yield settings, stable-value instruments with required metadata, structured notes with maturity settings, or organization-specific asset classes. Before you create or duplicate a template, decide what should be fixed for every asset in the family and what the issuer should still enter during asset creation. Fixed settings stay on the template as defaults. Configurable settings appear in the Asset Designer as issuer inputs. ## Template types [#template-types] DALP uses templates at different points in asset setup: | Template type | What it configures | When to use it | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Instrument template | Asset class, deployable asset type, required token features, feature defaults, and metadata fields for the Asset Designer. | Reuse a complete issuance pattern for assets that share the same business and operational shape. | | Token template settings | Token-level behaviors that are attached during issuance, such as maturity redemption, yield, fees, conversion, or permit support. | Make a behavior mandatory for every asset created from the instrument template. | | Metadata schema | Fields the Asset Designer must collect, including field key, label, type, mutability, required status, and constraints. | Collect repeatable product, regulatory, or reporting data during asset creation. | | Compliance template | Compliance modules, jurisdiction scope, required controls, and whether selected controls remain configurable in the designer. | Reuse policy controls for assets that follow the same regulatory or organization-specific ruleset. | These templates compose rather than replace each other. An instrument template handles the asset setup, token template settings handle token behavior, metadata fields handle asset-specific information, and a compliance template can be selected in the compliance step when the asset needs reusable policy controls. ## Where templates fit [#where-templates-fit] An instrument template does not issue an asset by itself. It defines reusable defaults and requirements that the Asset Designer applies when an operator creates an asset. ## DALP library taxonomy [#dalp-library-taxonomy] DALP library templates give operators a current starting point for common regulated-asset patterns. The platform provides them as read-only templates. Duplicate a library template when your organization needs a local variant with different feature choices, metadata fields, or wording. | Asset class | System product templates | | ------------ | -------------------------------------------------------------------------------------------------------------- | | Fixed income | Corporate Bond, Sovereign Bond, Convertible Note, Syndicated Loan, Treasury Bill, Green Bond, Commercial Paper | | Equity | Common Equity, Preferred Equity, Employee Equity Award | | Funds | Mutual Fund, ETF, Money Market Fund, Private Equity Fund | | Cash | Fiat-Backed Stablecoin, Tokenized Bank Deposit, Certificate of Deposit | | Real assets | Gold-Backed Token, Commercial Real Estate, Carbon Credit, Tokenized Art | | Structured | Principal-Protected Note, Autocallable Note, Asset-Backed Token | Use **From scratch** for the Configurable Asset starter when the product does not fit a preconfigured system product template. The Asset Designer still guides the flow. DALP does not count this starter as one of the 24 system product templates. ## Template sources and statuses [#template-sources-and-statuses] The instrument template list separates templates by source and status: | Field | Meaning | | ----------------- | -------------------------------------------------------------------------------------------------------- | | Source | DALP library templates are system-provided. Organisation templates are created by your organization. | | Status | Draft templates can still be prepared before use. Published templates are ready for operators to select. | | Asset class | The business category used to group and filter templates. | | Required features | Token features that the template attaches to assets created from it. | The list page supports search, source filtering, status filtering, and asset-class filtering. Template cards show the template name, description, source, status, and any required feature badges. ### Find a template in a large list [#find-a-template-in-a-large-list] The instrument template list and the compliance template list each show the first 100 templates. If your organization has more than 100, the extra templates are not lost: the list tells you they exist and search brings them back into view. Above the cards, the list shows a **Showing N of M** count whenever the total is known, so you can see how many templates exist beyond the ones on screen. When an organization holds more than 100 templates, the list shows a refine-search notice alongside the count: **Refine your search to find templates beyond the first N shown.** The notice appears only when the rendered cards are fewer than the reported total, so a full list never shows it. To reach a template past the first 100, type part of its name or description into the search box at the top of the list. Search runs against the templates allowed by the active filters, not only the cards currently rendered, so any named template that matches the current filter set stays reachable even when it falls outside the first 100. For the compliance template list, the configured version filter also controls which templates are searched: if the version filter is set to **Current**, legacy templates from earlier versions are excluded from both the list and the search results until the filter is changed. ## Show or hide templates and asset classes [#show-or-hide-templates-and-asset-classes] Operators can tidy what the Asset Designer offers by hiding instrument templates and asset classes their organization does not use, without deleting anything. For asset classes and for the **Hide from the asset designer** switch on templates, visibility is a per-organization display preference: changing it affects only your organization's view and leaves the template or class available to every other organization. New asset classes and templates are visible by default. Hiding is safe on both DALP library (system) and organization templates. It is the one preference you can change on an otherwise read-only system template or system asset class. The underlying definition is not modified, renamed, or removed, and you can restore it at any time. Hidden instrument templates show a **Hidden** badge in the templates list so operators can review and restore them. ### Instrument template visibility [#instrument-template-visibility] Open **Organisation settings → Products & assets → Instrument templates**, then open the template you want to adjust. On the template detail page, an instrument template has two independent visibility switches: * **Hide from main sidebar** removes the template from the main sidebar navigation. Because the sidebar is shared across all organizations, this change affects every organization, not just yours. Use it only when a system template should not appear in the sidebar for any operator. The template remains available in the Asset Designer for issuance. * **Hide from the asset designer** removes the template from the Asset Designer selection step so operators can no longer pick it for new assets. This is a per-organization preference: it affects only your organization and leaves the template selectable for everyone else. Assets already issued from the template are unaffected. A template that is hidden from the Asset Designer keeps its **Hidden** badge in the templates list, so you can find it and make it selectable again later. ### Asset class visibility [#asset-class-visibility] Open the asset class in the same **Products & assets** settings area and use the **Hide** action to remove the class from the Asset Designer's asset-class step. Hiding a class also removes its templates from that step, because operators reach those templates through the class. Use **Make visible** to restore it. As with templates, this is a per-organization preference that does not modify or delete the class, and it applies to both system and custom classes. Hiding does not edit a template or class, so it is not a substitute for editing organization-owned templates or for authoring a new custom template. Use it to keep the issuance pickers focused on the products your organization actually offers. ## Create or duplicate a template [#create-or-duplicate-a-template] Open **Organisation settings → Products & assets → Instrument templates**, then choose one of the creation modes: * **From existing** copies an existing template into a new draft, including its asset class, required features, metadata schema, feature configuration, and base asset type. Use this when a DALP library template is close to the product you need. * **From scratch** starts a new draft where you select the asset class and configure the template manually. Use this when no system product template fits the product shape. When creating or editing a template draft, configure the reusable parts first: * **Name and description** so operators can pick the right template later. * **Asset class** to connect the template to a managed asset category. * **Required features** to attach token-level behavior such as maturity, yield, fees, conversion, permit support, voting power, or historical balances. After the draft exists, use the template detail page to add metadata fields and adjust feature-specific settings. Publish only after the required features, configurable settings, and required metadata fields match the issuance pattern you want operators to reuse. Template names must be unique within the organization. If a duplicate name is entered, DALP keeps the form open and shows an inline validation message. ## Work with required features [#work-with-required-features] DALP shows required features as badges on template cards and as active features on the template detail page when the matching feature is available in the environment. These are token features, not compliance modules. Operators select compliance controls separately in the compliance step or through compliance templates. On the template detail page, users with template management permissions can: * add available features, * remove active features, * adjust feature configuration, * choose which configured feature settings remain editable in the Asset Designer. Configurable feature settings are controlled per setting. For example, a template can keep a fee recipient fixed while allowing an operator to enter the fee value during asset creation. Settings that are not configurable stay on the template as defaults and do not appear as editable inputs in the Asset Designer. During asset creation, configurable settings from the selected template are grouped by token feature. Each feature card has its own heading and can be expanded or collapsed independently, so operators can complete maturity, yield, fee, conversion, and metadata fields without mixing the controls together. DALP only asks operators for template settings that remain editable in the Asset Designer. Locked settings stay on the template as defaults. If a fixed-yield template supplies a basis-per-unit default, the operator may leave that field empty while the denomination asset still matches the template. Choosing a different denomination makes the basis-per-unit value required again because the amount must match the new token decimals. If a copied template references a feature that is not deployed in the current environment, DALP warns the operator while preparing the new draft instead of silently treating that draft as fully ready. ## Know which fields the template owns [#know-which-fields-the-template-owns] An instrument template owns the fields that define the reusable issuance pattern. Asset creators supply values only where the template or the Asset Designer leaves an input open. | Field | Owned by | How it affects asset creation | | --------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Base asset type | Template | Selects the concrete deployable asset behavior behind a custom template, such as a deposit-style or bond-style asset. The asset creation request selects the template, not a different base type. | | Required features | Template | Determines which token features DALP attaches to assets created from the template. Asset creators can complete configurable feature settings, but they do not remove the template's required features during issuance. | | Feature configuration | Template, with selected issuer inputs | Supplies default feature settings. Settings marked configurable appear in the Asset Designer and are submitted as `featureConfigs`; locked settings remain on the template as defaults. | | Metadata schema | Template | Defines the metadata fields the Asset Designer collects. Required metadata fields must be completed before creation can continue. | | Metadata values | Asset creator | Provides the values for fields declared by the template metadata schema. Immutable metadata values are locked on the issued asset after deployment. | | Compliance controls | Compliance template or manual setup | Adds initial compliance modules during the compliance step. If a compliance template is selected, DALP requires the selected controls to be submitted with the create request. | When the API receives a `dalp-asset` create request, `templateId` is required. DALP reads the template and combines its required features with the submitted feature configuration. It checks that incompatible features are not enabled together, then passes the template metadata schema into deployment so immutable metadata fields are encoded as immutable on the issued asset. Keep feature settings and metadata fields separate when you design or review a template. Maturity date and face value belong to the maturity redemption feature when that feature controls the instrument. Currency comes from the selected denomination or backing source where the template derives it from another field. Issuer country comes from the asset creation basics step. Use metadata fields for additional instrument facts that the feature configuration or basics step does not already own. This boundary prevents the Asset Designer from asking for the same business fact twice. It also makes later review clearer. Feature settings explain token behaviour, metadata values explain asset record facts, and basics fields explain the common issuance context. ## Define metadata fields [#define-metadata-fields] The **Metadata** tab appears when a template has metadata fields or when the current user can manage the template. Each metadata field has a field key, type, mutability, label, optional required status, and optional constraints. Supported metadata field types include string, number, date, enum, ISIN, address, basis points, percentage, currency code, country code, LEI, CUSIP, FIGI, decimal money, and URL fields. Required fields must be completed during asset creation. Fields marked immutable are locked on the issued asset after deployment. Fields marked restricted-mutable can still be managed through the supported metadata update flow, subject to permissions and governance controls. ## Publish, duplicate, edit, and delete [#publish-duplicate-edit-and-delete] Template operations are available from the template detail page. | Operation | When to use it | | --------- | ---------------------------------------------------------------------------------------------------- | | Edit | Update an organization-owned template before or after publication. System templates are read-only. | | Duplicate | Start a new draft from an existing template while preserving the original. | | Publish | Move an organization-owned draft template to the published state so it can be selected for issuance. | | Delete | Remove an organization-owned template after explicit confirmation. | DALP library templates are read-only. They can be duplicated when your organization needs a similar template with its own asset class, feature choices, or metadata fields. ## How templates affect asset creation [#how-templates-affect-asset-creation] When an operator selects a template in the Asset Designer: * required feature badges explain which token behaviors are included, * template-specific metadata fields are added to the details step, * required metadata fields must be completed before the wizard continues, * template defaults are applied for feature-specific settings, * feature-specific fields are grouped into separate cards when the selected template includes more than one configurable feature, * the selected template determines which asset class and base asset behavior the deployed asset uses. When an operator switches templates, the Asset Designer clears feature-mapped values and applies the new template defaults. This keeps values from a previous template, such as a maturity date or fee setting, out of the next issuance. Required token features can depend on other tokens: * Maturity redemption, fixed treasury yield, and external transaction fee behaviour need an ERC-20 token in the tenant. * Conversion needs an equity-class target token. If a required token is missing, the Asset Designer disables the affected template and shows the missing token type. The operator can create or register the required token, then return to the wizard and select the template after the token is available. Feature dependencies belong to the template configuration itself. Include `conversion` when a template includes `conversion-minter`; the minter must be paired with the conversion behaviour it serves. For the current dependency, incompatibility, and feature-closure rules, see [Token feature constraints](/docs/architects/components/token-features/feature-constraints). ## Model instruments outside the library catalog [#model-instruments-outside-the-library-catalog] Some instruments do not have a dedicated DALP library template. The current library catalog does not include stock templates for promissory notes, letters of credit, bills of exchange, guarantees, or warehouse receipts. Model those instruments by creating an organization template from the closest base behavior rather than naming a non-existent system template. Use this rule of thumb: | Instrument shape | Start from | Why | | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Promissory note, bill of exchange, commercial paper variant, or other maturity-based promise to pay | Bond-style template or a custom template with `bond` as the base asset type | The instrument usually has a face value, maturity date, optional yield or coupon behavior, and redemption at maturity. | | Letter of credit, guarantee, standby LC, or warehouse receipt pattern | Deposit-style or custom template, depending on the operating model | The template can capture the obligation, custodian or issuer context, document references, and transfer controls without implying a stock LC or guarantee template exists. | | Trade-finance receivable or supply-chain finance asset | Bond-style or deposit-style custom template, depending on tenor and repayment behavior | The repayment schedule, discounting, and transfer model decide which base behavior fits better than the market label. | Add instrument-specific metadata fields for the facts the Asset Designer should collect, such as issuer or maker, beneficiary or payee, governing law, due date, document reference, and final-terms document hash. Keep legal document workflows, document storage, and off-chain obligation management in the operating runbook or integration layer unless your implementation has a verified DALP workflow for them. ## Examples [#examples] Use these examples as patterns for how template parts affect issuance: * A bond-style instrument template can require maturity redemption and fixed treasury yield features. During asset creation, the operator sees those token behaviors as required feature badges and completes any configurable settings before deployment. * A real-world asset template can require metadata such as an ISIN, valuation date, address, or reporting category. Required metadata fields block wizard progress until completed. Immutable metadata fields are locked on the issued asset, while restricted-mutable fields can still follow the supported metadata update flow. * A precious metal template can require metal classification, weight, valuation, and custody context before issuance. See the [`system-precious-metal` entry in the system templates catalog](/docs/operators/asset-creation/system-templates#real-assets-asset-class-real-assets) for the metadata fields the wizard collects. * A compliance template can group reusable controls such as country lists, identity checks, holding limits, and transfer approvals. In the compliance step, the Asset Designer filters published templates by the asset context and carries selected controls into the asset's initial compliance setup. * Operators can also skip a compliance template and configure compliance modules manually when the asset needs one-off policy setup instead of a reusable template. For the end-to-end issuance flow, see [Create asset](/docs/operators/asset-creation/create-asset). For a step-by-step custom-template walkthrough, see [Custom template authoring](/docs/operators/asset-creation/custom-template). For the conceptual model behind templates, see [Tokenization modeling](/docs/architects/concepts/tokenization-modeling).