Corporate Action
A 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.
One record holds the announced terms and the entitlement basis, then routes the event to the instrument capability that owns the money. It coordinates. It does not execute on its own.
A Corporate Action pays a coupon, a dividend, or a matured redemption straight to a holder's own wallet, so nobody reconciles a legal notice, a holder file, and a ledger update by hand after the event.
It runs inside the instrument's own asset record: interest and dividends sit in the same Service stage that settles trades and freezes holdings, and maturity sits in the same optional Retire stage that closes issuance for good.
The legal event is announced first. Only an authorized operator or agent then turns its terms into an on-chain effect.
Interest follows a configured schedule, a dividend uses a recorded holder snapshot, and maturity exchanges burned principal for the denomination asset.
Payout features draw from a configured treasury and never hold the payout asset themselves.
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 a coupon, a dividend, or a maturity needs a coordinated record
Issuance is the short part of an instrument's life. What follows is 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 is most of what fills it. Interest accrual, a dividend, and a coupon payment run in the same Service stage that settles trades and freezes holdings. A maturity trigger runs in the optional Retire stage, where, in that page's own words, "an instrument that carries the maturity feature ends retired: it matures, holders redeem at face value, and their positions burn".
The cost of getting this wrong is handoff risk, not tokenization risk. A paper process usually splits the work across separate systems. An issuer's legal notice names who is owed what, a registrar's holder file names who currently holds the instrument, a payments desk moves the funds, and a ledger records that it happened. Asset Lifecycle names this pattern directly: a typical programme runs issuance, identity screening, custody, trading, and settlement and reporting in five separate systems. Every boundary between them is a reconciliation where the ledger state and the legal record can drift apart. A Corporate Action closes that gap for one specific 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 rather than inside it: its own copy of who holds what, its own funding source, its own record of who was paid. That copy is where the two systems can disagree, an entitlement the side system computes from stale data against a transfer the instrument's own compliance rules would have refused.
A Corporate Action record keeps no such copy. It coordinates: it does not hold the money, and it does not decide eligibility on its own. 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 authorized 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
An event runs in two stages, and the gap between them is deliberate: an authorized operator or agent records the announced terms first, and only a separate, later call turns those terms into a ledger effect. Nothing moves between the two.
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 AssetA Denomination Asset lets a payout-bearing Token Feature, such as Maturity Redemption or a yield schedule, pay holders in a real asset it never custodies.Read the concept, 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, and a buyback each resolve to a chunked mint or burn against stored per-holder allocations. A rights issue is the exception: it adds entitled holders to an existing token-sale allowlist instead of minting or burning.
The corporate actions API guide covers the full create, preview, confirm, and abort sequence every event type follows, and the same sequence runs from the Console. One invariant holds across every type: an operator must never treat the announcement step as payment. Creating a record only declares the event and, for a cash dividend or distribution, fixes it on chain. Nothing is paid, minted, or burned until a later confirm applies the reviewed allocation.
A dividend's snapshot is irreversible
For a dividend, the operator declares the ex-date, record date, payment date, and claim deadline, each on or after the one before it, with the claim deadline in the future, which is what DALP-9206 enforces, along with the per-share amount and whether the dividend is regular or special. A special dividend is a one-off payment whose dates may coincide or lie in the past. 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 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 funding the dividend had reserved, and declare a fresh dividend against a new record date.
A dividend can be cancelled before its snapshot is recorded. 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 yet claimed a further window. A second extension on the same dividend is refused.
Maturity is a one-way door
Two paths reach the matured state of the maturity redemption feature, and they differ on exactly the point an operator cares about. The ordinary path is available to the governance role once the scheduled date is reached. It will 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 solvency check is also a point-in-time check on the ordinary path, so a treasury drained after maturity produces the same outcome.
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 actually 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 rather than to the holder's own position. A holder is never told about the treasury: a redemption the treasury cannot fund, or one that reverts on chain, answers DALP-12371, which says only that redemption is not available right now and carries no treasury address, allowance, or amount. 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 rather than the difference: the standard token approval overwrites rather than adds. 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 rather than 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.
| Treasury type | What it needs before a payout | What it costs to run |
|---|---|---|
| An externally owned wallet. | A standing approval to the feature for at least the payout amount, signed by that wallet. | The wallet authorizes the allowance. An allowance that runs out stops redemptions with DALP-9481. |
| A vault or other contract. | The funds present, with the contract implementing its own payout logic. | No per-payout approval from a person, and the contract's own controls decide who moves the balance. The platform approves on its behalf only when the contract is the acting smart wallet. |
Coordinator and capability stay separate
Maturity is the clearest place the coordinator-capability split shows. The record schedules the trigger and tracks its outcome. The maturity redemption feature is what actually closes the door.
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 boundary: 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 can draw 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 and a second approver then review the split. Confirm computes the split again and reverts before any money moves if it differs from the approved one, so the platform never pays a split that no one reviewed. Confirm then funds the pool and records each class's snapshot in rank order. Three controls surround it. A class can draw only its own leg. A second person approves the plan unless the organization turned that approval off. One coordinated distribution can be open on an instrument at a time. Abort stops once the pool is funded and any class snapshot is still unrecorded, because aborting then would strand the pool in the waterfall.
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 at the request boundary, but expect the contract to recheck authorization, timing, entitlement, available treasury funds, and claim status during execution. One in-flight composition record is allowed per token. A second create attempt while the first is not yet completed or aborted is refused, and the same limit blocks primitive mint and burn on that token.
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 VerdictA Settlement Verdict lets you report success only when an operation actually happened, not from acceptance alone, across four recorded end states.Read the concept, 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 balance history and the configured schedule, while a dividend uses a recorded snapshot root. Dividend claims also recheck the claimant's on-chain identity at claim time. A failed check reverts the operation rather than producing an off-ledger exception. A composition type that burns or mints against stored per-holder allocations, such as a partial redemption, can also carry a maker-checker gate: a second operator reviews the computed plan and approves or rejects it before confirm can run.
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 authorized 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 shortfall is a funding gap the operator closes by topping up the treasury, not a state the platform reverses.
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. Redemption is per burn, not per account. A holder chooses an amount each time, the feature burns it and pays face value on what was actually 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.
Does a junior class earn income from a shared pool?
Only when its ordinary rank equals the senior class's rank. In ordinary mode the lowest rank takes the whole pool, so a class at a higher rank receives nothing from ordinary distributions, and no error reports it. Equal ranks share income by the capital each class paid in. A junior class recovers its paid-in capital through priority mode, when a trusted issuer's determination names an event that the terms rank differently. The distribution waterfall entry shows the arithmetic.
Primary Offering
A Primary Offering lets an issuer sell newly issued units once and resolve payment, allocation, and delivery or refunds as one on-chain outcome.
Token Distribution
Token Distribution lets an issuer put an allocation into every wallet an eligibility list names, at one fixed cost, without a payout system per campaign.