# Design your own assets from templates

Source: https://docs.settlemint.com/docs/changelog/dalp-3-0/asset-templates
Turn a proven asset setup into a reusable template, so the next instrument starts from a standard instead of a blank form. Your institution's configuration knowledge travels with it.



**We shipped a template library in Asset Designer. Clone a proven instrument setup, reshape what you need, and your version lives in the library beside ours.**

<Video src="/media/dalp-3-0/asset-templates.mp4" title="Design own assets templates in DALP 3.0" description="Turn proven asset setup into reusable instrument template, so next asset starts standard instead of a blank form." />

Issuing a tokenized security is not just filling in a name and a supply number. Every instrument carries a set of on-chain capabilities that determine how it behaves: whether it pays yield, whether it redeems at maturity, which compliance rules fire on transfer, what metadata a reviewer needs to see. Getting that configuration right on the first launch is a technical problem. Getting it right consistently across dozens of launches is an organizational one. Asset templates solve the organizational problem by making your institution's correct configuration the default, not the goal.

<Spotlight
  eyebrow="Asset templates"
  title="Institutional knowledge, captured once and reused every time"
  aside="<FactList items={[
  { label: &#x22;Asset classes&#x22;, value: &#x22;Six&#x22; },
  { label: &#x22;Standard&#x22;, value: &#x22;ERC-3643&#x22; },
  { label: &#x22;Your templates&#x22;, value: &#x22;Same library&#x22; },
  { label: &#x22;Checks&#x22;, value: &#x22;At design time&#x22; },
]} />"
>
  Asset Designer is the guided flow where you configure and launch a tokenized instrument. DALP 3.0 ships a template library across six asset classes: bonds, equities, funds, real assets, cash instruments, and structured products. Each template carries the full configuration a launch needs: the asset class, the token features, the safe defaults, and the metadata fields to collect at issuance. Your organization's templates sit right beside ours in the same library.
</Spotlight>

## Why every launch used to start from scratch [#why-every-launch-used-to-start-from-scratch]

<BeforeAfter
  before="{
  title: &#x22;Before templates&#x22;,
  points: [
    &#x22;Every instrument launch started from a blank form in Asset Designer.&#x22;,
    &#x22;Which token features to enable, which defaults are safe, which fields a reviewer needs: that knowledge lived in someone's head.&#x22;,
    &#x22;A new team member setting up a bond had to get it right from memory or ask an expert.&#x22;,
    &#x22;Each launch was an opportunity to configure something inconsistently.&#x22;,
  ],
}"
  after="{
  title: &#x22;With asset templates&#x22;,
  points: [
    &#x22;Clone the closest template and you start from a proven, complete setup.&#x22;,
    &#x22;Token features, safe defaults, and required metadata fields are already set.&#x22;,
    &#x22;You expose only the parameters an operator should decide at issuance. Everything else is locked in.&#x22;,
    &#x22;Prerequisite and compatibility checks catch a broken or conflicting setup before anything is created.&#x22;,
  ],
}"
/>

## From clone to your own standard [#from-clone-to-your-own-standard]

The real cost of configuration drift is not that a form gets filled in wrong. The error stays invisible until something downstream breaks. A bond that launches without the right fee configuration and compliance hooks will behave correctly on-chain while producing records that do not match what the servicer expects. Templates encode the decision once, at the point where the product team designed it, and propagate it forward to every subsequent issuance.

<Pipeline
  caption="One path from proven template to your institution's standard: no blank form, no configuration archaeology."
  stages="[
  { title: &#x22;Clone&#x22;, detail: &#x22;Start from any template in the library, ours or one your organization has already published.&#x22; },
  { title: &#x22;Reshape&#x22;, detail: &#x22;Adjust the token features, expose only the fields an operator sets at issuance, and set the defaults that reflect your product.&#x22; },
  { title: &#x22;Launch&#x22;, detail: &#x22;Asset Designer runs the same prerequisite and compatibility checks regardless of the source template. A real, fully-configured instrument is created.&#x22; },
  { title: &#x22;Publish&#x22;, detail: &#x22;Your version joins the library alongside the standard ones. The next launch starts from your standard, not a blank form.&#x22; },
]"
/>

## What standardization means at volume [#what-standardization-means-at-volume]

Institutions moving from pilot tokenization programs to production issuance at volume run into the same friction: each new instrument type requires rebuilding decisions that were already made for the last one. The yield feature that belongs on a fixed-rate note but not a floating one. The metadata fields a custodian needs to reconcile. The compliance controls that differ between a retail fund and an institutional one. That friction compounds with team size. A single experienced issuer carries those decisions in their head. A team of ten cannot, and the inconsistencies show up in the ledger.

Templates are how that knowledge moves from heads to the platform. The product team that knows exactly how a green bond should be configured defines it once. Every subsequent green bond launch starts from that definition. When the configuration changes, it changes in the template and propagates forward; it does not require tracking down every team member who might remember the old way.

Mature software organizations apply the same logic to infrastructure: you do not provision a database from scratch each time; you start from a baseline that encodes your decisions. Instrument templates bring that baseline discipline to regulated asset issuance.

## The standard under every template [#the-standard-under-every-template]

Every instrument Asset Designer launches, regardless of which template it starts from, is a tokenized security built on ERC-3643: the open Ethereum standard for regulated, permissioned tokens. ERC-3643 extends ERC-20, the foundational fungible-token interface that underpins the on-chain asset economy, by adding the identity verification and programmable compliance rules that ERC-20 alone does not provide. The result is a security that any ERC-20-compatible system can read and hold balances for, while transfer eligibility is governed by on-chain logic rather than off-chain promises.

What ERC-3643 adds over plain ERC-20 is a mandatory identity registry and a modular compliance contract, both linked directly to the token. Before a transfer executes, the standard requires that the recipient address be verified in the registry and that all active rules pass. That check is not a wrapper or a middleware layer: the transfer logic inside the contract enforces it, at the contract level, visible to any party reading the ledger. For tokenized securities across bonds, equities, funds, and structured products, this makes the permissioned model auditable, deterministic, and portable across custodians, exchanges, and secondary-market venues that support the standard.

Our ERC-3643 implementation is built on OpenZeppelin's audited ERC-20 primitives. We do not depend on a third-party token framework or a proprietary runtime. The token contract inherits directly from OpenZeppelin's ERC-20 base and adds the ERC-3643 identity and compliance layer on top. Every regulated asset issued on DALP benefits from the same audited foundation, our own implementation decisions, and the open interface guarantee the standard itself provides. No proprietary lock-in exists at the token layer: the on-chain asset conforms to a public Ethereum specification, not a vendor-specific extension.

When you clone a template and launch an instrument, the resulting tokenized security is portable and independently auditable. A custodian, compliance tool, or secondary-market venue that supports ERC-3643 and ERC-20 can interact with it without a DALP-specific integration. An auditor can verify the identity checks and transfer rules by reading the deployed contracts directly, without translation.

## The standard library and your own [#the-standard-library-and-your-own]

DALP 3.0 ships a library of instrument templates across six asset classes. Each one launches a real, fully-configured product today. Your institution's templates live in the same library, so the next team to issue a commercial paper or a private equity fund sees your organization's standard, not a blank page.

<LabelCards>
  <LabelCard label="Fixed income">
    Corporate Bond · Sovereign Bond · Green Bond · Commercial Paper · Convertible Note · Syndicated Loan · Treasury Bill.
  </LabelCard>

  <LabelCard label="Equity">
    Common Equity · Preferred Equity · Employee Equity Award.
  </LabelCard>

  <LabelCard label="Funds">
    ETF · Mutual Fund · Money Market Fund · Private Equity Fund.
  </LabelCard>

  <LabelCard label="Real assets">
    Commercial Real Estate · Precious Metals · Carbon Credit · Tokenized Art.
  </LabelCard>

  <LabelCard label="Cash">
    Certificate of Deposit · Fiat-Backed Stablecoin · Tokenized Bank Deposit.
  </LabelCard>

  <LabelCard label="Structured">
    Principal-Protected Note · Autocallable Note · Asset-Backed Token.
  </LabelCard>
</LabelCards>

![Instrument templates list](/docs/screenshots/settings/instrument-templates/0-instrument-templates-page.webp)

## What a template carries [#what-a-template-carries]

A template is not a saved form in the usual sense: the configuration it holds is an assertion about what the correct instrument setup for an asset class looks like. When an operations team reviews a launch, they review the template's definition, not a memory checklist maintained elsewhere. That difference matters to an auditor: the template is the documented standard, and the launched instrument is evidence that the standard was followed.

A template captures everything Asset Designer needs to launch a class of asset. The asset class determines which token features are available and which are required. The token features set the exact on-chain capabilities the instrument launches with. Default configuration gives the issuer safe starting values for each parameter they control. Metadata fields define what to collect at issuance, scoped to that instrument class.

When you clone a template and reshape it, all four dimensions travel with your version. The next operator who launches from that template gets your standard, not a blank form.

Configurable feature settings are controlled at the individual setting level. 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. The operator only sees the decisions that are still theirs to make.

<Callout title="Checks before anything is created">
  Asset Designer runs prerequisite and compatibility checks on every launch, regardless of whether it started from a template or a blank form. A conflicting or incomplete configuration is caught before the instrument is created, not after.
</Callout>

[Set up instrument templates →](/docs/operators/asset-creation/instrument-templates)