Skip to main content

DALP 3.2: run the instrument from issuance to trading

DALP 3.2.0, dated 11 November 2026, runs an instrument for its whole life, from issuance to trading, on the deployment you choose.

Minting a token is easy. Running the instrument is the work.

Creating the token is one step. Running the instrument lasts its whole life: the first sale to eligible investors, coupons and dividends, splits and holder votes, a secondary market, cash that has to match the bank, and the filings a regulator expects on its own calendar. Where those steps run on spreadsheets and registers re-keyed between systems, a regulated institution reconciles by hand, pays for errors and refunds, and cannot show who acted on whose authority.

DALP 3.2 runs the instrument from issuance to trading on the deployment you choose: corporate actions on the live token, offerings that take money only from eligible investors, a compliant venue you operate, and an assistant that drafts while your team decides. Your institution keeps the legal terms, the cash and the decisions. An agent acts only inside an on-chain mandate your organisation owner sets, which lists the calls it may make, caps its transfer and approval amounts per transaction and per period, and expires. A mandate does not cap the size of a mint or burn. Managed keys stay with the custodian or key store you choose, and on an instance SettleMint operates, SettleMint runs the platform key store.

The four stages of an instrument and the four pillars under them.An instrument moves through four stages: issuance, lifecycle management, primary offering and secondary trading. Under every stage run four shared pillars: integration and operations, control and security, deployment and operations, and the assistant. Each stage draws on the same identity checks, compliance rules, approval policy and audit trail, and an organisation turns each approval rule on for itself.The four stages of an instrument and the four pillars under them.An instrument moves through four stages: issuance, lifecycle management, primary offering and secondary trading. Under every stage run four shared pillars: integration and operations, control and security, deployment and operations, and the assistant. Each stage draws on the same identity checks, compliance rules, approval policy and audit trail, and an organisation turns each approval rule on for itself.

Four stages carry an instrument from issuance to trading, and four shared pillars run under every stage on one audit trail.

Release date: 11 November 2026. In this release the Bloomberg and LSEG price requests follow each vendor's documentation and have not run against the live services. The release changes the SDK and both API versions, so operators and integrators start an upgrade from Compatibility.

Issuance

Your organisation decides which instrument templates its issuers may use, and for an asset issued with balance history it can answer who held a security on a record date, down to the owners behind a nominee.

  1. Design and issue your own instrument types

    Issue from the templates your organisation published, two new sukuk among them, and read the holder register at a record date, reconciled against total supply and looked through to the owners behind a nominee.

Lifecycle management

Your team can split, buy back, pay income and put resolutions to holders on the token investors already hold, with one holder history through every event.

  1. Run corporate actions on the live token

    Review every holder's change before anything mints or burns, pay income from a treasury you fund, and execute a resolution holders passed on the token after a timelock.

Primary offering

Your institution can place a new issue only with investors the token's own rules admit, and settle a fund's dealing days at its NAV.

  1. Place new issues only with eligible investors

    A purchase the token's compliance rules refuse takes no money, and a raise that misses its minimum keeps every refund owed in the contract. Book-built offerings add a greenshoe and lock-ups by investor category.

Secondary trading

You can open a venue you operate, where a trade delivers only when each token's compliance rules allow it.

  1. Open a compliant venue to trade and distribute your assets

    Run order books, auctions and a trading calendar on a venue you operate, and send your surveillance provider a copy of every order and trade over FIX, the Financial Information eXchange protocol. DALP does not bring liquidity to a venue, and reversing a busted trade is a forced transfer, which skips the transfer rules by design.

Integration and operations

