A corporate action on a tokenized asset has to reach every entitled holder, wherever the token sits. Once supply spans several chains, an issuer paying a dividend or running a vote has to establish who holds the asset on each of them first, and a token contract will not tell it.
This page explains how dividends, splits, and votes are executed across chains, what an issuer needs in place first, and where the process breaks. To scope corporate actions for a tokenized asset, reach out to our team.
What is a corporate action on a tokenized asset?
A corporate action is an issuer-initiated event that changes what holders own or are owed: a dividend or coupon, a split or reverse split, a redemption, or a vote. Entitlement follows the asset's governing terms and official holder record. Onchain balances may be that record or may feed an offchain register, depending on how the asset is structured.
Tokenization changes the mechanics rather than the obligation. A dividend still has to reach every entitled holder, and a split still has to apply to every unit of supply, whether that supply sits on one chain or eight.
What an issuer needs before it can run one
Three things, and the first is the one that fails.
- A holder record per chain. A token contract answers what a given address holds, and it does not list who the holders are. The set has to be built from indexed transfer events, or from a register the issuer keeps alongside the contract.
- A record point that means something across chains. Chains do not share a clock, so a single date has to become a specific block on each chain, with transfers in flight between them accounted for.
- A distribution path. Whatever is being paid has to reach holders on the chain where they hold, or the entitlement has to be claimable there.
The first is where most of the work sits. Standard token interfaces expose a balance for an address you already know, so enumerating holders means indexing every transfer since deployment and keeping that index current on every chain. An asset with transfer restrictions has a shortcut: only approved addresses can hold it, so the allowlist is a bounded candidate set to check balances against rather than an open-ended reconstruction.
How the action types differ
Four actions cover most of what an issuer runs, and they place different demands on it.
| Action | What has to reach holders | What it demands |
|---|---|---|
| Dividend or coupon | A payment, per holder | A holder record, and a payment route on each chain |
| Split or reverse split | A ratio applied to every balance | Contract support for it, on every deployment |
| Redemption | Proceeds, against surrendered units | A redemption venue, and units to be surrendered to it |
| Vote | A ballot and a tally | Holder weights at a point in time, and no double-counting |
A dividend and a split are hard for different reasons. A dividend needs to know who the holders are, which is the enumeration problem. A split needs the contract to be able to restate every balance at once, and a plain token contract cannot: there is no global multiplier on balances, so a split requires accounting designed for it, such as a share-and-rate model, or else a migration to a new contract. An issuer that expects to split has to build for it before issuance rather than decide at the point of the action.
How the record gets assembled
Mostly by indexing. The issuer runs an indexer over transfer events on every chain where the asset is deployed, which yields the holder set and each balance as of any block. That is infrastructure the issuer maintains, and it is the part a token standard does not provide.
Cross-chain reads cover a narrower job: retrieving a figure from another chain for the issuer's own logic, rather than enumerating a set. A transfer changes state on a destination chain, while a read returns data from one.
LayerZero's lzRead pattern covers the second case. A request specifies the target chain, the data, and the block context, then returns the answer in a single round trip, with verifiers fetching from archival nodes and attesting to the result. A compute stage can transform each response and aggregate the set before it returns, so a contract receives the figure a calculation needs rather than raw state.
One constraint shapes how much this can carry. Reads need a compatible message library and verifiers with archival access on the pathway, so the supported origin and target combinations are narrower than the set of chains an asset can be issued on. An issuer relying on reads rather than its own index should confirm coverage for its own corridors first.
Where it breaks
Three failure modes, all of them record problems rather than transfer problems.
- Transfers in flight across the record point. This is the one a per-chain block does not fix. A transfer can be debited on the source before its chosen block and credited on the destination after, so the units appear in neither set, and a different ordering counts them twice. Fixing a block per chain is necessary and not sufficient.
- Ineligible holders. An asset with transfer restrictions may have supply sitting with an address that no longer qualifies, which is a question the action forces the issuer to answer.
- Chains the issuer forgot. Older bridged copies of the asset still hold balances, and their holders are not in the issuer's register.
The first is why a defensible record process does more than pick blocks. There are two ways to close it. The issuer can reconcile in-flight messages directly, tracking every transfer dispatched but not yet delivered and assigning each to one side of the record point. Or it can pause outbound transfers ahead of the record point, wait for dispatched messages to settle, and read once none remain. Message status is what makes either approach possible, since it distinguishes a transfer still awaiting verification from one already delivered.
Pausing is the simpler of the two and it is not the only option. A rate limit does not substitute for it, since any nonzero cap still allows transfers to leave.
The third is why the supply model decides how tractable this is. An issuer that controls every canonical deployment knows which ledgers belong in its record. Third-party wrapped copies require separate treatment because their holders' rights depend on the bridge or custodian structure and the issuer's governing terms.
FAQ
How does an issuer pay a dividend to holders on several chains?
By settling or accounting for in-flight transfers so the record point is unambiguous, taking the holder set from its index of transfer events on each chain, then distributing on each chain or making the entitlement claimable there.
Can an issuer read a list of holders from the token contract?
No. A token contract answers what a specific address holds, and it does not enumerate holders. The set comes from indexing transfer events, or from a register the issuer maintains alongside the contract.
What is a record date when chains do not share a clock?
A block height per chain, plus a way to account for transfers in flight between them. Choosing corresponding blocks alone can miss units mid-transfer or count them twice.
Do splits apply automatically across chains?
No, and not automatically on any single chain either. A plain token contract has no way to restate every balance at once, so a split needs accounting built for it or a migration, executed on every deployment.
Can holders of a bridged copy claim a dividend?
Not automatically. Whether wrapped-token holders receive a dividend from the issuer, through a bridge or custodian, or not at all depends on the issuer's terms and the third party's structure.
Does a corporate action require pausing transfers?
No. Pausing outbound transfers around the record point is the straightforward way to be sure nothing is in flight, and the alternative is to reconcile in-flight messages and assign each to one side of the record point. A rate limit is not a substitute, because any nonzero cap still lets transfers leave.
Scope corporate actions for a tokenized asset
Running a corporate action across chains is a records problem before it is a payments problem. It works when the official holder record covers every canonical deployment, treats third-party representations according to their actual rights, and accounts for anything in flight at the record point.
To work through that for a live or planned instrument, reach out to our team, or start at Developers.