What actually happens at a hard fork is a switch at a specified point, usually a block number. From that block onward, the upgraded nodes produce blocks in the new format. Any node that has not upgraded rejects them and keeps building on the last block it recognizes. If every node upgrades, there is one chain and the fork is invisible after the fact. If a meaningful number do not, there are two, and, as NIST puts it, "users on different hard fork versions cannot interact with one another". The two chains share every transaction up to the split and nothing afterwards.
The distinction worth carrying away is between deciding and doing. A fork is often described as though the network votes. The best-documented case is more specific than that. In 2016 an attacker exploited a flaw in a smart contract called The DAO running on Ethereum; the SEC's report on that investigation records that the attacker "used a flaw in The DAO's code to steal approximately one-third of The DAO's assets". NIST records what happened next: "A hard fork proposal was voted on by Ether holders, and the clear majority of users agreed to hard fork and create a new version of the blockchain, without the flaw, and that also returned the stolen funds." So a poll was held. But the poll did not move the ledger; running the new software did, and because a minority kept running the old rules the old chain survived under the name Ethereum Classic. A fork is settled by what nodes run, and a vote is at most evidence about what they are likely to run.
Forks are not always deliberate. NIST notes that "while most hard forks are intentional, software errors may produce unintentional hard forks", which is a different failure from a governance dispute and has to be repaired rather than chosen. It also flags a genuine vocabulary trap: some networks use the word fork for a temporary conflict in the ledger, two blocks competing for the same height, which resolves itself within minutes and "does not stem from a software change". That is not a hard fork, and the shared word causes real confusion.
The most consequential thing a hard fork proves is negative. A rule written into a blockchain's software, including a supply cap, is enforced by the software the participants choose to run. A hard fork is the mechanism by which such a rule could be changed, so describing any of them as unchangeable describes the difficulty of coordinating thousands of independent operators rather than a physical limit. The bitcoin page carries that qualification for bitcoin's own supply cap and this page is the mechanism behind it.
For tax, only one half of the event matters, and it is the half people get wrong. The fork by itself is not income. Revenue Ruling 2019-24 holds that a taxpayer whose cryptocurrency undergoes a hard fork "does not have gross income under section 61" if they receive no units of a new cryptocurrency. What can produce income is the distribution that sometimes follows, and the IRS is explicit that "a hard fork is not always followed by an airdrop". The income question therefore belongs to the airdrop, not to the fork.
The IRS's current digital-asset questions and answers say the same thing in plainer words and add the soft-fork case. A soft fork produces no income at all, because it "does not result in a diversion of the ledger". A hard fork with no new asset received produces none either. A hard fork where new assets are received produces "ordinary income equal to the fair market value of the new digital assets when they are received, which generally is when the transaction is recorded on the distributed ledger, provided you have dominion and control over the digital assets". So the tax result tracks the mechanics this page describes: nothing happens until something arrives that the holder can actually move.
