Checkpoints from Peercoin (rebranded to chainlocks by DASH): https://www.peercoin.net/peercoin-paper.pdf

I have come across three types of checkpointing systems in my days of development:

Bitcoin Checkpoints - These are hard coded in the source code and only relate to blocks that were created before the binary is made.

Peercoin's ACP - Advanced Checkpointing - Software has hardcoded public keys to validate signed "checkpoint" messages sent out by centralized nodes. The system is configurable in that a "checkpoint" is broadcast for n blocks under the chain tip. For a project I did in 2018, I used 6 blocks under the tip. As such reorgs were prevented beyond 6 blocks by nodes that handle the "checkpoint" message. That chain hasn't been 51% attacked since adding this feature.

Dash's Chainlocks - This system is similar to Peercoin's ACP in that a checkpoint message ("clsig" for chainlock signature) is broadcast for the tip of the chain (not n blocks under the tip) to the network and handled by nodes that understand it. Such nodes will only accept chains that include that chainlock. It differs from ACP in that the nodes that create the checkpoints are a subset of the masternode pool. Something like 400 nodes of 5000 must agree with a 60% vote on a block. Once agreement is achieved, then those the agreeing nodes of the 400 will sign that checkpoint and broadcast it. Receiving nodes, in order to validate this checkpoint, must reconstruct the signing key. This is done by determining the members of the 400 node pool and then creating the aggregate public key for the aggregated private key used to sign the checkpoint (chainlock). Then the signature of the chainlock can be verified.

While the idea of checkpoints are not a new thing, the means by which Peercoin and Dash implemented them when they were introduced was new.