Games & Graphs

Graph Commitments & Epoch Snapshots

One canonical epoch snapshot commitment per epoch — graph, seed, and artifact roots that serve as the reference for diffusion-derived claims.

Local Protocol finalizes one canonical epoch snapshot commitment per epoch. The ledger commits to snapshot roots and uses them as the canonical reference for any diffusion-derived claims.

Epochs

Time is divided into epochs . Each epoch defines:

  • a committed graph snapshot root
  • a committed teleport/seed root
  • a canonical randomness beacon
  • protocol parameters
Cap vector semantics

The epoch cap is not a single number. It’s a cap vector:

  • : max claimable output per user/identity per epoch
  • : max claimable output per market/domain per epoch
  • : optional protocol-wide backstop (“fuse”)

These caps are deterministic safety rails: even if audits miss something briefly, total extractable value is bounded per user and per market.

Intuition
A snapshot is like taking a photo of the graph once per epoch and publishing a hash of it. Later, anyone can prove facts about that “photo” (this edge existed, this node’s out-weight sum was X) using short inclusion proofs.
Related work
Commitment trees / authenticated datasets via Merkle trees.

Commitment structure

Partition nodes into shards . Each shard publishes:

The global graph root is:

Seed commitments (market-relative teleport)

Teleport is market-relative: each market marketId = m has its own protocol-committed teleport distribution .

To keep the fact layer compact while supporting many markets, the snapshot commits a root of roots:

Each per-market seed root commits to the seed-weight table for that market:

Proof-friendly teleport sampling (optional)
For O(1) verifiable teleport sampling in transcripts, the snapshot artifact can also include a per-market alias table commitment (e.g., ) for sampling from .

Snapshot artifact identifier (SnapshotId)

Audits require authenticated access to snapshot data (NodeRecords / EdgeRecords / alias tables). Each epoch therefore finalizes a Snapshot Artifact that is content-addressed and publicly retrievable.

MarketRegistry is part of the snapshot artifact (required)
To make market membership auditable, SnapshotBlob_t must include the canonical MarketRegistry table for epoch : marketContext → (marketId, vault, feeRouter, flags). Because binds SnapshotBlobHash_t, auditors can verify MarketRegistry lookups against the same snapshot commitments used for graph and seed verification.

At epoch , let SnapshotBlobHash_t be the content hash of the snapshot artifact bytes in the data layer (see Performance & Storage). The chain commits:

Proof-friendly snapshot packaging

To support efficient verification (including random-walk transcript checks), the snapshot is packaged in structures that are easy to open with Merkle proofs.

Intuition
These records are the index that makes audits cheap: a verifier doesn’t need the whole graph—just a few Merkle openings for the edges touched by a sampled walk.
Related work
Authenticated data structures (Merkleized key–value stores and adjacency lists) used in light-client verification.

NodeRecord

For node :

  • nodeId: Address
  • marketOutIndexRoot: bytes32 — Merkle root of per-market outgoing-index entries keyed by marketId
  • nodeAttrRoot: bytes32 — root of node attributes (identity proofs, reputation flags, maturity gates)

Each per-market outgoing-index entry (opened by a Merkle proof from marketOutIndexRoot) is:

OutIndex(m)

  • marketId: uint32
  • outWeightSum: uint128 — for this market
  • adjacencyRoot: bytes32 — Merkle root of outgoing edges in this market
  • aliasRoot: bytes32 — Merkle root of alias table for O(1) sampling of outgoing edges in this market
  • degree: uint32 — number of outgoing edges in this market
Intuition
A node’s outgoing edges are partitioned by market. When verifying a walk step for market , a verifier opens OutIndex(m) and then verifies the sampled neighbor using that market’s aliasRoot + adjacencyRoot.

EdgeRecord

For an outgoing edge :

  • dst: Address
  • weight: uint128
  • edgeAttrRoot: bytes32 — service proof / dispute state commitments
  • marketId: uint32 — required market tag for commerce edges (“this edge belongs to market ”). marketId MUST match the registry-assigned marketId of the producing MarketContext at that block height.
  • flags: uint32 — dispute outcomes, maturity gating, etc.

Alias tables (recommended)

For efficient verifiable sampling from , the protocol supports per-node, per-market alias tables (via OutIndex(m).aliasRoot):

  • alias entries deterministically derived from the market-scoped adjacency list
  • the table commits to sampling structure enabling O(1) verification of a sampled neighbor within the market context
Intuition
A random walk repeatedly asks: “from , which neighbor do I jump to next?” Alias tables are a standard trick to sample from a discrete distribution in O(1) time.
Related work
The alias method: Walker (1977) and Vose (1991).

Related

Snapshot artifacts and data availability

Nodes can check availability via probabilistic sampling (DAS-style checks), as in LazyLedger and common DAS primers (e.g., Celestia’s Data Availability Sampling).

See: Performance & Storage

Previous Snapshot-Relative Diffusion
Next Optimistic Diffusion Claims
Copyright © 2026