Finality Checkpoints

Citrate achieves transaction finality in approximately 12 seconds through a BFT (Byzantine Fault Tolerant) checkpoint system layered on top of GhostDAG's block production. Each checkpoint does more than confirm transactions -- it triggers the network's cooperative learning cycle, aggregates LoRA adapters, and updates the meta-model.

Why Checkpoints?

GhostDAG provides fast block production (1-second intervals with k=18 parallelism), but individual blocks are not final. Like any DAG or chain protocol, there is a window during which block ordering could theoretically shift. Finality checkpoints close that window definitively.

The checkpoint system uses a classical BFT voting mechanism: once 2/3 of validators (weighted by stake) sign a checkpoint, the blocks up to that point become irreversible. No reorganization can undo a finalized checkpoint, even if an attacker controls up to 1/3 of the network's stake.

Checkpoint Timing

Checkpoints are produced at regular intervals, targeting one every ~12 seconds. This cadence balances three concerns:

User experience -- 12 seconds is fast enough for interactive applications while providing strong finality guarantees.
Learning cycle -- Each checkpoint triggers a Paraconsensus learning round, and the meta-model needs enough signal to produce meaningful updates.
Network overhead -- BFT voting requires all validators to exchange signatures, so overly frequent checkpoints would saturate bandwidth.

Block production:  ████████████████████████  (1-second intervals, k=18 parallel)
                   |           |            |
Checkpoints:       CP-N        CP-N+1       CP-N+2
                   (~12s)      (~12s)        (~12s)

Each checkpoint finalizes all blocks since the previous checkpoint.

The 2/3 Honest Assumption

The checkpoint system operates under a standard BFT assumption: the protocol is safe as long as at least 2/3 of the total validator stake is controlled by honest participants. This means:

With honest supermajority: Checkpoints finalize correctly and the learning cycle operates normally.
With 1/3 to 2/3 honest: Checkpoints may stall (liveness failure), but no incorrect checkpoint can be produced (safety preserved).
With less than 1/3 honest: Safety guarantees are lost. This threshold is standard across BFT protocols (Tendermint, PBFT, Ethereum's Casper).

What Happens at Each Checkpoint

A finality checkpoint is not just a signature -- it triggers a cascade of operations:

1. Transaction Finality

All blocks between the previous checkpoint and the current one are finalized. Their transaction ordering becomes permanent and irreversible.

2. Meta-Model Update

The Paraconsensus learning cycle runs. Mentorship signals collected since the last checkpoint are aggregated, contradictions are processed through the paraconsistent lattice, and the meta-model parameters are updated.

3. Adapter Aggregation

LoRA adapter updates submitted by nodes during this period are merged using federated averaging. The resulting aggregated adapter is committed to chain state and becomes available to all nodes.

4. Reputation Update

Blue scores are recalculated based on each node's contributions during the checkpoint period. Nodes that provided accurate inference results and valid mentorship signals see their scores increase; poor performers see theirs decrease.

5. Fee Settlement

Inference fees accumulated during the period are distributed to model providers, validators, and the protocol treasury according to the fee schedule.

Checkpoint Structure

Each checkpoint contains:

CheckpointData {
    number:           uint64       // Sequential checkpoint number
    block_hashes:     []Hash       // All finalized block hashes
    state_root:       Hash         // Post-finality state root
    meta_model_hash:  Hash         // Updated meta-model parameters
    adapter_root:     Hash         // Merkle root of aggregated adapters
    validator_sigs:   []Signature  // 2/3+ validator signatures
    timestamp:        uint64       // Checkpoint creation time
}

Relationship to Block Confirmation

Before a checkpoint finalizes a block, that block has probabilistic confirmation based on its depth in the DAG. More blue descendants mean higher confidence. The checkpoint converts this probabilistic confidence into cryptographic certainty.

Confirmation Level	Mechanism	Time	Guarantee
Optimistic	DAG depth	~3 seconds	Probabilistic (safe for low-value)
Final	BFT checkpoint	~12 seconds	Irreversible (2/3 honest assumption)

Applications that can tolerate probabilistic finality (e.g., reading public data) can act on blocks immediately. Applications that require hard finality (e.g., token transfers, model registration) should wait for checkpoint inclusion. We designed this two-tier system so developers can choose the right tradeoff for their use case.