Execution Architecture

Local Protocol is a single-chain EVM-compatible appchain that keeps global diffusion computation off the validator critical path.

Local Protocol is specified as a single-chain, EVM-compatible appchain with fast Byzantine finality. The core scaling strategy is to keep global diffusion computation off the validator critical path (claims + audits) and to rely on implementation-level parallelism for throughput.

One canonical reference frame per epoch

At epoch boundaries, the chain finalizes:

  • canonical snapshot roots (e.g., GraphRoot_t, SeedRoot_t),
  • a canonical randomness beacon (Rand_t),
  • and a canonical snapshot artifact identifier (e.g., SnapshotId_t) that auditors can fetch.

These commitments make diffusion claims deterministic to verify and keep audits objective.

Markets as logical domains

Markets are expressed as logical domains (e.g., marketId). marketId drives:

  • policy routing (maturity rules, caps, proof multipliers),
  • accounting (per-market cap vectors),
  • indexing and parallel execution hints.

Consensus and asset state remain global, so claims across markets reference the same epoch snapshot roots.

marketId is derived from execution: interaction records and commerce edges are valid only if their (marketContext, marketId) pair matches the canonical registry state and the market is ACTIVE.

See: Market Registry

Snapshot artifacts and data availability

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. Nodes can check availability via probabilistic sampling (DAS-style checks), as in systems like LazyLedger and common DAS primers (e.g., Celestia’s Data Availability Sampling).

Auditors fetch only the small Merkle openings needed to verify sampled walks.

See: Performance & Storage

Next Steps

Next, see how snapshot roots, randomness, and snapshot artifacts are finalized: