There is a lot of talk these days about tokenizing stocks as wrappers or as a real representation of owning a piece of a company onchain. Stocks are financial instruments that require special accounting when corporate actions (also called corporate events) occur.
Following is a comprehensive review of corporate actions types and a number of considerations (not often discussed) related to their processing when blockchains are used as the settlement rails and the distributed ledger is the source of truth of who owns what.
A first high-level conclusion that might sound controversial: to process corporate actions at scale it is operationally very challenging to do so in a world of 24x7 uninterrupted trading -> brief moments of trading halts will be required. More on this below, but first let’s start by enumerating the different corporate action types and diving into their processing considerations.
I. Corporate Action (CA) Types
1. Stock Dividends
Stock dividends come in 2 forms: cash or in-kind (i.e. new shares are distributed as dividends). There are a few key timeline dates in their processing, in TradFi markets.
- Declaration Date: The date the company’s board of directors formally announces and approves the dividend payout, specifying the dividend amount, record date, and payment date.
- Ex-Dividend Date: The most critical date for investors. To receive the upcoming dividend payout, you must purchase and own the stock before this date. If you buy on or after the ex-dividend date, the seller receives the dividend instead.
- Record Date: Usually set one business day after the ex-dividend date. This is the date the company finalizes its official ledger of eligible shareholders.
- Payment Date: The day the company actually distributes cash or issues new shares into eligible shareholders’ brokerage accounts.
DeFi processing considerations
a. Processing Dates: As we will see for other corporate action types too, one needs to take into account the concept of a business date (or at least a general processing date that could be any day of the week, w/o considerations for holidays). To my awareness there is no generally agreed upon time of what is a line of demarcation as to when a processing date ends and a new one begins in DeFi - especially one that aligns with what companies issuing dividends across multiple legal jurisdictions are used to. More thoughts on the need to still have some date intervals defined in a world of continuous trading can be found here.
b. Processing Mechanics: In DeFi some of the distinct dates listed above could probably collapse: once on an ex-dividend date + time is selected the corporate action processor needs to take a snapshot of ownership breakdown on the ledger at that exact time.
Based on the determination of which wallets own what amount of shares, the pro-rata calculations for the amount of cash (stablecoins) or new share units can be established and then through atomic transactions can be applied, soon after the calculations are done:
- using a mint authority (for in-kind dividends) - this will increase the circulating supply of shares OR
- through transfers of stablecoins out of wallet(s) funded by the issuing company
The net result being that owners of shares see new distributions / airdrops in their wallets after the CA processing completes. In DeFi, the record and payment dates will likely have less meaning, as the processing timeline for corporate actions can be accelerated.
c. Permissionless Ownership: or in other words, ownership of stocks onchain without knowing the investor behind them (i.e. w/o KYC or KYB). If I hear a tokenization agent saying that their tokenized stocks are issued only to KCYed investors but those stocks can then trade permissionlessly that is a red-flag to me: as something that won’t scale and sooner or later will butt heads with a regulator. Although the airdrops I talked about above can technically be done, I don’t see how they can be legally paid out, if there isn’t a way to prove that the payments are not going out to investors that might be in sanctioned geographies or some sanctioned government list. Not to speak of voting: how can an investor vote when you don’t even know where to send the proxy documents to?
2. Stock splits
There are 2 kinds of stock splits:
- regular stock split - e.g. 2-for-1 (an investor owning 100 shares, will own 200 shares after the stock split)
- reverse stock split - e.g. 1-for-2 (an investor owning 100 shares, will own 50 shares after the stock split)
Timelines similar to stock dividends apply to stock splits processing too and an important thing to know is that as soon as the stock split is applied/reflected in investors accounts the price at which the stock trades adjusts accordingly as well - e.g. for the reverse stock split from above, the new trading price will roughly double.
DeFi processing considerations
The same type of snapshot needs to be taken of who owns what on record date. And the CA needs to be applied uniformly across all wallets owning the shares in such a way that the math works out too as an aggregate: at the end of a 2-for-1 regular stock split processing, the circulating supply needs to double, while for a reverse stock split it needs to be halved, again when using a 1-for-2 as an example.
DeFi approaches to applying stock splits fall into 2 main categories:
a. Scaled UI Multipliers: the number of actual share units in wallets (the raw balance onchain) remains the same but a multiplier is adjusted such as that when quantities are displayed in investors’ wallets they are shown in quantities that reflect the post-split adjustment. This would apply to both current balances and transactions - i.e. transactions post stock-split use the new multiplier to arrive at the displayed transacted quantity.
b. Rebasing: under this approach the actual/raw quantity of shares onchain is adjusted based on the math required by the stock split multipliers. If I had 100 shares before a 2-for-1, I will have a raw balance of 200 shares post stock-split. There is no UI multiplier involved.
Rebasing is a bit more challenging in terms processing but easier to reason about and code for after the CA is processed. Considerations in terms of keys needed to process the stock split with rebasing:
A regular stock split is easier to process from the perspective of having the necessary keys to affect the changes: in essence since the processing is similar to an airdrop, a minting authority is needed to credit the new shares in investors’ wallets.
Reverse-stock splits involve though a special key/permissions because their application requires a debit from the investors’ wallets. As such, a key with special power is involved (referred to as a permanent delegate in the case of Solana Token Extensions or an Authorized Agent in Ethereum - ERC-3643). This authority is attached to the token and has the ability to process forced transfers and burns on any wallet holding the token the authority is associated with.
Challenges using UI Multipliers: the issue with using multipliers is that wallets software (across the board) have to constantly adjust quantities displayed to or entered by users (when submitting a buy/sell order and specifying a quantity) - e.g. if I had 100 shares before a 2-for-1 stock split and I want to sell 25% of them post split, I would enter in the order form 50 (= 100 x 2 x 25%) but, since onchain the raw balance has to be adjusted using the raw/original balance, the software would really need to sell only 25 shares -> such as that my new raw balance onchain is now 75.
The problem compounds when a stock goes through multiple stock splits over its lifetime - and this is not a rare occurrence. This is a sample list with stocks that had more than 3 stock splits, with some companies on this list going through more than 10 stock splits. The application of multipliers in effect for each of these CAs would have to be chained to start with the original raw quantity onchain and arrive at the current display balance.
Typically the DeFi solution is to use a current multiplier that will factor in all prior stock splits - for e.g. if a stock went through 2 stock splits: a 2-for-1 and then a 5-for-1, then the current multiplier will be 10. Displaying current balances goes through the same mechanics as if a stock goes through only 1 stock split.
The additional challenge comes though when displaying historical transactions - if we would always use the current multiplier to take the raw trade/transfer (blockchain transaction) quantity and multiply it by it, we arrive at quantities which were not the actual quantities of sold shares at the time when the transaction happened. In my prior example if I sold 25% of 100 shares pre stock-split, the total numbers of share sold would have been 25 - displaying that as 50, at a time post split (using the multiplier of 2), would be incorrect. To reflect the quantities in effect at the time when the transactions occurred, offchain databases need to be maintained and queried to determine the proper multiplier to be used, in effect at the transaction time.
Based on what is deployed today on blockchains I don’t see the UI multipliers faring well over time - my feeling is that rebasing will eventually win. It also makes it easier to bridge TradFi and DeFi systems, as TradFi also uses rebasing. I don’t see TradFi ledgers moving onchain all at once -> it is more likely that the total number of stocks issued by a company will gradually transition from offchain ledgers to onchain ledgers over time (i.e. there will be periods of time where for e.g. 50% of stock units are still tracked through offchain ledgers while the rest are onchain). And, in this case, having different ways to apply the math/processing for stock splits will complicate matters more.
Very important also: a standard needs to emerge as to how everyone (or at least everyone within given geographical markets) processes stock splits onchain -> w/o that, the confusion and complexities of processing corporate actions in 2 different ways will be a considerable headache and slow the transition to onchain ledgers.
3. M&A
A few permutations are possible here:
a. Merger of equals: 2 companies with tickers ABC and DEF merge into one and a new ticker/cusip is issued XYZ that replaces ABC and DEF.
b. Acquisitions: company ABC acquires company XYZ, the ABC ticker remains, the XYZ ticker disappears and in consideration for it, investors receive one of these sets of new assets:
- new ABC shares
- new ABC shares + cash
- cash only
c. Spinoffs: a company (parent) with ticker ABC spins off a separate legal entity (child) that will trade under symbol XYZ. Possible options here:
- Parent # shares remains unchanged, new shares of child issued
- Parent shares swapped for child shares
- Parent # shares reduced, new shares of child issued
DeFi processing considerations
In all of the above situations something similar to rebasing needs to occur: a snapshot of ledger ownership needs to be taken, a trading halt/delisting has to applied for the tickers that go away and new shares need to be minted of the surviving ticker and/or stablecoin payouts need to be made.
Nothing too different compared to what was discussed for the first 2 corporate action types: a special key needs to be used to burn all quantities on old tickers in an atomic transaction with the credit/mint of new shares and/or cash transfers.
4. Stock Symbol/Ticker & Identifiers Changes
These corporate actions types typically do not involve a change in inventory / # shares outstanding. They only affect attributes of a stock already issued, examples:
- Ticker/symbol changes -> e.g. FACE(book) to META
- Stock identifier (e.g. CUSIP, ISIN, NSIN, SEDOL, WKN, etc.) changes
DeFi processing considerations
a. Symbol/Ticker changes: Token symbols are well standardized in DeFi and updates to this attribute are well supported. However their semantics, when applied to crypto assets, are frequently different than what is applicable in TradFi. In TradFi these are typically administrative changes w/o impact on investors balances. In DeFi, these could involve a rebranding, tokenomics overhauls/redenominations, etc., which then require the creation of a new token and possibly the setup of new/updated smart contracts associated with them.
How will symbol changes be implemented to equities onchain? I presume most often then not, they will just involve a change of the symbol attribute on the same token.
b. Stock Identifiers changes: will stock identifiers lose their importance/meaning onchain, since an onchain token address can be used as de facto unique identifier for a stock? My bet is that at least for the transitional period when ledgers move from offchain to onchain, these identifiers will still need to be around - to bridge and link the TradFi and DeFi rails.
One could argue that offchain systems could be updated with their peer token onchain address and there is no need to carry identifiers onchain. I would argue though that a strong case can be made that these type of attributes (alongside with many other key financial instrument attributes), IF STANDARDIZED, could be a great fit to track onchain, especially on blockchains where blockspace storage is cheaper (see for e.g. the considerable recent rent reduction on Solana). I made the case for this here and here.
II. The Case for Trading Halts
As discussed above, the application of most corporate action types requires taking a snapshot at a particular point in time of all current balances across all owner wallets so the pro-rata calculations can be applied and arrive at new / updated balances that have to be reflected post corporate actions processing in investors wallets.
A world of 24x7 continuous trading implies that balances can change at any point in time as trading/transfers can occur at any point in time. Even the most advanced TradFi trading platforms that for e.g. support 23x5 trading (e.g. US Futures markets, and more recently some spot equities markets) still have typically an 1-hour batch window when trading stops. None of this is applicable in DeFi.
When looking at processing Corporate Actions at scale, one should be considering the most extreme scenarios - i.e. stocks with a very widely distributed ownership. As reflected here, it is not uncommon to see popular stock being held across millions of accounts. TradFi does not need to deal with applying corporate actions all at once across the entire universe of holding accounts -> there are typically at least 2 layers of applying corporate actions:
- The clearing houses (e.g. DTCC) first apply the balances changes on their clearing member accounts - and many of these accounts are omnibus accounts which aggregate balance across many end-investors (e.g. retail customers of clearing members or other institutions accounts that clear through the clearing members) - thus the number of impacted accounts is considerably lower.
- Then brokerage houses and institutions, (typically after they receive the updated data from clearing houses) they apply the balance changes to their end customers accounts.
So in effect, TradFi does not really process (in its batch windows) Corporate Actions for all accounts at once. And you could argue sub-ledgers at intermediaries, get actually processed in parallel.
However when moving to onchain ledgers, it is likely that the level of intermediation will reduce somewhat. And as such an entity (Transfer Agents, Brokers, maybe DEX) might need to process corporate actions against at least tens of thousands wallets for some of the most popular stocks.
Given the assumptions above, a few challenges arise if there is no trading halt for the duration of processing corporate actions:
1. Unreliable ledger snapshots
If trading is not halted, given that reads of balances from the blockchains don’t run in microseconds (and even if they did), corporate actions processors will have a very difficult time determining with precision who owns how much of a stock at a particular point in time, as balances can shift underneath them. By the time all reads for current balances are completed, new transactions can be applied which will alter balances, and then when one adds up all current balances that were just read, the total won’t actually match the current supply. Thus without a precise and accurate snapshot, CA processing can’t continue.
A possible way to solve this is to do the reads from systems that store offchain historical position balances and in this case the math would work out - however, currently, DeFi systems are notorious in their lack of support for historical position balances.
2. Failures to process debit transactions
Even the fastest blockchains today don’t support processing more than a few 10s of thousands of transactions per second. So even in the most optimistic scenario, processing corporate actions (with rebasing updates) across of all accounts, for the extreme cases I mentioned above, will take at least a few seconds if not a few minutes. During this window of time, continuous trading could result in balances that have been changed in such a way that by the time the Corporate Action transaction needs to be processed, the necessary balance quantity to allow the processing to occur is not there any longer:
- for reverse stock split when balances have to be reduced (using the rebasing approach): if an investor sells out their position between the snapshot time and the CA processing time, the debit against its wallet will fail.
- for spinoffs where the parent # shares is reduced: they suffer from the same potential exposure as reverse stock splits.
One could argue that precisely the issue I describe above makes the case for using Scaled UI multipliers for Stock splits vs rebasing. How would we deal then with the spinoffs scenario? We can’t use UI Multipliers there.
Looking across all corporate action types, it makes a lot more sense to me to use rebasing across all of them, instead of making an exception just for stock splits.
So trading halts/pause windows, to allow the processing of corporate actions I think will become the preferred mode of operation. And the capability of having a key that can change amounts across all wallet balances that own a particular token, while trading is halted, will also be a required capability. Having this capability is probably a good idea anyway, for emergency situations when wide spread corrections/verifications are needed to address any serious system integrity issues that might arise and apply repairs to bring specific sub-ledgers back to an operational state.
III. Looking Ahead
The evolution we see today in DeFi markets where different token issuers/tokenization agents create onchain stocks wrappers (sometimes dubbed as debt instruments) or as a closer representation of true ownership (with all legal rights of a stockholder) - with various claims as to how much “true ownership” they offer, seems very normal and expected to me.
Most of them very likely, currently fall short in one or more aspects related to processing corporate actions, if their whole gamut is to be taken in a consideration and parity to TradFi markets in terms of CA processing capabilities is to be assessed.
This is a very complex space and it is impossible to have answers to all these issues at once. The market will evolve by pushing the limits to what is legally possible or not, take shortcuts initially and push forward an agenda. The more volume and more attention tokenized stocks gain though, the more scrutiny they will bring from regulators and TradFi market participants in general -> and that should lead to a closer alignment, more standardization and systems buildouts that allow the transition to onchain ledgers w/o losing investors convenience and discarding best practices uncovered in TradFi markets over the decades.
While I still have some doubts that all trade matching that happens today on TradFi markets can be brought onchain, for reasons I explained here, I do believe that the barriers to bringing most clearing and settlement onchain are lower and the trend towards this transition, while still somewhat in its infancy, is starting to gain more traction as time goes by.
And if one day most equities trading can settle onchain, why wouldn’t derivatives (options and futures) follow the path of spot markets? Applying Corporate Actions to derivatives positions on blockchain rails is an even more challenging endeavor. I am hoping though as an industry will get to that as well, in the years to come.