Consensus

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.

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.

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.