One record holds the announced terms and the entitlement basis, then routes the event to the instrument capability that owns the money without executing it.
A Corporate Action records an issuer's announced event on the token and hands it to the feature that applies it. A holder claims a coupon or a dividend, or redeems at maturity, from their own wallet. A supply change mints or burns units on each holder's balance. The holder file and the ledger update come from the same record. The institution still keeps the board resolution, the notice and the funding evidence.
The catalogue has thirteen types that work in four ways. A cash dividend and a distribution declare a payout on chain. A bond coupon, a maturity redemption and a conversion name a programme the token already carries. A bonus issue, a rights issue, a capital decrease, a stock split, a spin-off, a partial redemption and a buyback change supply through stored per-holder allocations. A coordinated distribution pays every share class of an instrument from one pool.
The action record links the announced terms and entitlement basis to the resulting on-chain transactions, so a reviewer can trace one to the other.
Why corporate actions need one record
After issuance come years of servicing: paying what was promised, tracking who holds a claim to it, and proving both to a regulator later. Asset Lifecycle places that servicing in its own stage, and a Corporate Action covers most of it. A maturity trigger runs in the optional Retire stage, where an instrument that carries the maturity feature matures, holders redeem at face value, and their positions burn.
A paper process splits a corporate action across separate systems. An issuer's legal notice names who is owed what, a registrar's holder file names who holds the instrument, a payments desk moves the funds, and a ledger records that it happened. Every handoff between them is a reconciliation where the ledger state and the legal record can drift apart. A Corporate Action closes that gap for one kind of event. It connects the announced economics straight to the holders entitled to receive them, so there is no separate holder file or payment instruction to keep in step with the chain.
Why the instrument's own record runs it
The alternative is a corporate-actions process that sits beside the instrument. It keeps its own copy of who holds what, its own funding source and its own record of who was paid. That copy is where the two systems can disagree: the side system computes an entitlement from stale data, and the instrument's own compliance rules would have refused the transfer.
A Corporate Action record keeps no copy of the holder register of its own. A dividend's snapshot is built from the holders' record-date balances and committed on chain as one root, so the entitlement basis is fixed and published. The record coordinates: it does not hold the money, and it does not decide eligibility on its own. Payout features draw from a configured treasury, the wallet or contract that holds the payout asset, and never hold the payout asset themselves. Each route invokes the feature that already owns that economic effect on the instrument itself, whether that effect is a dividend claim, a treasury-yield coupon, a maturity redemption, or a supply operation such as mint, burn, transfer, or token sale. Because the payout runs through the instrument's own contract, the same eligibility registry and transfer rule that govern every other movement of that instrument govern this one too. The identity check a holder already passed to receive the token is the same check that gates their payout.
The platform executes terms that an authorised issuer or agent supplies. It does not decide whether a dividend should be declared, whether an instrument should mature early, or whether the legal notice behind either is valid. Those decisions stay in the issuer's own governance and legal process, outside the platform.
What a Corporate Action does
For most types an operator can read the plan first, which stores nothing. A bond coupon, a maturity redemption, a conversion, and a cash dividend or distribution have no plan until they are recorded. Recording stores the terms: for a cash dividend or a distribution paid in cash it also declares the payout on chain, and for a maturity redemption it matures the bond. Nothing is paid, minted or burned until the reviewed allocation is applied, or until a holder claims or redeems. A plan is the list of mints, burns or payouts per holder that a type would apply. Preview or quote reads it, record stores the terms, and confirm or commit runs it.
The economic result depends on the event. Fixed interest accrues from a configured schedule, and a holder claims it. A cash dividend fixes entitlement from a record-date snapshot and later becomes claimable. Maturity closes ordinary issuance, fixes the supply basis for principal redemption, and lets holders burn positions for the Denomination Asset, the single asset in which the instrument's face value and payouts are stated, at face value. A stock split, a bonus issue, a rights issue, a capital decrease, a spin-off, a partial redemption and a buyback each resolve to a chunked mint or burn against stored per-holder allocations. A rights issue can instead add the entitled holders to the whitelist of an existing token sale.
The corporate actions API guide covers the create, preview, confirm, and abort sequence, and the quote and commit calls that read the plan and run it under one wallet verification. The Console uses the quote and commit for a supply change or a payment in new tokens: the operator reads the plan for every holder first, and one PIN then records the action and runs it. A cash dividend, a distribution paid in cash, and a coordinated distribution keep the record, preview, and confirm steps. One invariant holds across every type: an operator must never treat the announcement step as payment.
A dividend's snapshot is irreversible
For a dividend, the operator declares the ex-date, record date, payment date and claim deadline, the per-share amount, and whether the dividend is regular or special. Each date falls on or after the one before it, and the claim deadline lies in the future. DALP-9206 enforces that order. The dates may coincide, and every date except the claim deadline may lie in the past. A special dividend is a one-off payment. The kind is recorded with the dividend and does not change these checks. A past record date must fall on or after the moment the token's historical balances were enabled, which is what DALP-9294 enforces. The operator then records the holder snapshot, waits until the payment date, and holders submit claims with proof of entitlement. The snapshot is a Merkle root that the platform builds off chain from the holders' record-date balances and a governance-role holder records. The contract does not check the root against balances, so keep the holder list behind each root as evidence.
The snapshot is the step to get right, because a dividend accepts exactly one. It cannot be recorded before the record date has passed, which answers DALP-9212, and a second attempt on the same dividend answers DALP-9213. No operation replaces a recorded snapshot, and cancelling the dividend stops being possible the moment one lands, which answers DALP-9214. An entitlement basis captured against the wrong holder set cannot be corrected in place. What is left is to let the claim deadline pass, reclaim the unclaimed funding, and declare a fresh dividend against a new record date.
A dividend can be cancelled until its snapshot is recorded, and recording the snapshot closes that path.
A payable dividend's claim deadline can be pushed out once, for as long as no reclaim has closed the dividend, to give holders who have not claimed a further window. A second extension on the same dividend is refused. A governance-role holder extends the deadline, cancels before the snapshot and reclaims after the deadline. An emergency-role holder can pause all claims on the dividend feature.
Maturity cannot be undone
Two paths reach the matured state of the maturity redemption feature. The ordinary path is available to the governance role once the scheduled date is reached. It does not mature an instrument whose treasury does not hold face value times the supply outstanding, so redemptions cannot open underfunded on that path. The early path is available to the emergency role, only strictly before the scheduled date, and it skips that solvency check on purpose so an operator can open redemptions during a shortfall. Using it means holders who redeem first are paid in full and later holders may find nothing left. The ordinary path checks solvency once, at the moment of maturity. A treasury drained after maturity does not undo maturity, and later redemptions fail with DALP-12373.
Maturity fixes the aggregate redemption basis: the supply outstanding at that moment becomes the basis for principal redemption. Each holder then redeems separately, and a redemption pays only for the amount burned. That matters when another feature on the instrument rewrites part of a burn as a fee: the holder is then paid for the net burned amount.
A redemption fails before a holder pays gas for a transaction that would revert, and the failures trace back to the treasury's funding and configuration instead of the holder's own position. A holder is not told about the treasury unless the organisation shares redemption funding with holders: a redemption the treasury cannot fund, or one that reverts on chain, answers DALP-12373, which says only that the redemption cannot be completed and carries no treasury address, allowance, or amount. A holder who sees it contacts the issuer. When the organisation shares redemption funding, or the caller manages the token or is its treasury, a redemption the treasury's balance cannot pay answers DALP-14506 and one a wallet treasury has not approved enough for answers DALP-9481, each naming the treasury and the amounts.
The funding diagnosis belongs to the issuer. Read the maturity feature's treasury state and bond status before holders redeem, and approve the full payout the outstanding supply needs instead of the difference, because the standard token approval overwrites the earlier one. An approval sent from any wallet other than the configured treasury answers DALP-9480. The platform's own approve-allowance control signs with the acting wallet, so it works only when that wallet is the configured treasury. For any other treasury contract, the approval has to come from that contract's own admin or governance flow. Before maturity, the treasury can instead be set to a wallet the platform signs for.
A redemption attempted before the instrument has matured answers DALP-9478, and a preflight that runs before the indexed feature state has landed answers DALP-9477 or DALP-9479, both worth retrying instead of treating as a configuration fault. Yield and maturity covers funding and triggering a maturity feature step by step.
Choosing a treasury type
The treasury type is a choice made when the feature is configured, and it changes what an operator does before every payout. An externally owned wallet suits a low-frequency payout that a human signs by hand. A vault suits recurring payouts, or an institution that cannot keep a signing key hot.
Coordinator and capability stay separate
A Corporate Action coordinates, and the instrument's feature executes. Maturity shows that split most clearly. The record schedules the trigger and tracks its outcome. The maturity redemption feature is what matures the instrument.
Two entrances, one terminal state, and a solvency check that only one of the entrances applies.
This separation keeps one source of enforcement: whichever feature owns an event's economic effect is what enforces it, never the record that scheduled the call.
Payout-bearing features share one treasury rule: a feature pulls an approved denomination asset from an externally owned treasury, or delegates payout to a vault that implements its own payout logic. In neither case does the feature custody the denomination asset, which is why an identity-controlled payout asset stays compliant: the feature never needs an identity merely to hold funds.
Paying several share classes from one pool
An instrument with several share classes pays every class from one pool of cash through a distribution waterfall. The waterfall is a vault with a ledger for each class. It holds one balance and tracks how much of that balance each class may draw. A coordinated distribution is the corporate action that funds it: one pool, one record date, and each class paid in rank order.
Two separate cash dividends on two classes would draw on the same money with no shared rule for who comes first. The waterfall puts that rule in one place. Money enters once, when the coordinated distribution funds the pool, and the waterfall splits it into one leg for each class. Money leaves when a holder claims. Each class's dividend feature uses the waterfall as its treasury and draws down only its own class's leg. A class never receives a lump sum. Its leg always reaches holders as per-share dividends, for income and for capital return alike.
The waterfall holds one balance and one counter for each class, a class draws only its own leg, and cash leaves only when a holder claims.
Two modes decide the legs. In ordinary mode, the whole pool goes to the classes with the lowest ordinary rank, split by the capital each class paid in. In priority mode, a determination that a trusted issuer signed names an event, such as a wind-down that the sponsor caused. Each class then recovers the capital it paid in, tier by tier, before the rest follows the ordinary ranks. The two orderings are independent, so a class can rank first for income and second for capital. The distribution waterfall entry lists the terms and works through the numbers.
A coordinated distribution guards the split from preview to payment. Preview declares each class's dividend and takes its holder snapshot. The operator then reviews the split, and when the organisation's Corporate actions approval is on, an organisation owner or platform administrator other than the operator approves it. Confirm computes the split again and reverts before any money moves if it differs from the previewed one, so the platform never pays a split that differs from the preview. Confirm then funds the pool and records each class's snapshot in rank order. Three controls apply: a class can draw only its own leg, a second approver reviews the plan when the organisation has turned that approval on, and only one coordinated distribution can be open on an instrument at a time. Abort is refused while the funding transaction may still land or a class is still being recorded. After the pool is funded, abort keeps the classes already open for claims and cancels the rest.
The integration contract
A Corporate Action integration treats creation, confirmation, holder execution, and reconciliation as distinct states, so it never confuses an announced event with a completed payout or supply change. The action identifier is the durable business key. Transaction references show how its current progress reached the ledger, and integrations read both.
Read the instrument's attached features before presenting an operation. A dividend route requires the dividend feature, scheduled interest requires fixed treasury yield, and principal redemption requires maturity redemption. Validate dates and positive amounts before you send the request, but expect the contract to recheck authorisation, timing, entitlement, available treasury funds, and claim status during execution. One corporate action in progress is allowed per token. A second create attempt while the first is not completed or aborted is refused, and the platform refuses its own mint and burn routes on that token until then. The token contract does not know about the record, so a direct mint or burn by a supply manager still runs.
Use one idempotency key per business instruction. If a response is lost, inspect the recorded operation and corporate-action state before sending another request. Reuse the key for an API retry only when that route documents replay safety. After submission, follow the recorded operation to its Settlement Verdict, the recorded end state of an on-chain operation and the only signal from which success may be reported, and re-read the corporate-action record before reporting completion. For holder claims, preserve the action or dividend identifier and the holder's proof data. Request acceptance and an unresolved transaction hash are intermediate states, never the answer.
Controls and evidence
The record creates an evidence chain from approved terms to holder-level execution: it identifies the event, dates, economics, entitlement basis, executing transactions, and the progress of any multi-transaction batch. A reviewer can separate what the issuer announced, what the platform executed, and which holder entitlements remain open.
Role checks restrict who may declare or confirm an action. Holder eligibility is fixed from the relevant source: scheduled yield follows on-chain balance history and the configured schedule, while a dividend uses the snapshot root a governance-role holder recorded. Dividend claims also recheck the claimant's on-chain identity at claim time. A failed check reverts the operation instead of producing an off-ledger exception. A holder of the token's custodian role can also claim a dividend for a holder, or redeem a holder's matured units, and the payout still goes to the holder.
A cash dividend, a cash distribution, a bonus issue, a rights issue, a spin-off, a capital decrease, a stock split, a partial redemption, a coordinated distribution, a payout in new tokens or a buyback can carry a maker-checker gate: an organisation owner or platform administrator other than the maker approves or rejects the computed plan before confirm can run. While the organisation's Corporate actions approval is off, or while it has no other owner who could approve, the action runs without that approval. The gate governs the platform's submission and does not bind a direct contract call.
The record proves what the platform received and executed. It does not prove that the issuer's board resolution, notice process, tax treatment, or off-chain funding source was legally sufficient. Those source documents stay in the institution's evidence file, linked through the institution's own control process.
Frequently asked questions
Does a bond mature on its own when the scheduled date arrives?
No. Reaching the date changes nothing by itself. It only opens the ordinary maturity path to the governance role, and that trigger is still refused while the treasury holds less than face value times the supply outstanding. Until an authorised operator triggers maturity, the instrument keeps transferring and servicing normally, so a bond can sit past its scheduled date without maturing.
Can an operator recover a corporate action that opened redemptions during a shortfall?
No. Recovery does not undo the trigger: no operation returns a matured instrument to its pre-maturity state once early maturity has opened redemptions. What an operator can do is send the denomination asset directly to the treasury address already configured for the feature, and the next redemption pays out of that refreshed balance. The operator closes the shortfall by topping up the treasury.
Can an entitled holder claim twice?
No, and each feature refuses it on its own rule. A dividend entry is all or nothing: the recorded snapshot gives a holder one entitlement, the feature marks that entry claimed when it pays, and a second claim against the same entry is refused. Scheduled yield keeps a per-holder mark of the last period paid and pays only the periods after it, so a repeat claim inside the same period has nothing to pay. Redemption pays for the amount burned in that call. A holder can redeem remaining units later but cannot redeem units already burned.
Can a holder redeem a matured position in parts?
Yes. A redemption pays for each burn separately. A holder chooses an amount each time, the feature burns it and pays face value on what was burned, and the same holder can return for the rest later. The one shared ceiling is the total paid across all holders, capped at face value times the supply recorded at the moment of maturity.