A corporate action is now a record, not a batch you assemble
Thirteen corporate-action types such as cash dividends and stock splits are recorded objects: enter the terms, read the effect on every holder, then confirm.
The Console records every corporate action with stored terms and an execution record. Supply changes use a reviewed allocation. Recording a cash dividend or distribution already declares it on chain, before Preview or Confirm.
Corporate actions have stored terms and recorded outcomes
A corporate actionA Corporate Action pays a coupon, a dividend, or a matured redemption straight to token holders, turning an issuer's announced terms into an on-chain payout.Read the concept is a lifecycle event on an issued security: the board declares it, and the register changes as a result. The platform now holds each one as its own record from the moment you enter its terms.
- Catalog
- Thirteen corporate-action types in one collection
- Supply changes
- Stored allocation reviewed before Confirm
- In flight
- One supply-changing event per asset
- Abort
- Stops the run and keeps applied holders
What you assembled by hand before
In 3.1, operators combined platform primitives to carry out these events. DALP 3.2 gives the event its own record, preview, and execution state.
A stock split was a balance snapshot, then a batch of mints for the delta, then your own reconciliation of the two. A bonus issue was the same shape with different arithmetic. A rights issue was a token sale restricted to the entitled holders. A spin-off was a new asset plus a pro-rata mint. The platform ran each step correctly. What it did not do was know that the steps belonged to one event.
That gap shows up in the places an issuer feels it. A run that stopped halfway left no object to resume, so you reconstructed where it got to from transaction history. A preview was something you computed yourself, in a spreadsheet, against a snapshot you took separately. And the record that an auditor asks for, the one showing that what was applied matches what was approved, had to be assembled after the fact from the same transaction history.
- The event lived in your process and the primitives lived on the platform.
- You took the snapshot, computed the allocation, submitted the batches, and reconciled the result yourself.
- The event lives on the platform as a record with an identity.
- It computes the allocation, holds it, applies it in order, and reports how far it got.
Thirteen types, four ways of working
The versioned API carries thirteen corporate-action types. The Console lists more entries than types: a stock split appears once forward and once reverse, and a cash dividend, bond coupon, or distribution can be paid in cash or in kind. Paying in kind mints new units, so it runs as a supply change with a reviewed allocation. Behind those names sit four different mechanisms, and knowing which one you are running changes what to expect.
Two declare a distribution. Recording a cash dividend or general distribution declares an amount per unit on chain through the asset's dividend yield feature. This happens before Preview or Confirm. Entitlement comes from the register on the record date.
Three name a program the asset already carries. A bond coupon, a maturity redemption, and a conversion complete the moment you record them. Each is a claim the holder makes against a capability attached to the asset at issue, so there is no batch to push and nothing for a preview to compute.
One pays every class of an instrument. A coordinated distribution is raised on the share class that carries the instrument's distribution waterfall. Once the record date has passed, preview declares one cash dividend per class and shows the split and every class's holder amounts for approval. Confirm funds the waterfall once with the whole pool and records each class's snapshot in rank order, so holders can claim. A class the pool does not reach gets no dividend.
Seven use stored holder allocations. Most apply mints or burns in chunks. A rights issue can instead add entitled holders to an existing token sale whitelist. These actions use the record, preview, confirm, and abort sequence.
| Mechanism | Types |
|---|---|
| Declares a distribution | Cash dividend, distribution |
| Names an attached program | Bond coupon, maturity redemption, conversion |
| Composes a supply change | Bonus issue, rights issue, capital decrease, stock split, spin-off, partial redemption, buyback |
| Pays every class | Coordinated distribution |
Preview before confirming
For the seven composing types, a preview computes the whole allocation and writes none of it. It reads the holder book, works out what each holder receives or loses, and stores that result against the action's record. Nothing has reached a holder yet.
Confirm applies the stored allocation and requires a preview for a composing action. If the remaining holder balances have changed since preview, the platform aborts the run with a snapshot-drift error. The aborted record cannot resume; review any applied holders before starting another action.
Cash dividends and distributions also require preview before Confirm. Preview stores holder allocations and returns the exact root and totals that Confirm must echo. Preview does not submit the allocation on chain; Record has already declared the dividend.
Abort is available from the moment the action is recorded and it fences the chunks that have not started. It does not reach backwards. A holder the run already applied keeps that change exactly as it stands, and there is no reversal. Any corrective action requires a separate authorized instruction. To continue the unapplied part of a composition, create a follow-up record linked with followsUpOn; preview excludes holders already applied in that sequence.
Concurrency and idempotency
The platform enforces concurrency and idempotency when it stores an action.
An asset carries at most one supply-changing event that is not yet completed or aborted. A second attempt to start one is refused while the first is open, so two people cannot run overlapping splits against the same register.
A create carries an idempotency key, the value that identifies one attempt rather than one request, so a retried create returns the record that already exists instead of making a second one. Replaying the same key with a different body is refused rather than quietly accepted.
A confirm that lost its connection converges too. When the record is next read, the platform reconciles it against the durable record of the batches it submitted, so a browser that closed mid-run does not leave the action stuck at a status that no longer describes it.
Compatibility, and one new rejection
The collection is additive. The frozen v1 surface is unchanged, existing v2 routes keep their request and response shapes, and an asset issued before this line is unaffected.
One existing behaviour does change, and an integrator should know the exact failure mode. A primitive mint or burn on an asset is now rejected while a composing corporate action on that asset is not yet completed or aborted. The rejection names itself as a composition being in flight and tells you to wait for it to complete or abort. Another operator or integration can start the action on the same asset, so callers of primitive mint or burn must handle this rejection even if they never create corporate actions themselves. The fix is to finish or abort the open action, then retry.
This release deprecates nothing here. No route, field, or error is being retired, so no removal date applies.
What this still leaves to you
The catalog records the event. It does not decide it, and several judgements stay outside the platform on purpose.
The approval itself lives in your own governance process. Nothing in the sequence records or displays an approval reference, so the link between the board minute and this record is one you keep. A partial redemption adds one check inside the platform: a second owner or admin approves its previewed plan before it runs, as Approve or reject a partial redemption describes.
An announced burn, meaning a capital decrease, a partial redemption, or a buyback, accepts a list of holder addresses and amounts through the API. Use the approved amounts; the platform does not derive a legal pro-rata reduction.
A spin-off mints into a child asset that must already exist and hold no supply. Create the child first; the spin-off will not create it for you.
The API record lists each holder, allocation, state, and any associated transaction hash. A skipped state has no separate reason field. Investigate skipped or remaining holders against the approved allocation and execution evidence.
Availability
The collection runs on the versioned public API and is available to every deployment on this line, with no flag to enable. The same eight operations back the Console surface, so anything you can do from the menu you can do from an integration, except approving or rejecting a partial redemption, which needs a signed-in session.
The API and the Console offer an action from what the asset carries, never from its asset type: its attached features and its instrument capital (share capital for shares, unit capital for fund units and real-estate fractions). A SAFE offers its conversion and no share action, and the Console hides any action the asset cannot run. Permission, pause, and in-flight restrictions disable the relevant entry and show the reason.
Understand corporate actions → · Run one in the Console → · See how income is paid →
Dividend & interest yield
Two token features let an instrument pay income: dividend yield pays a declared amount per unit on a chosen date, and interest yield accrues continuously.
Governance votes
A governance vote asks a token's holders to approve a decision, weighted by holdings on a record date, and a passing vote can execute the change after a delay.