Architecture

Consensus

Local Protocol uses BFT Proof-of-Stake consensus to finalize blocks and epoch commitments, providing a canonical set of ledger facts.

Local Protocol uses standard BFT Proof-of-Stake consensus to finalize blocks and epoch commitments (snapshot roots and randomness). This provides a single, canonical set of ledger facts for claims and audits to reference.

See: State Model, Settlement, and Graph Commitments & Epoch Snapshots.

Quorum certificate (QC)
A QC is a supermajority signature (> of stake) attesting to a finalized block (and, at epoch boundaries, the epoch header). If you have the QC, you know the network has finalized those ledger facts.

What consensus finalizes (fact-layer)

Consensus finalizes ledger facts:

  • which transactions and SDLs are included
  • which escrow/dispute outcomes are finalized
  • which graph deltas (edge/attribute updates) are applied
  • a canonical market label per commerce interaction: marketId derived from execution and registry state (see note below)
  • the canonical epoch snapshot roots and
  • the canonical epoch randomness beacon
  • a canonical snapshot artifact identifier for authenticated snapshot data

Diffusion values (PageRank/PPR fixed points) are snapshot-relative interpretations and are not finalized as a global vector.

Consensus-critical label: canonical marketId (minimal registry)

With market-scoped seeds and caps, marketId cannot be a soft/user-chosen label. Otherwise, users could route interactions into whichever market has favorable teleport seeds or cap budgets.

The protocol therefore enforces one hard rule as a ledger fact:

  • marketId for an InteractionRecord (and the resulting commerce EdgeRecords) must be derivable from protocol facts: it must match MarketRegistry[marketContext].marketId at that block height, and the market must be ACTIVE.

Auditability: the epoch snapshot artifact SnapshotBlob_t includes the canonical MarketRegistry table for epoch , and binds SnapshotBlobHash_t, so verifiers can replay and check market attribution deterministically against the same snapshot commitments used for claims.

Randomness and audit selection
Audit sampling depends on unpredictability at commit time. The randomness beacon used for -derived sampling is designed to minimize bias (VRF-based or threshold designs), so no participant can systematically steer which claims are audited. A common appchain pattern is a threshold BLS beacon in the style of drand.

Claim-layer finality (optimistic diffusion claims)

Diffusion-derived reward claims are finalized through optimistic verification with mandatory audits. Consensus finalizes the fact-layer roots and randomness; the claim protocol defines transcript commitments, sampling, and fraud proofs.

See: Optimistic Diffusion Claims and Validator Audits & Penalties.

Chain
|
|-- Validator Set (600 total stake)
|   |-- V1 [stake: 100] [Block_t ✓]
|   |-- V2 [stake: 150] [Block_t ✓]
|   |-- V3 [stake: 200] [Block_t ✓]
|   |-- V4 [stake: 150] [Block_t pending]
|
|-- Finalized Block_t: {
|     SDLs: [...],
|     graph_deltas: {...},
|     epoch_roots: {GraphRoot_t, SeedRoot_t, Rand_t, SnapshotId_t},
|     QC: {signatures: [...], total_stake: 450/600}
|   }

Next Steps

This concludes the detailed breakdown of the Local Blockchain architecture. Explore further to understand how these concepts integrate with other features of the network.

Previous Settlement
Next Performance & Storage
Copyright © 2026