# Structured products Source: https://docs.settlemint.com/docs/business/use-cases/structured-products Use DALP structured instrument templates to govern token issuance, holder controls, and lifecycle events for products whose payoff terms and reserve processes remain outside the platform. Use DALP when your programme needs a governed EVM on-chain record for an instrument whose economics depend on terms outside the contract itself. The structured instrument family covers Principal-Protected Note, Autocallable Note, and Asset-Backed Token patterns. DALP models the issued asset, attaches required token features, enforces holder and transfer restrictions, and exposes event and holder records. Your institution still owns the payoff formula, underlying exposure, reserve or collateral proof, cash settlement, accounting, investor notices, and legal approvals. The routing decision is whether your product should start from a DALP structured template, a fixed-income template, or the Configurable Asset starter. This page does not cover pricing model, term-sheet authoring, regulatory opinion, or reserve attestation. Confirm those decisions before configuring assets in the Console. ## Business challenge [#business-challenge] Structured products combine token-lifecycle control with commercial economics that live in term sheets, calculation-agent processes, reference-asset data feeds, and collateral workflows outside the token. Your platform team needs one place to operate issuance and servicing without pretending the token contract proves the entire instrument. DALP covers: * Instrument templates for structured product starting points. * Metadata fields capture maturity, reference terms, collateral context, and product identifiers. * Token features support maturity, redemption, fees, historical balances, or other configured behaviour where selected. * Compliance modules enforce holder eligibility and transfer checks. * Indexed records covering tokens, holders, transactions, and events support downstream integration and reconciliation. The surrounding institution must still approve and operate the product's economics. For an autocallable note, the observation logic and payoff determination belong to the product and calculation-agent process. For a principal-protected note, principal protection depends on the approved conditions and funding arrangement. For an asset-backed token, DALP can record collateral-related configuration and lifecycle operations. The reserve, warehouse, trustee, custodian, or other independent evidence source must prove the underlying backing. ## How DALP fits structured products [#how-dalp-fits-structured-products] The diagram below shows how approved product terms flow through the platform into on-chain records, and where external processes must connect to close the evidence pack. DALP records and enforces the configured EVM lifecycle. The platform does not replace the product term sheet, calculation agent, pricing source, or market venue. It also does not replace the cash rail, collateral agent, custody provider, legal register, or accounting ledger. Each of those responsibilities belongs to your institution and its appointed counterparties. ## Template routing [#template-routing] The structured family is useful when the product's economics do not fit a plain bond, equity, fund, deposit, stablecoin, or real-asset pattern. Use the table below to match your product to the right starting point before configuring the asset in the Console. | Template | Selection condition | DALP handles | External owner | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Principal-Protected Note | The instrument needs a note-like token with maturity context and approved principal-protection terms. | Asset setup, holder controls, lifecycle operations, maturity or redemption features where configured, and event records. | Principal-protection economics, funding arrangement, payoff calculation, cash settlement, investor disclosures, and accounting. | | Autocallable Note | The instrument depends on observation dates, call conditions, or reference-asset performance outside the token workflow. | Token configuration, eligibility checks, lifecycle records, servicing steps, and integration evidence. | Observation logic, reference data, calculation-agent decisions, cash movement, notices, and dispute handling. | | Asset-Backed Token | The token represents an asset-backed programme where backing evidence must be reconciled outside the token contract. | Token issuance, transfer controls, collateral-related configuration where selected, holder, and event history, and API records. | Asset pool eligibility, reserve or warehouse evidence, custodian or trustee process, valuation, insurance, and reporting. | If the product is simply debt with maturity and coupon-style servicing, start with [Corporate bonds](/docs/business/use-cases/corporate-bonds). If you need a blank or organisation-specific model, start with [Instrument templates](/docs/operators/asset-creation/instrument-templates) and duplicate the closest library entry or create one from scratch. ## Operating model [#operating-model] A structured product programme usually needs these decisions before launch. | Decision | DALP answer | External answer | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Which token pattern should be issued? | Select a structured instrument template or a configurable template, then define the asset identity, metadata, required features, and compliance controls. | Approve the legal instrument, offering terms, payoff method, calculation role, and investor disclosures. | | Who may hold or transfer the token? | Configure roles, identity claims, compliance modules, and transfer controls before issuance and transfer. | Decide eligibility rules, jurisdictional restrictions, suitability checks, exception handling, and investor communication. | | How are payoff or reserve facts proven? | Use metadata, token operations, events, holder views, API reads, reports, and integration records as DALP evidence. | Operate the pricing source, observation process, reserve attestation, collateral inventory, custody records, and accounting evidence. | | How does settlement complete? | Execute token transfers, burns, mints, redemptions, or settlement workflows when the configured EVM rules allow them. | Operate fiat payments, bank-core posting, market venue activity, cash reconciliation, and final client statements. | ## Controls to confirm before implementation [#controls-to-confirm-before-implementation] * Confirm that your target network and token lifecycle are EVM-based. DALP is EVM-only. * Decide whether your product should use a structured template, a fixed-income template, or the Configurable Asset starter. * Define which metadata fields the Asset Designer must collect, which must be immutable, and which can follow the supported metadata update flow. * Select compliance modules and identity claims before relying on secondary transfers. * Assign an external owner for calculation-agent decisions, reserve evidence, custody, payment rails, accounting, and notices to investors. * Connect your external systems to DALP token, holder, transaction, event, webhook, and reporting records for downstream reconciliation. ## Related pages [#related-pages] * [Use cases](/docs/business/use-cases) compares the full template taxonomy. * [Instrument templates](/docs/operators/asset-creation/instrument-templates) explains how templates define asset class, required features, and metadata fields. * [Tokenization modeling](/docs/architects/concepts/tokenization-modeling) describes the split between asset class, token type, token features, and metadata. * [Compliance overview](/docs/compliance-security/security/identity-compliance) covers holder eligibility and transfer checks. * [Operational integration patterns](/docs/api-reference/reference/operational-integration-patterns) shows how external systems consume DALP records.