Crypto Corporate Actions
Forks, airdrops, token burns, governance votes, and vesting — how blockchains handle the events that change what you own
What Are Corporate Actions?
In traditional finance, a corporate action is any event initiated by a company that materially affects its securities — stock splits, dividends, mergers, rights issues. Crypto has its own equivalents: events that change what you own, how much you own, or which chain your assets live on.
The analogy is imperfect but useful. A hard fork resembles a stock split or spin-off — you hold both legacy and new assets after the event. An airdrop resembles a special dividend — tokens distributed to qualifying holders. A token burn resembles a share buyback — reducing circulating supply to benefit remaining holders. A rebase resembles a stock split — adjusting the number of units you hold without changing their aggregate value.
The key difference: crypto corporate actions are executed by immutable smart contracts or by social consensus among node operators. There is no board of directors, no registrar, and often no single legal entity responsible for the event. This creates unique risks — replay attacks, exchange treatment uncertainty, tax ambiguity — that traditional investors don't face.
Understanding these events is essential for anyone holding crypto assets. Missing a fork can mean missing free tokens. Misunderstanding a rebase can make your portfolio look like it's crashing when nothing fundamental has changed. Ignoring an unlock schedule can expose you to predictable sell pressure that sophisticated traders are already positioned for.
When a significant protocol event is announced, ask: (1) Do I qualify? (2) Do I need to take action, or is it automatic? (3) How will my exchange or custodian handle it? (4) What are the tax implications? This guide answers each of these for every major crypto corporate action type.
Hard Forks & Soft Forks
A fork is a change to a blockchain's consensus rules. The critical distinction is whether the change is backward-compatible. Soft forks tighten the rules; hard forks change them in ways that permanently split nodes that disagree.
A soft fork introduces a rule change that old nodes still accept as valid — they just won't enforce the new rule. Bitcoin's SegWit (BIP141) is the canonical example: old nodes saw SegWit transactions as valid (anyone-can-spend outputs), while upgraded nodes applied the full signature verification rules. If the majority of hash power enforces the new rule, the minority cannot produce a competing chain — the network converges. Soft forks are upgrades; they don't split the asset.
A hard fork introduces a rule change that old nodes reject as invalid. If any significant portion of the network refuses to upgrade, the chain permanently splits into two divergent histories from the fork block. Every holder at the fork block height ends up with tokens on both chains — their pre-fork balance is cloned. What happens after is determined by market forces, developer activity, and community support.
Hard forks come in two flavours. Planned upgrades are non-contentious: near-universal community consensus means almost all nodes upgrade, and any minority fork collapses from lack of support (Ethereum's London, Paris, Shanghai upgrades).Contentious hard forks arise from genuine disagreement — scaling philosophy, values disputes, or economic interests — and can produce viable competing chains with real market value (ETH/ETC, BTC/BCH).
Scaling disagreement: BTC kept 1MB blocks + SegWit; BCH increased block size to 8MB (later 32MB) and rejected SegWit. BCH proponents argued larger blocks were the original Satoshi vision.
Every BTC holder at block 478,558 received 1 BCH. Exchanges credited both coins; some required manual claiming.
Replay attacks are the hidden risk in hard forks. If both chains share the same transaction format and chain ID, a transaction broadcast on one chain is technically valid on the other — an attacker (or even your own wallet software) can "replay" it. Modern forks address this with replay protection: different chain IDs (EIP-155), different signature schemes (BCH's SIGHASH_FORKID), or transaction format changes that make cross-chain validity impossible.
| Fork type | Backward compatible? | Chain split? | Asset duplicated? |
|---|---|---|---|
| Soft fork | Yes — old nodes accept | No, converges | No |
| Planned hard fork | No | Technically yes, but collapses | Briefly, then worthless |
| Contentious hard fork | No | Yes, both persist | Yes — two real assets |
Airdrops & Token Distributions
An airdrop is a distribution of tokens to a set of qualifying addresses, typically at no direct cost to recipients. Protocols use airdrops to decentralise ownership, reward early adopters, bootstrap governance participation, and generate awareness.
The mechanics vary significantly across airdrop types. The snapshot airdrop — pioneered by Uniswap's landmark 400 UNI distribution in September 2020 — rewards holders of a specific token at a fixed block height. The retroactive airdrop rewards protocol users based on on-chain activity scores, as Arbitrum and Optimism did with ARB and OP. The streamed airdrop vests tokens linearly over time to reduce immediate sell pressure.
All three types use the same on-chain claim mechanism: a Merkle treeof eligible addresses and amounts is constructed off-chain, and the Merkle root is written to an airdrop contract. Recipients submit a Merkle proof — a compact cryptographic path from their leaf to the root — to claim their allocation. This is efficient: the contract stores only one 32-byte root regardless of how many recipients there are.
Protocol records every wallet's balance at a specific block height. Holding tokens before the snapshot qualifies you; holding after does not.
- UNI airdrop (Sep 2020): 400 UNI to every historical Uniswap user
- ENS airdrop (Nov 2021): based on ENS name registration history
Snapshot block is usually announced only after it has already passed — to prevent last-minute farming. 'Snapshot farming' (buying tokens just before an announced snapshot) is a known strategy.
Generally treated as ordinary income at fair market value on the date of receipt (US/UK treatment).
Airdrop farming is the practice of deliberately positioning to qualify for expected distributions. Snapshot farming means buying tokens before an anticipated snapshot. Retroactive farming means using every new protocol early and broadly. Protocols respond with increasingly sophisticated anti-Sybil filters: clustering analysis to detect wallets funded from the same source, minimum activity thresholds, on-chain reputation scores, and sometimes KYC for larger allocations. The arms race continues.
In most jurisdictions, airdropped tokens are ordinary income at fair market value on the date you receive them — not when you sell. If you receive 1,000 tokens at $10 each and the price later drops to $1, you still owe tax on $10,000 of income. Plan for tax liability before spending airdrop proceeds.
Token Burns & Buybacks
A token burn permanently removes tokens from circulating supply by sending them to an address from which they can never be retrieved. The canonical burn address on Ethereum is0x000...dEaD — a checksum-valid address with no known private key.
Burns come in two forms. Protocol burns are built into the token mechanics: Ethereum's EIP-1559 burns the base fee on every transaction — since August 2021, over 4 million ETH have been burned, making ETH occasionally deflationary under high network usage. BNB's quarterly burns reduce total supply toward a 100M target. Discretionary burns are one-off events — a team burns unsold treasury tokens or uses protocol revenue to buy and burn tokens on the open market.
The economic argument for burns mirrors the share buyback rationale: if demand is constant, reducing supply increases the value of each remaining token. In practice, the effect depends on whether the burned tokens represent genuine supply reduction (tokens that would otherwise have been sold) or purely symbolic gestures (burning locked treasury tokens that were never circulating anyway).
Buy-and-burn programs combine two effects: buying tokens on the open market creates direct price support, while burning removes those tokens permanently. Maker DAO's smart burn engine uses protocol surplus (from stability fees) to buy MKR on Uniswap and burn it. Evaluating any burn program requires checking the source of funds: genuine protocol revenue buying and burning tokens is fundamentally different from a team burning their own allocation for marketing purposes.
| Burn type | Supply effect | Price effect | Example |
|---|---|---|---|
| EIP-1559 base fee burn | Continuous, usage-dependent | Reduces ETH inflation/creates deflation | Ethereum (post-Merge) |
| Quarterly scheduled burn | Predictable, pre-announced | Anticipated in price pre-event | BNB Burns |
| Buy-and-burn from revenue | Ongoing, revenue-driven | Buyback support + supply reduction | Maker MKR burn engine |
| Treasury token burn | Reduces total supply, not circulating | Minimal if tokens were locked | Various team burns |
Rebases & Elastic Supply
A rebase adjusts every holder's token balance simultaneously — expanding or contracting supply proportionally — without changing the percentage of total supply each holder owns. It's a stock split in token form.
The mechanics: the token contract stores balances as shares rather than raw amounts. A global rebaseFactor (or its inverse, sharesPerToken) converts between shares and displayed balance. A rebase event updates this factor; every wallet's displayed balance changes instantly without any individual transfer transactions.
Positive rebases increase supply. Ampleforth (AMPL) — the original elastic supply token — targets a price of $1 by rebasing supply daily: if AMPL trades above $1, supply expands so each holder gets more tokens (and price moves toward $1 as supply increases). OHM forks used rebase mechanics to offer staggering nominal APYs — 3,000%+ — which in practice translated to modest real returns because each token was worth proportionally less.
Staked rebasing (stETH, rETH) is a different use of the same pattern. Lido's stETH balance increases daily as Ethereum staking rewards accrue — your stETH balance reflects both your original deposit and accumulated rewards without requiring any claim transactions. Rocket Pool's rETH takes the opposite approach: supply stays constant, but each rETH becomes redeemable for more ETH over time (exchange rate accrual).
Rebasing tokens are notoriously difficult to integrate with DeFi protocols. Uniswap v2 pools cannot handle balance changes that occur outside of swap transactions — liquidity providers in rebasing token pools lose rebase rewards to arbitrageurs. This is why Lido also offers wstETH (wrapped stETH) — a non-rebasing version that accrues value through exchange rate rather than balance changes, making it safe for use in lending protocols and LP pools.
On-Chain Governance Votes
On-chain governance allows token holders to propose and vote on protocol changes that are automatically executed by smart contracts if the vote passes. This is crypto's equivalent of a shareholder vote — except the resolution is enforced by code, not by a registrar or board.
The standard implementation follows the Governor Bravo pattern (used by Compound, Uniswap, and many forks): a governance token holder creates a proposal with an on-chain calldata payload — the exact transaction(s) to be executed if the proposal passes. A voting period opens (typically 3–7 days). Token holders vote for, against, or abstain. If quorum is reached (e.g., 4% of supply) and the vote passes, a timelock delay (typically 2 days) gives users time to exit before the change takes effect. After the timelock, anyone can call execute() to enact it.
Snapshot voting is an off-chain variant that uses signed messages to record votes without gas costs. Results are not automatically enforced — a multisig or governance committee must manually execute approved proposals. This sacrifices trust minimisation for participation: turnout is higher when voting is free.
Governance attacks are a real risk in any protocol with on-chain governance and liquid governance tokens. An attacker with sufficient token holdings (or the ability to borrow them via flash loans) can pass a proposal that drains the treasury. Compound, Tornado Cash, and Beanstalk have all experienced governance-related exploits or near-misses. Timelocks, quorum requirements, and guardian multisigs are the primary defences.
| Governance mechanism | Trust level | Gas cost | Enforcement | Example |
|---|---|---|---|---|
| On-chain Governor | Trustless | High (voters pay gas) | Automatic via timelock | Compound, Uniswap |
| Snapshot + multisig | Trusted committee | None for voters | Manual execution | Aave (formerly) |
| veToken governance | Trustless | High | Automatic | Curve, Balancer |
| Optimistic governance | Trustless with challenge | Low normally | Auto after challenge window | Optimism Collective |
Vesting & Token Unlocks
Token unlock schedules determine when early investors, team members, and ecosystem contributors can sell their allocations. These events are among the most predictable sources of sell pressure in crypto markets — and among the most overlooked by retail investors.
Every token launch begins with a total supply allocation across stakeholders. Typical categories include: public sale (tokens sold at TGE), team and founders (long vesting, often 1-year cliff then 3–4 years linear), investors (shorter vesting, often 6-month cliff then 18 months linear), ecosystem and grants (slow release over 4+ years), protocol treasury (multi-year controlled release), and liquidity (often 100% at TGE).
The cliff is a lock-up period during which no tokens vest — after which vesting begins (sometimes with an initial tranche). The vesting period is the total duration over which the remaining allocation linearly unlocks. A common team schedule is a 12-month cliff followed by 36 months of linear vesting — meaning nothing unlocks for the first year, then 1/36th of the vested allocation becomes available each month for three years.
Large cliff unlocks — particularly 1-year team and investor tranches — create identifiable windows of potential sell pressure. Resources like Token Unlocks and Vesting.xyz aggregate unlock schedules across hundreds of protocols, allowing investors to see upcoming unlock events months in advance. The market often pre-prices anticipated unlocks: price tends to weaken in the weeks before a major cliff, then sometimes rebounds once the uncertainty resolves and not all newly-unlocked holders sell.
When evaluating a token: (1) Find the total supply breakdown — what percentage goes to team and investors? (2) When is the first cliff? (3) What percentage of total supply unlocks at or shortly after TGE? A token that launches with 15% circulating supply and has 35% unlocking at the 1-year cliff faces significant structural headwinds at that moment. Compare unlocks to average daily trading volume to estimate relative impact.
Token Migrations & Swaps
A token migration replaces one token contract with another, requiring holders to swap their old tokens for new ones within a defined window. Migrations occur when protocols need to change token mechanics, fix contract bugs, or rebrand.
The mechanics are straightforward: the protocol deploys a new token contract and a migration contract. Holders approve the migration contract to spend their old tokens, call migrate(uint256 amount), and receive new tokens at a fixed ratio (usually 1:1). The old tokens are burned or locked in the migration contract.
Notable migrations include: LEND → AAVE (100:1 consolidation in 2020 — one AAVE for every 100 LEND), SNX v1 → v2 (various Synthetix contract upgrades), and REP v1 → REP v2 (Augur's migration to fix a fundamental market resolution bug). Each had a migration window; LEND tokens not migrated became worthless.
Token swaps differ from migrations in that both old and new tokens may continue to exist independently. Cross-chain token bridges are sometimes called swaps when the underlying asset is the same but the chain differs — bridging ETH to Arbitrum is not a migration, but a representation of the same asset on a different layer.
The primary risk in migrations is the deadline. Protocols typically offer migration windows of 6–24 months, after which old tokens lose redemption rights. Hardware wallet holders, holders with forgotten wallets, and exchange users who didn't claim their tokens before a deadline have permanently lost value in migrations. Always track migration announcements for every token you hold.
Exchange & Custodian Treatment
How your exchange or custodian handles a corporate action is entirely separate from how the blockchain handles it. Holding tokens on an exchange means the exchange holds them on your behalf — and may or may not pass through the benefits of every on-chain event.
For hard forks: major exchanges generally credit both assets after contentious hard forks once the forked chain demonstrates sufficient market value and technical stability. But there is no obligation to do so — exchanges decide case by case. Binance, Coinbase, and Kraken all handled BTC/BCH differently in 2017; some required manual claiming within specific windows. Holding assets in a self-custody wallet at the fork block guarantees you receive both sides.
For airdrops: exchanges may pass through airdrop allocations or may keep them. Many smaller airdrops are simply not distributed to exchange users. Protocols sometimes explicitly exclude exchange wallets from eligibility (or exclude addresses identified as CEX hot wallets via on-chain analysis). Retroactive airdrops almost always require the wallet that interacted with the protocol — exchange accounts don't interact directly with DeFi protocols, so those users are ineligible by definition.
For staking rewards and rebases: most major exchanges support staking and pass through rewards (often taking a cut). Rebasing tokens like stETH are typically handled correctly by large exchanges, though some smaller platforms may show incorrect balances during rebase periods.
For token migrations: exchanges handling the migration on behalf of users is common for large migrations (LEND → AAVE was handled automatically by most major exchanges). But relying on this is risky — always confirm your exchange has announced migration support before assuming your tokens will be converted.
The phrase applies directly to corporate actions. Self-custody guarantees participation in every on-chain event — forks, airdrops, governance votes. Exchange custody means relying on the exchange's discretion. The trade-off is convenience versus control: know which events matter to you and ensure you hold tokens appropriately before each one.
Tax & Accounting Implications
Crypto corporate actions create complex tax events that many investors don't anticipate. The rules vary significantly by jurisdiction and are still evolving — but ignoring them can result in significant unexpected liabilities.
Hard forks and airdrops are treated as ordinary income in most major jurisdictions (US, UK, Australia) at fair market value on the date you receive the tokens. In the US, the IRS issued guidance in 2019 (Rev. Rul. 2019-24) confirming that tokens received from a hard fork are gross income when received. Your cost basis in the new tokens is the value at receipt — when you later sell, you pay capital gains on any appreciation from that basis.
Token burns that affect your holdings are straightforward: if your tokens are burned without compensation, you may have a capital loss. Protocol-level burns (EIP-1559) don't directly reduce your balance — they reduce total supply, potentially increasing the value of remaining tokens.
Rebases create uncertainty. A positive rebase technically increases your balance — the IRS has not issued definitive guidance on whether each rebase is a taxable event. Conservative interpretation: income at each rebase. Aggressive interpretation: no taxable event until sale (similar to stock splits). The safe approach is to track the fair market value of any rebase increase at the time of each rebase event.
Token migrations at 1:1 ratios are generally treated as non-taxable events in most jurisdictions — similar to a stock ticker change. Non-1:1 migrations (LEND → AAVE at 100:1) may trigger a taxable disposal of the old token and income recognition on the new token. The specifics depend on jurisdiction.
Governance voting itself is not a taxable event. However, governance rewards (some protocols pay governance participants) are ordinary income when received.
| Event | Tax treatment (US/UK) | Cost basis | Timing |
|---|---|---|---|
| Airdrop / fork receipt | Ordinary income | FMV at receipt | On receipt |
| Token burn (your tokens burned) | Capital loss | Your original cost basis | On burn |
| Rebase (positive) | Likely ordinary income (unclear) | FMV of additional tokens at rebase | On rebase event |
| 1:1 token migration | Generally non-taxable | Carries over from old token | N/A |
| Non-1:1 migration | Disposal + income | FMV of new tokens received | On migration |
| Governance rewards | Ordinary income | FMV at receipt | On receipt |
Tax treatment of crypto corporate actions is jurisdiction-specific, fact-specific, and rapidly evolving. The summaries above reflect common interpretations in the US and UK as of 2025 — consult a qualified tax professional before filing. Crypto tax software (Koinly, CoinTracker, Coinpanda) can help track cost basis across multiple event types, but always verify their treatment against current guidance in your jurisdiction.