Hashing Reference

RespHash, LtHash, and App Hash

This page is the compact hashing reference for the repo: what is confirmed about the LtHash pipeline, what is chain-scoped in RespHash, what reaches `VoteAppHash`, and what is still open. The goal is to separate "algorithm cracked" from "full parity closed" so the docs do not overclaim.

LtHash Serialization Note App Hash Note State Hash Call Graph Open Claims

LtHash pipeline confirmed

RespHash backend split confirmed

Mainnet serializer parity still open

Heartbeat concise hashes confirmed

1. Hash Pipeline

The current confirmed pipeline is: response serialization feeds a per-category LtHash accumulator, then the final accumulator state is condensed into the app-hash and vote surfaces. The pipeline itself is cracked; the remaining gap is exact response-family parity.

flowchart TD A[Execution produces response objects] --> B[rmp_serde serialization] B --> C[blake3 XOF to 2048-byte element] C --> D[LtHash16 paddw u16 accumulator] D --> E[Per-category running state] E --> F[Finalize accumulator state] F --> G[SHA-256 concise digest] G --> H[VoteAppHash and heartbeat surfaces]

Stage	Current truth	Status
LtHash element pipeline	`rmp_serde → blake3 XOF (2048B) → paddw u16 → SHA-256`	confirmed
RespHash backend mode	Local code tracks `Mainnet` and `Testnet` backends explicitly.	confirmed
Mainnet response families	Not all mainnet-specific serializer families are wired end-to-end yet.	open

2. Accumulator Surface

Surface	Current fact	Notes
L1 accumulators	14 categories are tracked in the current paper surface.	Settlement, validator, signer, liquidation, vault, BOLE, and other L1 lanes remain separate.
EVM accumulators	3 categories: accounts, contracts, storage.	These are the concise-hash families visible in heartbeat snapshots.
Heartbeat digest	`hash_concise` is a compact digest, not the raw 2048-byte accumulator.	Public surfaces should not imply that the heartbeat carries full L1 hash state.

3. Backend Split

The repo now treats RespHash backend choice as chain-scoped. That is important because "testnet binary path observed" is not the same thing as "mainnet serializer parity implemented."

Question	Current answer
Is the backend split real?	Yes. The docs and code both now carry a mainnet/testnet RespHash distinction.
Does backend mode mean full parity?	No. `RespHashMode::Mainnet` is backend selection, not proof that every mainnet response shape is already closed.
What is the main open gap?	Full mainnet serializer families plus the exact local field/value wiring for the still-open lanes.
What facts are now closed?	G-family success hashes use the 1-field H-shape, the 3-field G-shape is error-only, and fills use a separate 18-field payload rather than ordinary ledger-update wrapper fields.

{"status":"success"} is the success shape for the hybrid G-family actions.
{"status":"err","success":false,"error":"..."} is the corresponding error-only shape.
coin and feeToken belong to API/user-fill wrapper surfaces, not to the hashed fill payload itself.

4. VoteAppHash and Network Surfaces

VoteAppHash is the validator agreement surface for the finalized digest.
Heartbeat snapshots expose concise EVM hash summaries, not the full LtHash lattice state.
The docs should keep "accumulator naming", "heartbeat concise hashes", and "vote hash" as separate ideas.

Execution response
  → category accumulator
  → final app-hash material
  → VoteAppHash

Heartbeat path
  → concise EVM hash summaries
  → peer / sync visibility
  → not a full replay substitute

5. What Is Still Open

Exact mainnet serializer shapes for the remaining response families.
Exact local value derivation for the still-open fill fields and a few transfer-style deltas.
Replay proof that the current backend split moves the first mismatch later, not just labels it better.