Your back office and data vendors work from the records DALP keeps, your systems get signed, ordered events as records settle, and your clients work in a portal under your brand.

  1. Build on one stable API and a generated SDK

    Build on a v2 API whose breaking changes ship only on a new API version, with a TypeScript SDK generated from the platform's public routes and webhooks delivered in order to each endpoint. The payloads of the event families 3.2 adds, apart from gas funding requirements, are beta and can still change inside v2. Connect your own Xero app, and DALP posts each final money event your rules map as a manual journal, once, while your organisation's owner sees every posting in the Console and retries one that failed.

  2. Move bank money and tokens together

    Mint once for each credit your bank confirms over its own FIX session, pay redemptions only to bank accounts a second Bank rail manager approved, and see when the bank balance and the token supply disagree.

  3. Publish checked provider prices to your tokens' price feeds

    Provider prices reach your tokens' price feeds only after the platform checks them, and with the Prices approval rule on, a move past its tolerance waits for a second approver. The Bloomberg and LSEG requests follow each vendor's public documentation and have not run against the live services.

  4. Give your team one inbox and clients a branded portal

    Your team starts from a ranked Dashboard and one Actions inbox, and your clients get the Investor portal, a separate app in your theme, on your domain and in ten languages.

Control and security

Your institution decides who holds the keys and which changes need a second person, and can show a regulator who acted, in which role and with what outcome.

  1. Hold and sign with the custodian and controls you choose

    Give each client a custody gateway to deposit and withdraw through, close each custody day against the chain, and choose embedded wallets, Utila custody or multisig shared accounts alongside the custody you already run.

  2. Generate the filings you owe and prove who approved them

    Generate each filing from platform data on the schedule your published obligations set, with someone other than its maker approving it. Keep one audit trail of the person, their role and the outcome of each change made through the Platform API, send clients their statements, and put a second approver on the changes your policy names.

Deployment and operations

DALP runs in your own Kubernetes or OpenShift cluster, air-gapped where you need it, or on an instance SettleMint operates, and one organisation can work across several networks. On an instance SettleMint operates, a platform administrator may be SettleMint staff. Features that call an outside service, such as the assistant, Ask AI, embedded wallets and vendor price sources, need that access allowed.

  1. Run several networks and recover stuck transactions

    Run one organisation on several networks, manage from the Console the node endpoints behind Ledger Data, the platform's queryable copy of each network's chain data, and recover a stuck transaction or hold it for a person after recovery asks every configured endpoint about it.

Assistant

Your team gets drafts prepared from the data each member can already read. Every write waits for a member's signature, or runs as an agent inside the on-chain mandate the organisation owner sets and can revoke, which caps transfer and approval amounts and does not cap a mint or burn.

  1. Let the assistant draft while your team decides

    Ask the Console about the page you are on and get a filled-in draft to check and sign, while watchers an owner switches on post what needs attention to the Actions inbox. Once a provider key is set, questions and the records they cite go to an outside model provider, documents included unless an owner chooses Mask.

Who it is for

  • Banks that want tokenised deposits, bonds and funds serviced inside their own controls, with managed keys at the custodian they chose and a second approver on the actions their policy names.
  • Exchanges, CSDs and market infrastructures that need corporate actions on the live token, book-built offerings with a greenshoe and category lock-ups, a venue they operate, FIX drop copy and a register that reconciles at a record date.
  • Regulators and the teams that answer them, who get compliance enforced on each ordinary transfer of the token, with forced transfer and the compliance bypass list named as its exceptions, an audit trail of who acted in which role, and filings generated from platform data.
  • Partners that bring core banking, custody or market data, and put DALP next to them as the asset leg through the v2 API and its SDK.
  • Existing customers, who read Compatibility before they upgrade.

Compatibility

You can upgrade to 3.2 from 3.1 or directly from 3.0. Operators follow Upgrade a deployment to DALP 3.2, and integrators follow Upgrade an integration to DALP 3.2. Both guides hold every step. The operator is whoever runs the deployment: your platform team, or SettleMint on an instance it operates.

