HJMT matters because it is where abstract privacy language has to become durable settlement structure. Once Z00Z stops speaking only about wallet-local possession and starts speaking about checkpointed state, it needs a way to explain what is actually committed, how a right or voucher survives in canonical state, and why replay protection belongs to storage and checkpoint application rather than to a public balance table.
What This Research Lane Owns
HJMT research is best treated as the storage-and-settlement depth lane for four recurring questions.
| Question | Why HJMT matters |
|---|---|
| What kind of leaf does canonical state actually commit? | It keeps the corpus grounded in typed settlement objects rather than vague balance stories |
| Why does replay protection belong to state continuity, not only to package checks? | It explains why local verification and final settlement are not the same event |
| How can the model widen from assets to rights and vouchers? | It provides the structural lane for broader right objects without changing the core settlement contract |
| Why are performance claims around state transition expensive and maturity-sensitive? | Tree shape, proof size, batching, and recovery all affect what can honestly be claimed |
This is why HJMT should be read as research depth, not as a shortcut to “storage is solved.”
The Safe Present-Tense Reading
The current corpus gives a defensible present-tense story even without pretending every storage extension is already finished.
| Present-tense point | Safe wording |
|---|---|
| Z00Z settles typed objects, not public accounts | Canonical state is described through leaves, paths, checkpoints, and replay-safe transitions |
| Local package verification is not final settlement | Storage and checkpoint continuity still decide whether a transition becomes authoritative |
| The leaf family is widening conceptually | Rights and vouchers are part of the direction, but the corpus still treats some of that widening as target architecture |
| Performance and sharding discussion are evidence-sensitive | Benchmarks and design notes inform direction, but do not by themselves prove production-scale guarantees |
That posture keeps HJMT aligned with Main Whitepaper, which repeatedly separates wallet-side preparation from canonical settlement.
Why HJMT Shows Up Outside Storage Discussions
Readers sometimes assume HJMT only matters to a storage engineer. The corpus suggests a broader role.
First, it matters to privacy claims. If a reader does not understand that only settlement evidence becomes public, they may accidentally assume the system is hiding an ordinary account ledger. HJMT is one of the places where the corpus explains that the public side is narrower and more typed than that.
Second, it matters to liability and rights expansion. Linked Liability Whitepaper assumes that rights, receipts, and later fraud proofs can attach to a structured settlement surface rather than to an undifferentiated balance map. HJMT is part of the reason that claim is coherent.
Third, it matters to maturity language. The more a page depends on rights leaves, vouchers, or generalized settlement families, the more carefully it should separate live boundary from target widening.
What HJMT Research Does Not Prove By Itself
The research lane is valuable, but it should not be asked to prove more than it can.
| Overclaim to avoid | Safer replacement |
|---|---|
| “The full generalized rights tree is already production-complete.” | “The corpus has a coherent widening path from asset-centric settlement toward broader right families.” |
| “Storage design alone proves throughput at scale.” | “Storage design shapes the cost surface that benchmarks and later implementation work still have to validate.” |
| “HJMT means every policy family is already live.” | “HJMT provides the structural lane for future settlement families, while policy maturity still varies.” |
| “A tree diagram proves recovery and operator safety.” | “Recovery, sharding, and publication resilience still need supporting operational evidence.” |
This page is therefore less about celebrating one tree structure and more about teaching the reader how to keep tree research proportional to actual evidence.
How To Use This Lane With Other Papers
For most readers, HJMT makes the most sense in combination with one core paper and one companion paper.
| Read together with… | Result |
|---|---|
| Main Whitepaper | You get the baseline story of typed objects, checkpoints, and state continuity |
| Linked Liability Whitepaper | You see how delayed execution and later fraud handling need a structured settlement surface |
| Benchmarks | You can separate storage-shape reasoning from measured performance claims |
| Glossary | You can keep terms such as RightLeaf, SettlementLeaf, and SettlementPath consistent |
That combination is usually enough to write careful prose about storage and settlement without importing stale or overly confident language from older technical notes.
Path Proof And Root Continuity
The useful mental model is a continuity argument, not a tree-brand argument. A wallet can prepare a candidate transition locally, but the candidate does not become authoritative merely because the package is well formed. The settlement path identifies where the typed object belongs. The leaf carries the object family and committed state. The root binds the leaf set at the checkpoint boundary. The evidence package connects spent and created deltas to that root transition. If any part of the path, leaf, root, or evidence does not line up, the system should not treat the transfer as final settlement.
This is why HJMT language must stay mature and narrow. The corpus can discuss HJMT-style thinking as the storage and proof concept for settlement roots, replay protection, and generalized object families. It should not imply that every future voucher, right, sharding, recovery, or archival feature is already production-complete. When a docs page describes a local implementation proof, it needs live code anchors or deterministic tests. When it describes the paper-level architecture, it should say that the corpus defines the storage lane and that implementation evidence controls current maturity.
Replay Boundary Checklist
Use three checks when applying this page. First, identify the object: asset, right, voucher direction, liability object, or fee-support object. Second, identify the state boundary: wallet-local payload, package envelope, settlement leaf, checkpoint root, or external service record. Third, identify the replay rule: package validity, spent-state exclusion, nullifier or liability-domain binding, or checkpoint-root continuity. The HJMT page becomes misleading if those checks are collapsed into one vague “tree proof” phrase.
Evidence Boundary
HJMT-style diagrams are explanatory, not proof by themselves. A root-continuity diagram can show why replay safety needs state continuity, but it does not prove benchmark cost, recovery behavior, archival compaction, or production operator resilience. A docs page should therefore separate conceptual evidence from implementation evidence. Conceptual evidence comes from the main whitepaper, the assets-rights-vouchers paper, and the linked-liability paper. Implementation evidence comes from source files, tests, deterministic simulations, and benchmark records. If a sentence says “the implementation does,” it needs the second class of evidence.
The same rule applies to rights and vouchers. A generalized object model may be coherent at the paper layer while individual object families remain uneven at runtime. The HJMT page should help readers see where the shared settlement-root contract is heading without pretending that every leaf family, policy surface, or recovery mode is equally mature today.
Read Next
Read Storage HJMT for developer-facing implementation anchors, Object Lifecycle for the protocol flow, and Linked Liability when offline conflict changes the evidence boundary.
Evidence and Further Reading
- Main Whitepaper sections 3, 4, and 8 are the primary current-corpus source for canonical state objects, rollup architecture, publication, checkpoints, and implementation-status language.
- Assets, Rights, And Vouchers Whitepaper section 9 is the source for the one settlement-root contract and semantic object view across assets, rights, and voucher direction.
- Linked Liability Whitepaper section 7 shows why exculpability, selective reveal, and domain scoping need a structured settlement surface.
- Corpus Terminology And Abbreviations Reference is the authority for
RightLeaf,VoucherLeaf,SettlementLeaf,SettlementPath, and related storage nouns. - Privacy Threat Model And Metrics is useful when you need to explain how internal private movement relates to public settlement evidence without turning the tree surface into a public behavior graph.