Custom template authoring

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 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

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

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

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

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

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 to confirm the rule.

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

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

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

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

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

• 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 and the system templates catalog for platform updates that may affect template validation.

Troubleshooting

Read next

• System templates for the 24 seeded templates the custom catalog extends.
• Create asset for the Asset Designer flow that consumes a published template.
• Feature constraints for the dependency, incompatibility, and order rules the validator enforces.