# Custom template authoring Source: https://docs.settlemint.com/docs/operators/asset-creation/custom-template Walk an operator through creating a custom DALP instrument template, from choosing a base type and asset class to publishing the template for the Asset Designer. This tutorial walks you from a blank custom template to a published template the Asset Designer offers alongside the seeded system templates. By the end, you have a custom template that names its required token features, declares its metadata schema, lists which feature parameters operators configure during asset creation, and shows up in the Asset Designer's template picker for your organisation. Use this tutorial when none of the [system templates](/docs/operators/asset-creation/system-templates) fits the instrument you need to model. If a system template is close, prefer customising the asset during creation over building a new template — system templates carry shared semantics auditors recognise. ## What you build [#what-you-build] By the end of this tutorial you have: * A draft template named for the instrument you are modelling, scoped to your organisation. * A base asset type, an asset class, and a required-feature list the platform validates against the dependency and incompatibility rules. * A metadata schema covering the immutable, restricted-mutable, and editable fields the Asset Designer collects. * A `feature_config` block declaring which feature parameters operators configure in the wizard. * A published template the Asset Designer offers to operators in your organisation. ## Before you start [#before-you-start] Confirm these are in place before you open the templates workspace: * You have platform-administrator or template-manager access in the active organisation. The custom-template workspace is gated by the same role that publishes system addons. * The required feature factories for the template are enabled in the target environment. Templates that name a feature without an installed factory fail validation when an operator tries to create an asset. * You can name the instrument the template will model and you know which existing system template it most resembles. Reading the closest system template's required-feature list before you start saves an iteration later. ## Step 1: Open the templates workspace [#step-1-open-the-templates-workspace] Navigate to **Platform settings > Templates > Instruments** in the Asset Console, or go to `/platform-settings/templates/instruments` directly. The workspace lists the seeded system templates (read-only for non-system operators) and any organisation-owned templates the platform has already published. Look for the template-create entry. You should see a list view with system templates marked separately from organisation templates. If you do not see the entry, confirm you have the template-manager role for the active organisation. ## Step 2: Create a draft [#step-2-create-a-draft] Click the create entry and give the template: * A short display name. The Asset Designer surfaces this name in the template picker. Use the instrument shape, not an internal code (`Senior Secured Note`, not `SSN-T1`). * A description that names the instrument shape and the operating model. Operators read this when they pick the template; an auditor reads this when they trace why the template exists. * A base asset type. Pick the closest match: `bond`, `equity`, `fund`, `deposit`, `stablecoin`, `precious-metal`, or `real-estate`. The base type controls the underlying contract behaviour the template inherits. * An asset class. Pick from the seeded classes (`fixed-income`, `equity`, `funds`, `cash`, `real-assets`, `structured`) unless your organisation has registered a custom class. The class drives sidebar grouping and downstream filtering. After save, the template lands as a draft. Drafts are visible to operators with template access but the Asset Designer does not offer them in the picker until they publish. ## Step 3: Select required features [#step-3-select-required-features] Open the required-features editor. The editor offers the eleven supported token features. Pick the set that matches the instrument behaviour. Use these heuristics as you decide: * Holder snapshots for reporting almost always need `historical-balances`. Almost every system template includes it. * Periodic accrual to holders needs `fixed-treasury-yield`. The treasury must be funded for accrual to pay out, so a yield feature without a funding plan is a configuration error, not a template error. * A maturity date with face-value redemption needs `maturity-redemption`. * Fee-bearing instruments choose between `transaction-fee` (collects fees on chain) and `transaction-fee-accounting` (records fees off chain). They are mutually exclusive on the same template. * Time-based management fees need `aum-fee`. * Voting share-like instruments need `voting-power`. * Convertible instruments need both `conversion` and `conversion-minter`. The Asset Designer reports a dependency error if you pick `conversion-minter` without `conversion`. * EIP-2612 signature-based approvals need `permit`. Most templates include it because it is a usability feature, not an asset-shape feature. The editor disables incompatible options when you have already picked one half of a pair. If the editor refuses a combination, read the [feature constraints reference](/docs/architects/components/token-features/feature-constraints) to confirm the rule. ## Step 4: Declare the metadata schema [#step-4-declare-the-metadata-schema] Define the metadata fields the Asset Designer collects when an operator creates an asset from this template. Each field declares: * A field key (camelCase identifier the API uses). * A type. Supported types include `string`, `number`, `date`, `country-code`, `currency-code`, `isin`, `cusip`, `lei`, `figi`, `decimal-money`, `bps`, `percentage`, `url`, `enum`, and `address`. * A mutability mode. `immutable` fields cannot change after issuance. `restricted-mutable` fields change only through governance-controlled updates. Plain mutable fields edit freely during servicing. * A display label and an optional description. * For `enum` types, an `options` array. Pick fields that capture the instrument identity (ISIN, issuer name, issuer LEI, issue date), the instrument terms (maturity date, coupon rate, face value), and the operating context (jurisdiction, custodian, denomination currency). Refer to a system template in the same asset class for a baseline schema; copying the schema is faster than designing from scratch and keeps your custom template aligned with auditor expectations. ## Step 5: Mark which feature parameters are configurable in the designer [#step-5-mark-which-feature-parameters-are-configurable-in-the-designer] The `feature_config` block lets you mark specific feature parameters as configurable in the Asset Designer. For example, on `aum-fee` you can mark `feeBps` and `recipient` as configurable so the operator enters those values during creation. Parameters not marked configurable take the platform default. The configurable list is the contract between the template author and the asset operator: it names which parameters the operator owns and which parameters are fixed at the template level. Be deliberate. Marking everything configurable defeats the point of the template; marking nothing configurable forces every parameter into a template re-publish. ## Step 6: Validate [#step-6-validate] Save the draft and run the validate action. The platform checks: * Dependency rules: every required feature has its dependencies satisfied (for example, `conversion-minter` requires `conversion`). * Incompatibility rules: no two mutually exclusive features are enabled together (`transaction-fee` and `transaction-fee-accounting` cannot both appear). * Feature factory availability: every required feature has an installed factory in the target environment. * Metadata schema validity: every field has a supported type and a mutability mode. * Feature config validity: every `feature_config` key matches a required feature; every parameter is a known parameter for that feature. Fix any violations the validator reports. The validator messages name the rule and the offending feature or field. The most common error is forgetting to add `conversion` alongside `conversion-minter`; the second is misnaming a metadata field type (the validator lists supported types in the error). ## Step 7: Publish [#step-7-publish] Once validation passes, publish the template. Publishing flips the visibility flag the Asset Designer reads. The template now shows up in the picker for operators in your organisation. System templates stay in the catalog above the published custom templates; your custom template appears in its own organisation section. Publishing is irreversible in the sense that the Asset Designer can issue assets against the template starting immediately. You can still edit the template after publishing, but changes to required features or metadata schema take effect on assets created from that point forward — existing assets created from the earlier template version keep their original feature set. ## Step 8: Verify in the Asset Designer [#step-8-verify-in-the-asset-designer] Open **Asset Designer** and start a new asset. Confirm: * Your custom template appears in the template picker, grouped under your organisation. * The wizard collects the metadata fields you declared. * The wizard collects the feature parameters you marked configurable. * The wizard does not collect parameters you marked non-configurable. * The dependency and incompatibility validation messages match what you expected when you defined the required-feature list. If the template behaves as expected in the wizard, the tutorial is complete. The platform team can now use the template to create production assets that follow your custom configuration. ## After publishing [#after-publishing] * Document the template choice in your operating runbook so future operators know which template to pick for which instrument. * Set up review for changes: published templates affect every asset created from that point on. Treat template edits with the same review discipline as smart-contract configuration changes. * Watch the [feature constraints reference](/docs/architects/components/token-features/feature-constraints) and the [system templates catalog](/docs/operators/asset-creation/system-templates) for platform updates that may affect template validation. ## Troubleshooting [#troubleshooting] | What you see | What to check | | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Template-create entry not visible | Confirm the active organisation and your role grant template-manager access. | | Validator rejects `conversion-minter` | Add `conversion` to the required-feature list. | | Validator rejects `transaction-fee` + `transaction-fee-accounting` | Choose one. They cannot coexist on the same template. | | Validator rejects an unknown feature type | Check the spelling against the [feature constraints reference](/docs/architects/components/token-features/feature-constraints) feature-id list. | | Asset Designer does not show the template | Confirm the template is published (not draft) and you opened the Designer with the active organisation that owns the template. | | Wizard does not collect a parameter you expected | Mark the parameter `configurableInDesigner` in the `feature_config` block. | ## Read next [#read-next] * [System templates](/docs/operators/asset-creation/system-templates) for the 24 seeded templates the custom catalog extends. * [Create asset](/docs/operators/asset-creation/create-asset) for the Asset Designer flow that consumes a published template. * [Feature constraints](/docs/architects/components/token-features/feature-constraints) for the dependency, incompatibility, and order rules the validator enforces.