DALP 3.2: trading, income, and reporting

DALP 3.2 adds secondary trading, income features, corporate actions, and reporting. Review the compatibility notes for SDK migration, new API rejections, and deployment changes.

The release extends asset issuance with trading and servicing operations. The entries describe the scope and limits of each capability.

Trade it where you issued itCopy Anchor Link

Secondary trading no longer has to leave the platform. The Trading Venue gives each deployment its own permissioned order book, meaning a market open only to identity-verified participants. DALP tokens remain reserved in traders' wallets; plain ERC-20 tokens use venue escrow. Token compliance checks still apply. The venue supports trading calendars, opening auctions with a randomised clearing instant, official closing prices, stop orders, price bands, and a dual-approved remedy for busting an erroneous trade without touching settlement finality.

Put the instrument's whole life on the platformCopy Anchor Link

Five capabilities cover what an instrument does before and after it trades. Primary offerings gives the first sale both of its sides: a desk that runs the raise and watches its deadlines, and a portal where investors subscribe and follow their positions. Dividend and interest yield add the two income shapes that were missing, the declared distribution and the continuously accruing rate, each paid from a treasury you fund. Corporate actions provides thirteen Console entries for recording and tracking lifecycle events. Supply changes use stored previews; recording a cash dividend or distribution already declares it on chain. The instrument catalog grows to thirty-three product shapes, adding two sukuk structures under a Shari'ah compliance framework, a class for digital assets, a spot commodity, three venture instruments, and a two-class equity. Compliance controls closes six gaps found by modelling that two-class share structure, including verification claims that can expire and a sanctions rule its subject cannot remove.

Let the holders decideCopy Anchor Link

Governance votes give a token's holders a decision that carries itself out. Weight is read from the register at a record date you set. A vote that passes queues its change on a timelock, and executing it applies the change to the token.

Prove what happenedCopy Anchor Link

Regulatory reporting generates its report families on the schedule your published obligations produce, and records every state-changing and sensitive request as an audit trail naming the person, the role, and the outcome. Weighted multisig lets a participant account require several signers, with weights rather than head counts, so a treasurer's seat can outweigh two junior ones. Transfer pre-check answers whether a transfer would clear before anyone signs it, and names who can resolve each thing standing in the way.

Work you can watchCopy Anchor Link

Live activity replaces the submitted-and-redirected pattern with a tray that reports each operation's real phase, survives a refresh, mirrors across tabs, and offers an undo while nothing has reached the chain yet.

Run it and connect itCopy Anchor Link

Custody adds an embedded wallet, fixes the DFNS integration, and signs smart-account operations in a form a strict provider policy accepts. The network control plane moves endpoint routing into the platform, with pools you manage in the Console, automatic failover away from a lagging endpoint, and an authenticated JSON-RPC endpoint of your own. The same entry carries the choice to run one organisation across more than one chain, which is off unless you turn it on. Index correctness follows blocks by identity so a chain reorganisation cannot mix two competing blocks, isolates a stalled chain from the rest, and refuses a price it cannot publish exactly. Response caching adds conditional reads and waits for indexed visibility before reporting supported writes as complete.

Smaller updatesCopy Anchor Link

Console:

• An investor who holds an asset can read that asset's documents. Documents marked for holders are now visible to any wallet with a verified balance, read only, and management stays with governance.
• Asset documents preview in the browser across PDF, Word, Excel, and CSV files, with the file-integrity check and the download preserved.
• Action lists, dashboard tiles, and the pending-action count update as work lands, over a live stream instead of a polling refresh.
• A held asset shows its unrealised gain or loss as a small inline trend chart, alongside total return and the trailing day's change.
• Table filters count correctly: each filter now excludes only itself when computing its own options, so choosing a value no longer collapses the rest of the menu.
• Charts across insights, portfolio, and platform status are rebuilt: the portfolio value chart no longer fails in bar mode, legends show translated instrument names instead of raw identifiers, and the world map and thirty-day status history are properly interactive.
• The jurisdiction map carries per-country counts and a total.

Platform and integrations:

