A Bitcoin checkpoint is a hardcoded block hash embedded in the Bitcoin Core client that tells new nodes: this block is legitimate, full stop. The node won't accept any chain that contradicts it. Checkpoints were introduced early in Bitcoin's life as a practical defence against a specific class of attack, and understanding them gives beginners a clearer picture of how the network protects its historical record.
What a checkpoint actually is
Every block on the Bitcoin blockchain has a unique hash, a fixed-length fingerprint that changes if even one character in the block is altered. A checkpoint is simply a pairing of a block height and that block's hash, written directly into the software source code. When Bitcoin Core developers decide that a particular block is so deeply buried in history that it will never be reversed, they can hardcode that block's hash as a checkpoint.
When a new node downloads the blockchain from scratch, it validates every block from the genesis block forward. Checkpoints act as fixed anchors along the way. If an attacker tries to feed the new node an alternative chain that branches before a checkpoint, the node rejects it outright, regardless of how much proof-of-work that alternative chain carries. The checkpoint wins. No debate.
It's worth pausing on that last point. Bitcoin's normal consensus rule is that the chain with the most cumulative proof-of-work is the valid one. Checkpoints override that rule for the history they cover. That's both their strength and their most discussed trade-off.
Why checkpoints were introduced
In Bitcoin's early years, the network's total hash rate was tiny. A determined attacker with modest computing power could have rewritten years of transaction history by rebuilding a longer alternative chain from scratch. That kind of attack, sometimes called a "history-revision attack" or a deep reorganisation, would have been catastrophic for anyone who accepted a payment believing it was settled.
Checkpoints closed that window. By the time a new node syncs, it treats every block before the most recent checkpoint as immutable. An attacker can't rewrite anything behind it, even if they somehow assembled more computing power than the entire honest network, because the client simply won't accept a chain that diverges at that point.
This matters less today. The Bitcoin hash rate has grown enormously since those early years, and the cost of a deep reorganisation attack is now astronomical. Understanding what a Bitcoin hash rate is and why it matters gives you a sense of just how much computing power now protects the network. That protection makes the original threat checkpoints were designed to address essentially theoretical at current scale.
Checkpoints vs. assumed valid
Bitcoin Core has largely replaced checkpoints with a subtler mechanism called "assume valid." Rather than rejecting chains that contradict a known hash, assume valid skips signature verification for blocks that precede a trusted ancestor. The node still downloads and processes every block; it just doesn't recheck every cryptographic signature for history it already trusts.
The practical difference is meaningful. Assume valid speeds up initial block download significantly, because signature verification is computationally expensive. It doesn't reject alternative chains the way a checkpoint does, though. It's a performance shortcut, not a consensus rule. Checkpoints, by contrast, are a hard consensus rule: a chain that violates one is simply invalid to that node.
The last hard checkpoint in Bitcoin Core was added at block 295,000, included in version 0.9.3 back in 2014. No new hard checkpoints have been added since. The developers decided the growing hash rate made them unnecessary, and that hardcoding consensus rules into client software introduced its own risks, centralising too much trust in whoever controls the Core repository.
The centralisation argument
Critics of checkpoints have always pointed out the same tension: if the Bitcoin Core developers can decide which blocks are canonical by writing them into the software, then those developers hold meaningful power over what counts as valid history. That sits uncomfortably alongside Bitcoin's design goal of being a trustless, decentralised system.
This argument is legitimate but somewhat overstated in practice. Checkpoints only cover history that is already so deeply confirmed that no honest participant would dispute it. They don't let developers redirect future transactions or censor specific addresses. Still, the debate over checkpoints is a useful window into how Bitcoin governance actually works: through rough consensus among developers, miners, and node operators, not through any single authority.
If you're running your own full node, you're validating every transaction independently. Understanding what a Bitcoin node does makes it clear why running one is the most trustless way to interact with the network, checkpoints and all.
What this means for beginners
For most Bitcoin users, checkpoints are invisible. You'll never manually configure one, and you won't encounter them in a wallet interface. Their significance is architectural: they reveal that even a system designed to minimise trust still makes deliberate engineering decisions that require some degree of trust in the developers who ship the software.
Knowing that checkpoints exist doesn't change how you buy, send, or store Bitcoin. It does help you understand why Bitcoin's history is treated as genuinely permanent, and why the probability of a confirmed transaction being reversed drops to effectively zero once it's buried deep enough in the chain. That permanence is core to what makes Bitcoin useful as a settlement layer. Every confirmed transaction you've ever sent relies on the same principle the checkpoint mechanism formalises: that history, once written, stays written.