Instrument Templates
An Instrument Template lets an issuer configure a new instrument from an approved shape, instead of re-deciding what it records, does, and permits each time.
One definition, split into what the template fixes and what the issuer fills in. Both sides feed the one deployment that puts the instrument on the ledger, and the instrument keeps only a record of where it came from.
An issuer completes only the settings a template leaves open. Every other setting the template already fixed, for the whole family.
The platform enforces the template on every create: an instrument gets exactly the behaviours its template required, even from a direct API call.
Later template edits do not rewrite an issued instrument's on-chain configuration. Catalog 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. It is the reusable definition behind that shape, and it is what lets the platform support a whole catalog of instruments without commissioning 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-three shapes ship with the platform already, listed in the platform's template catalog, across seven business classes, which the platform itself calls asset classesAn Asset Class groups instrument templates by economic category for catalog navigation and exposure reporting.Read the concept: fixed income, equity, funds, cash, real assets, digital assets and structured products. 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 decides the shape, never the deal. It settles which pricing fields an instrument carries, not what those fields say, and it 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 avoids that path by staying a definition, never 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. 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. Three templates that ship with the platform start published in every organisation: Equity, Bond, and 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 business 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.
Getting that split right is the whole of the drafting work. 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, because that is what makes the family stand for one approved shape rather than for whatever the next issuer decides. Leave a setting open when the value is legitimately different per issuance, so publishing 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 regardless of which instrument earns it. The fee rate is worth leaving open because each deal negotiates its own number, and the template only needs to guarantee that a rate exists, not what it is.
The template decides four things outright.
The business class decides where an operator finds the template. The deployable type, settled at publication, fixes which behaviour the generic asset contract deploys with, and so 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. Creating an instrument then means selecting the template and completing what it left open, and the flow stops at any required fact still empty.
Copy, draft, publish, in one direction. What reaches the issuance flow is a finished definition, and the deployable type behind it never changes again.
Three controls decide what your operators see, and none deletes anything. 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 catalog 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 business 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 attempt against a template with instruments still behind it fails without a distinct error to catch, so read the template's linked instruments first, the way Controls and evidence describes, and only delete once none remain.
You can still edit your own published template: its name, the facts it collects, the behaviours it attaches, the compliance rules it points at. One thing is settled at publication: the deployable type, meaning which contract behaviour the platform deploys for this shape, and with it the pricing fields the instrument carries. Nothing else locks.
How a template is put together
An Instrument Template sits between the business class an operator browses and the instrument that ends up on the ledger. A template is a stored definition, neither a contract nor an asset. One definition binds four things, and that binding is what makes selecting a template enough to issue.
The four are the business class, an instrument-fact schema, a required behaviour list, and an optional compliance rule set. 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 catalog lists each feature, its parameters, and who operates it. The compliance pointer names 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. Two templates can also form one multi-class instrument: 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, not a live dependency: 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 assetA Composable Token lets an issuer bring a new regulated instrument to market by configuring facts, features, and rules, not new contract code.Read the concept 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 publish, or be edited once published, while a required behaviour's own dependency is missing (DALP-0477), so the list a create reads is already complete before deployment starts. Configuration you send for a behaviour outside that list is dropped rather than attached, and the create still succeeds without it, so a direct API call cannot add a capability the published shape does not carry. The conflict check reads every key you send, including the ones about to be dropped. Send configuration for a behaviour that conflicts with a required one, and the create is refused for that pair (DALP-0605) instead of the configuration disappearing on its own. 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. That is what stops an SDK call from quietly 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 facts the template marks immutable as immutable on chain. The ledger itself then refuses a later 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 catalog 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. After an upgrade that introduces the published state, this applies to every shipped template except Equity, Bond, and Stablecoin.
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 apply to it. Review the fixed template settings once, then review each issuance's open values and legal terms under the issuer's own process.
The review holds because the platform refuses to bend in three places. Nobody can edit the catalog that ships with the platform, only copy 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-0686), so what reaches the issuance flow is a finished definition. Publication also freezes the deployable type behind a template, so nobody swaps the contract behaviour under a live product family afterwards.
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, and the ledger then holds that line: nobody edits an immutable field after deployment, an administrator included.
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 rather than 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?
They answer different questions and compose rather than replace each other. An instrument template describes the product: its business 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?
Two different things can count as a shape change, and they land differently. Adding a fact, adding or removing a behaviour, or pointing at a different compliance rule set are all edits a published template still accepts, and each reaches every instrument created from it after that point; nothing already issued moves. Changing the deployable type is not on that list: publication freezes it, and no edit reopens it. When the family genuinely needs a different deployable type, publish a new template rather than trying to edit 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 actually deployed from, so the split between the old shape and the new one stays visible instead of hidden inside one drifting definition.
What if the shape we need is not in the catalog?
Two paths. 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 catalog carries. Or 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 an administrator, system manager, or asset designer in your organisation can create, edit, publish or delete a template. Issuing an instrument from a published template needs a separate permission, which keeps the decision about a product's shape apart from the decision to bring one to market.