Before the upgrade, operators plan for these:

  • Which steps apply. A deployment on 3.1.19 or later takes every step in the guide. One on an earlier 3.1 patch also decides on the original asset families and, before 3.1.12, on Fireblocks Gas Station, and one on 3.0 takes the 3.1 steps a direct upgrade skips, as Which steps apply to you lists.
  • In-flight work. Workflows still running on 3.1 do not continue on 3.2, so let every transaction request, issuance run, corporate action run, invitation and identity recovery finish first, as Finish in-flight work describes.
  • A backup first. A Helm rollback leaves the database migrated, so take a database backup before the upgrade, as Take a recovery point describes.
  • A maintenance window. The upgrade replaces the Platform API's services in one step, so plan a maintenance window rather than a rolling upgrade, as Run the Helm upgrade describes. The Platform API answers again once the new pods are ready, and the guide gives the window no fixed length, so size it on a rehearsal.
  • Values the 3.2 chart ignores. The 3.2 chart does not reject a 3.1 values key it no longer reads, and it deploys no RPC gateway, so each network takes its node endpoints directly. Move those values first, as Move your values to the 3.2 chart lists.
  • Ripple custody. DALP renames the operation names it sends on Ripple intents, so an organisation on Ripple custody updates its policies first, as Update Ripple policies describes and the Ripple policy reference lists.
  • Fireblocks signing. 3.2 refuses Raw signing by default and tags the vaults it creates, so check your Fireblocks policy first, as Update Fireblocks settings describes.
  • The custody provider check. With account abstraction on, the pods do not start unless the platform's custody provider can sign user operations on each enabled network, as Check that the custody provider signs user operations describes.
  • The custody census. The migration records which custodian holds each existing wallet and stops on a wallet it cannot place, as Prepare the custody census describes.
  • Which capabilities run. After the upgrade every organisation can run offerings, where 3.1 shipped them off, and the same decision covers corporate actions and dividends, as Decide on the offerings surfaces describes. Secondary trading, regulatory reporting with the holder register exports, and the FIX drop copy to a surveillance provider run only once the operator switches them on, so decide which capabilities your deployment runs, with every default in the deployment reference.
  • The assistant and Ask AI. No question leaves the deployment for a model provider until a provider key is set, and the platform key also turns on Ask AI on the documentation site for anyone who can reach it, so decide whether to share the key, give Ask AI its own key or keep Ask AI off, as Decide on Ask AI and Ask AI provider key describe.
  • The original asset families. 3.2 refuses new assets in the seven original families unless the operator allows them, as Decide on legacy asset creation describes.
  • The index rebuild. DALP rebuilds its data for each network after the upgrade, and reads keep answering from the existing data until it has caught up, as Watch the index rebuild describes.

Integrators plan for these:

  • The TypeScript SDK breaks. Code written against the 3.1 SDK does not compile unchanged, as The TypeScript SDK and the SDK migration guide describe.
  • 187 v2 operations are removed. 145 of them have a successor and 42 have none, and Removed v2 operations lists each one.
  • Error bodies drop defined on v1 and v2, so identify a failure by data.id, as Error bodies drop defined describes.
  • The CLI is verb-first, so dalp contacts list becomes dalp get contacts, as The CLI describes.
  • Some v2 requests require new fields and some response rows changed shape, as Required fields added to v2 requests lists.
  • Existing operations gain new refusals, among them mint and burn during a corporate action and issuance from an unpublished template, as New refusals on existing operations lists.
  • The v1 API changes too. 3.2 removes three v1 operations, v1 user reads drop their single-wallet fields, and a v1 write is refused where an organisation holds its v2 route under maker-checker, as Removed v1 operations describes.
  • Venue event reads name only the caller's own side of a trade a venue settled, unless the caller operates the venue, as Trading venue reads describes.

The platform upgrade does not change the contracts an organisation runs on chain. Each organisation runs System updates on each network when it wants the 3.2 contracts, and until it does, the token features and contracts that 3.2 adds are not on its system.

Was this page helpful?