Can Monero add checkpoints to defend against deep reorgs?

Yes. Monero can use checkpoints to reject a competing blockchain history that conflicts with an agreed block, and its software already includes hardcoded historical checkpoints. But using checkpoints to stop new deep reorganizations would require important choices about who selects them, how quickly they appear, and how much trust you place in that process.

What a checkpoint actually protects

A chain reorganization, or reorg, happens when your Monero node switches to a competing chain with more accumulated mining work. Your node is the software that checks blocks and transactions for you.

Small reorgs can happen naturally when miners find competing blocks close together. A deep reorg replaces a much longer stretch of history. It could undo payments you thought were settled or allow an attacker to spend the same funds again.

A checkpoint records a specific block’s height—its position in the chain—and its hash, a digital fingerprint identifying that block.

If your node enforces that checkpoint, it rejects a competing history that disagrees with it. Even more mining work cannot make that conflicting history acceptable to that node.

What Monero’s existing checkpoints do

Monero already has historical checkpoints built into its software. These anchor particular older blocks.

That is useful, but it is not the same as continuously protecting recent payments. A checkpoint protects the history through its position, not every block added afterward.

For example:

• A checkpoint at block 1,000 prevents your node from accepting a chain with a different block at that position.
• It does not, by itself, prevent a reorg that replaces blocks 1,001 through 1,100.
• Adding another checkpoint later moves that protected boundary forward for nodes that adopt it.

So “Monero has checkpoints” does not mean “Monero guarantees that every payment becomes irreversible after a fixed number of blocks.”

Why frequent checkpoints change the trust model

Monero could adopt a system that publishes and enforces checkpoints more frequently. The difficult part is deciding which blocks deserve that special status.

Possible approaches include checkpoints distributed through software releases or approved by designated signing keys. Either approach introduces decisions beyond simply checking accumulated mining work.

You would need answers to questions such as:

• Who chooses? A small group could gain influence over which history survives.
• What if keys are stolen? Attackers could misuse a checkpoint-signing system.
• What if nodes disagree? Conflicting checkpoints could split the network.
• What if communication fails? Nodes might stall or make incompatible decisions.

Automatically refusing any reorg deeper than a chosen limit also has risks. During a long network outage or deliberate isolation, different nodes could lock themselves onto different histories.

What this means for your payments

Checkpoints are a possible defense layer, not a free replacement for mining security.

As of 2026, Monero targets roughly two minutes per block. Normal received funds need 10 confirmations before becoming spendable, while newly mined coins remain locked for 60 blocks. Those wallet rules are not checkpoint guarantees.

For a valuable payment, you may choose to wait longer before treating it as settled. More confirmations generally make reversal harder, but they do not create absolute finality.

The bottom line

Monero can checkpoint history, and already does so for older blocks. Stronger protection against recent deep reorgs is technically possible, but it trades some reliance on mining work for reliance on checkpoint selection and distribution. The key question is not just “Can it?” but “Who gets to decide which history cannot change?”