• Workflows that exhaust their retries against an infrastructure problem now suspend and are retried automatically as capacity returns, and suspended shows as its own state rather than as a failure.
• The documentation is readable by an agent or a crawler: every page is available as plain markdown, the whole corpus as one file, with an index and a search endpoint.

For operators:

• Index catch-up publishes as its own measurements: how far behind the chain the index is running, how old the building copy is, and how much backfill is outstanding.
• Database and pipeline telemetry ship with their own dashboard, and a database metrics exporter is available to turn on.
• The Platform API deploys as three roles that scale independently, serving requests, running background work, and indexing the chain. The merged single-process shape stays supported, and remains the right choice for a smaller deployment.

CompatibilityCopy Anchor Link

The TypeScript SDK has breaking changes, and existing API routes gain new rejection cases. The v1 API stays frozen, existing v2 routes keep their response shapes and every request shape except the flat collection keys below, and new capabilities land as additive routes and Console surfaces that appear only where the capability is deployed.

The v2 API is stable from 3.2. After this release, a breaking change to v2 ships only on a new API version, and an operation is removed only after a deprecation that gives at least 90 days' notice. A deprecated operation answers with the Deprecation, Sunset, and Link headers and is marked deprecated in the OpenAPI contract. Versioning and deprecation states the full policy. GET /api/v2/platform-status/snapshot, deprecated since 21 May 2026, now announces a sunset of 19 August 2026 instead of 30 June 2026, the first date the 90-day window allows. Both dates have passed, so a later release can remove the route; call the data-freshness, transactions, platform-api, workflows, and stat-cards routes under /api/v2/platform-status/ instead. Its deprecation headers now use the standard formats: Deprecation carries the announcement date instead of true, and Link names the policy as well as the successor.

One existing route pair gains a new rejection rather than a new shape. A mint or a burn on an asset is refused while a supply-changing corporate action on that same asset is open, and the refusal names the action holding it. Any integration that mints or burns the asset can receive this rejection, even if another operator started the corporate action. Corporate actions explains the recovery.

v2 collection routes drop the flat keys limit, offset, sortBy, sortDirection, and filters. A route that did not apply them answered with the unfiltered first page instead of an error. They now fail with a 400 that names the key, and the SDK no longer accepts them. Send page[limit], page[offset], sort, and filter[<field>] instead, as Pagination describes.

Ten webhook write routes stop publishing a 202 accepted response: creating, updating and deleting an endpoint, sending a test event, retrying a delivery, replaying, recalling, rotating and revoking a signing secret, and posting a receipt. None of them ever answered 202. Each finishes before it responds and returns 200 with its result, so a client can drop any branch it kept for the accepted shape. A retried POST /api/v2/webhooks that sends the same Idempotency-Key now returns the endpoint the first request registered, with signingSecret set to null, instead of registering a second endpoint with a second secret. The route echoes the key it used in the Idempotency-Key response header, including one the platform generated, so a client that lost the response can replay it. Reusing the key for a different body, or for a registration that never completed, answers 409 WEBHOOK_IDEMPOTENCY_KEY_REUSED. Retrying while the first request is still registering answers 409 WEBHOOK_CREATE_IN_PROGRESS; retry it again shortly.

A paymaster deposit, a paymaster signer rotation and a refund splitter allocation change now answer 202 with a status URL when their transaction has not settled within the request, as their contract already declared. They used to answer 200 with values read before the change landed.

The seven original asset families stop being creatable on a deployment that does not ask for them, which an integration that still issues bonds or funds will notice as a new refusal. Legacy asset creation states both refusals and the single setting that restores them; tokens already issued are untouched.

Instrument templates are offered for issuance only when an organisation publishes them. Equity, Bond, and Stablecoin start published in every organisation, and every other DALP Library template starts unpublished. An integration that creates a token or starts an issuance run from an unpublished template is rejected until the organisation publishes that template. Template publication states the rejections and the remedy; tokens already issued are untouched.

TypeScript SDK lists the required client changes.

Two upgrade actions belong to self-hosting operators rather than to integrators. The Platform API's deployed workloads are renamed as part of the role split, which needs a sequenced cutover rather than a rolling upgrade. And this line rebuilds the index, so plan the upgrade window with that load in mind. The index rebuild is covered on Index correctness.