Skip to Content
DocsResearchMomentum & Account Chains20. Commitments and Proofs

Commitments & Proofs

The original can be found at Zenon Developer Commons .

Status: Proposed (audit map for what is provable)

This document enumerates what a verifier can prove from existing commitments and what new commitments would be required for compact proofs.

Definitions (informal)

  • Commitment: an on-chain hash/signature value that binds some data.
  • Proof: a data package that a verifier checks against commitments.
  • Decomposable commitment: supports partial inclusion proofs (e.g., Merkle root).

Proof taxonomy

Header proof

Proves the existence/validity of a Momentum header in the canonical chain:

  • signature verification
  • hash linkage
  • fork-choice
  • producer eligibility (requires committee proof strategy)

Inclusion proof (bounded list)

Proves a specific item is included in a bounded list committed by the header:

  • can be “include the full list” if bounded (no Merkle needed)
  • or Merkle-inclusion if a root exists

State delta proof

Proves a state change occurred as part of a committed delta:

  • easy if the commitment is decomposable (Merkle/vector)
  • hard if commitment is a flat hash over an opaque dump

Claims vs required commitments (table)

ClaimRequired on-chain commitmentExists today?Upgrade needed
Verify Momentum continuityheader hash-link + signatureYesNone
Verify producer signed headerproducer public key setPartialcommittee proof scheme
Verify account-block header list for a Momentumbounded header list or commitmentPartialformal bound + canonical encoding
Verify full state patch for a MomentumChangesHash = H(full patch)Yes (if defined)None
Verify partial state delta (per-account slice)decomposable delta commitmentNoMerkle/vector commitment
Verify committee membership at height Hcommittee commitment per epoch/heightNo/Partialcommittee root + proofs
Anchor auxiliary proofs (future)header Data field / extra commitment slotReservedconsensus rule to enable

Minimal credible strategy

MVP (verifiable today-ish):

  • headers + signatures + bounded lists + full-patch verification (slow path)

Phase 2 (requires upgrades):

  • decomposable delta commitments
  • committee root commitments
  • structured proof bundles

Design rules

  1. Any third-party “bundle server” is untrusted.
  2. Every bundle MUST be checkable against a canonical on-chain commitment.
  3. If a claim cannot be checked, it MUST be labeled Speculative.
Last updated on