One definition splits into what the template fixes and what the issuer fills in, and both feed the one deployment that puts the instrument on the ledger.
An issuer completes only the settings a template leaves open. The template has already fixed every other setting for the whole family.
The Platform API applies the template on every create, so an instrument created through the platform starts with exactly the behaviours its template required.
Later template edits do not rewrite an issued instrument's on-chain configuration. Catalogue names and classification can still change through the template link.
Why instrument templates matter
An instrument template lets a team approve a product shape once, then issue every bond, fund share, or note built to that shape by filling in only the fields it leaves open. A template is the reusable definition behind a product shape. It lets the platform support a whole catalogue of instruments without a new smart contract for each one.
That changes what a new product costs. A new shape needs configuration, not new code, whenever the platform's existing behaviours, fact fields, and compliance modules already cover what it requires. Thirty-six shapes ship with the platform already, listed in the platform's template catalogue. They sit in seven of the nine asset classes the platform ships, the economic categories a template belongs to: fixed income, equity, funds, cash, real assets, digital assets and structured products. The other two classes, derivatives and yield instruments, ship with no template of their own and accept equity-based templates. An issuer who needs a variant copies the closest one and adjusts it.
The second effect is consistency inside a family. Where a desk re-decides the shape at each issuance, two of its bonds can differ in what they record and what they permit, and a reviewer has to read both. A template makes the whole family answer one definition.
A template sets which pricing fields an instrument carries, and the issuer sets what those fields say. A template creates nothing by itself: an issuer selects it, and the instrument exists only once someone issues from it.
Why a template works through one shared contract
The alternative to a template is a new contract for every product line, each with its own review and its own chance to drift from what the last one promised. That path multiplies two things a control function has to track: the code under review, and the number of places the same rule can end up applied differently.
A template is a definition, not a contract. Every instrument the platform issues runs on the same Composable Token, the one configurable asset contract behind every product. A template is what configures it: which facts it records, which behaviours it runs, and which compliance rules govern its transfers. A behaviour is what the Console and the API call a token feature. Asset Lifecycle names this the design stage, the step before anything is issued where the class, template, facts, behaviour, and transfer rules are all decided together. A template is what makes that decision repeatable across a whole family instead of a one-off review for every instrument in it.
Working with templates day to day
Day to day, an instrument template is an entry in a list your organisation curates. Each template is a draft, published, or unpublished in your organisation, and the issuance flow offers the published ones. A Permission manager, System manager, or Asset designer in your organisation creates, edits, publishes and deletes templates. Three templates that ship with the platform start published in every organisation: Common Equity, Corporate Bond, and Fiat-Backed Stablecoin. Every other shipped template starts unpublished until your organisation publishes it. You can publish and unpublish the shipped templates, but you cannot change them. Anything you want to change starts as a copy, and that copy stays a draft until you publish it.
The draft is where the work happens. You pick the asset class, choose the behaviours the product needs, add the facts the instrument must record, and decide setting by setting what stays fixed and what the issuer fills in. You can fix the fee recipient while leaving the fee rate open. The platform refuses to publish a template while a behaviour you selected is still incompletely configured, and it names the setting it is waiting on, so a half-built shape never reaches the issuance flow.
The rule that decides which side a setting belongs on is what letting it vary would cost the family. Fix a setting when every instrument in the family must answer it the same way. That is what makes the family stand for one approved shape. Leave a setting open when the value differs per issuance, where a near-duplicate template for every variant would cost more than trusting the issuer to fill it in. The fee recipient is worth fixing because the desk's revenue always resolves to the same account whichever instrument earns it. The fee rate is worth leaving open because each deal negotiates its own number. The template only guarantees that a rate exists.
The template decides four things outright.
The asset class decides where an operator finds the template. The base asset type is the instrument family the template deploys, such as bond, equity, fund or deposit, and it fixes which pricing fields the instrument carries. The required behaviour list is what the instrument gets exactly as published, because publishing checks for a missing dependency and for a conflicting pair before it lets the list stand. The instrument-fact schema marks each field required, which blocks creation until the issuer fills it, and separately marks it immutable, which locks the value the moment the instrument deploys.
Three things stay for the issuer to complete at creation.
Every fact value the template requires, with an immutable one locking on the ledger the moment the instrument deploys. Whichever behaviour settings the template left open arrive as inputs in the creation flow, while the settings the template fixed travel with every instrument unchanged. Compliance sits between the two: the template supplies a starting rule set, the issuer completes it at the compliance step, and what results becomes the instrument's opening transfer controls.
Publishing puts the template into the issuance flow, and a published template never returns to draft. Unpublishing takes it out of the issuance flow for your organisation without making it a draft, so publishing it again needs no second readiness check. A template that a published instrument structure uses cannot be unpublished until the structure is. Creating an instrument then means selecting the template and completing what it left open, and the flow stops at any required fact still empty.
A template moves from copy to draft to published in one direction, and a published template never returns to draft.
Three controls decide what your operators see. Unpublishing, hiding a template and hiding an asset class remove nothing. Unpublishing is what you do to a template your organisation does not offer, shipped or your own: it drops out of your picker and stays available to every other organisation, because the shipped catalogue is common to all organisations and each one keeps its own published state. Your own templates were never visible to another organisation in the first place. Hiding a template also keeps it out of the picker, whatever its published state. Hiding a whole asset class takes its templates out of the step where an operator picks a class, and instruments already created from anything you hide keep working. Deletion reaches only a template with no instruments behind it, because the link each instrument keeps to its template holds the definition in place. A delete against a template with issued instruments is refused with DALP-181131, and a delete against a template that belongs to an instrument structure is refused with DALP-14383.
You can still edit your own published template: its name, its base asset type, the facts it collects, the behaviours it attaches, the compliance rules it points at. One thing never changes after creation: the slug, the identifier the platform derives from the first name. Once instruments have been issued from the template, the storage and mutability of its fact fields lock as well.
How a template is put together
An instrument template sits between the asset class an operator browses and the instrument that ends up on the ledger. A template is a stored definition. It binds the asset class, the base asset type, an instrument-fact schema, a required behaviour list, and an optional compliance template, and that binding is what makes selecting a template enough to issue. The fact schema names each field and its type, from plain text and dates through to the identifiers a securities record needs, such as ISIN, LEI, CUSIP and FIGI. It also marks each field: an identifier or an issue date locks permanently at issue, while a servicing detail such as an auditor or an appraiser stays editable under permission. The behaviour list draws on the platform's own set of on-chain capabilities: maturity redemption, yield distribution, fee accounting, conversion, signed approvals. The token features catalogue lists each feature, its parameters, and who operates it. The compliance template is a reusable rule set the issuance flow starts from.
Scope has two levels. Platform templates carry no owner and every organisation sees them, while an organisation's own templates stay visible only to it. A structure of two templates issues one multi-class instrument, such as the Dual-Class Share Structure that the distribution waterfall pays: a controlling class, sponsor-held and carrying control, paired with an economic class, investor-held and carrying the cash flows and the secondary trading. The pairing says which templates belong together and nothing about compliance. Each class keeps its own rules, because the investor class needs eligibility and transfer-approval checks the sponsor class has no use for.
At issuance the platform reads the definition once and then steps out of the way. The instrument keeps a record naming the template it came from, which is how a portfolio groups by product shape. That record is provenance. The ledger holds the behaviours and the locked facts from the moment of creation, and editing the template afterwards does not reach them.
The integration contract
On the API, an instrument template is a settings resource you list, read, create, update, publish and unpublish through the template endpoints in the API reference. Every call that creates a composable asset must name one, and a create that names no template is rejected outright (DALP-0316). Whatever your client did with the template, the server reads it again and applies it.
Three rules follow. First, the new instrument gets exactly the template's required behaviour list. A template cannot be saved or published while a required behaviour's own dependency is missing or two of its behaviours conflict (DALP-14094), so the list a create reads is already complete before deployment starts. Configuration you send for a behaviour outside that list is dropped, and the create still succeeds without it. A create call therefore cannot add a capability the published shape does not carry, though the token's governance role can attach one afterwards through the feature endpoints. The conflict check reads every key you send, including the ones about to be dropped. If you send configuration for a behaviour that conflicts with a required one, the create is refused for that pair (DALP-0605) and the configuration is not dropped silently. Read the created instrument back to confirm which behaviours attached.
Second, the template overwrites a fixed setting with its own value, and supplies that value when your request omitted it. This stops an SDK call from issuing an unapproved variant. A setting the template leaves open but marks required must reach the server, or the create fails (DALP-9175).
Third, the deployment stamps on-chain facts the template marks immutable as immutable on the token, and the token then refuses a later edit. For an immutable fact stored off chain, the Platform API refuses the edit.
Reading an instrument back returns the template it came from, by identifier and by name, so an integration groups holdings by product shape without keeping its own mapping. A template read resolves the platform catalogue plus your own organisation's templates, and never another organisation's. The identifier is unique across the platform. The name is unique inside the organisation that owns it, and creating a template with a name already in use inside that organisation is refused (DALP-0463).
A template read also tells you whether the template is still a draft and, in isPublished, whether the calling organisation has it published. The issuance flow offers published templates only. The platform enforces the same rule on the API: a create or an issuance run that names an unpublished template is rejected with a non-retryable conflict (DALP-14019 for a create, DALP-14020 for an issuance run). Publish the template through the publish endpoint first.
Controls and evidence
For a control function, an instrument template is the artifact under review. The template is where a product shape wins approval: what the instrument must record, what it may do on the ledger, and which transfer rules it starts from. Review the fixed template settings once, then review each issuance's open values and legal terms under the issuer's own process.
Three platform refusals keep the reviewed shape intact up to issuance. No user can edit or delete the catalogue that ships with the platform, only copy it, though a platform release can change it, so each adjustment your organisation makes stands as its own named template with its own author and timestamps, and the shipped definition stays available for comparison. A template stays a draft until someone publishes it, and the platform refuses to publish one whose behaviours are not fully configured (DALP-14345), so what reaches the issuance flow is a finished definition. Once instruments exist, the platform also refuses to change where a fact field is stored or whether its value may change (DALP-12114), so the facts a live family records keep their rules. After issuance, review the token's role holders as well as the template. The governance role can change the instrument's features, compliance rules and identity claims, and a system manager can upgrade the code every Composable Token runs.
The evidence runs in both directions. From a template you reach every instrument an issuer created from it, because each instrument stores that link. You can delete a template with nothing behind it, but never one with live instruments, so the definition behind a live instrument stays retrievable. From an instrument you reach its template and see which recorded facts it declared immutable. The token refuses an edit to an immutable on-chain fact from any role, and the Platform API refuses an edit to an immutable off-chain fact.
Paired templates keep their compliance rules apart. Where two classes of one instrument arrive as a single declaration, each class keeps its own rule set. A controlling class and an economic class carry different restrictions, and copying one onto the other is the error the separation prevents.
Frequently asked questions
Is an instrument template a smart contract?
No. A template is a stored definition the platform reads at issuance. What deploys is one generic asset contract, which the platform configures from that definition, so a product shape supported by the existing capabilities needs configuration instead of a new token implementation. Review the configuration and legal terms before issuance. The template decides the configuration and never runs on the ledger itself.
How does an instrument template differ from a compliance template?
The two work together. An instrument template describes the product: its asset class, the facts it records, and the on-chain behaviours it carries. A compliance template describes the rules a product follows: which controls apply, in which jurisdictions, and which of them an issuer may still adjust. An instrument template can point at one compliance template, so both arrive together when an issuer picks the product shape.
What happens when a live family needs a shape change the template cannot make?
A shape change is either an edit a published template accepts or an edit it refuses. Adding a fact, adding or removing a behaviour, changing the base asset type, or pointing at a different compliance template are all edits a published template still accepts, and each reaches every instrument created from it after that point. Nothing already issued moves. Once instruments exist, two edits are refused: moving a fact field between on-chain and off-chain storage, and changing whether its value may change. When the family needs one of those, or when the old and new shapes should stay apart, publish a new template instead of editing the old one into it. The two versions then coexist, and an issuer picks the one that matches what they are creating. Every existing instrument keeps pointing at the template it deployed from, so the old and new shapes stay visible as separate definitions.
What if the catalogue has no matching shape?
You can copy the closest template and adjust it, which keeps the parts that already fit and is the shorter route to a variant of a shape the catalogue carries. Or you can start from a blank template and configure it yourself, which suits a product unlike anything shipped. Both paths produce an ordinary organisation template that goes through the same draft and publish steps.
Who can create and publish templates?
Only a Permission manager, System manager, or Asset designer in your organisation can create, edit, publish or delete a template. Issuing an instrument from a published template needs the Asset manager role, so the decision about a product's shape can sit with a different person from the decision to bring one to market.