Terminology

Z00Z becomes confusing fast if you translate every unfamiliar word back into public-account language. This page exists to stop that drift early. It does not replace the full terminology reference. It gives you a learn-facing glossary for the words that show up again and again across the corpus.

The format is intentionally close to the glossary table in the Main Whitepaper. Read it as a working reference, not as an essay. The list is longer than the Main Whitepaper appendix because Learn needs one place where a new reader can scan the most reused terms without jumping across five papers first. If a term here still feels too compact, jump to the whitepaper or the terminology reference before guessing.

Beginner Glossary

Term	Meaning In This Page
`ActionPool`	The bounded set of actions that a policy-shaped object is allowed to perform.
`Agent spending envelope`	A private, task-scoped budget and fee right for an agent without full wallet authority.
`Asset`	A final-value object in the Z00Z model. It is not a public account balance row.
`AssetLeaf`	A public, checkpointed settlement object that represents a confidential asset right under the canonical asset-tree state model.
Asynchronous rights settlement	A pattern where wallet-local possession or local acceptance can happen before publication, while authoritative settlement remains checkpoint-bound.
`BridgeInTx`	The integration-side transition that brings an external deposit or lock into a private internal right.
`BridgeOutTx`	The integration-side transition that consumes an internal right and authorizes external release or redemption.
Canonical asset path	The deterministic storage path used to prove that an `AssetLeaf` is present under the accepted state root.
Checkpoint	The validation boundary that commits ordered publication into a replay-safe state transition.
Checkpoint anchor	The public reference that helps make a checkpoint auditable and replay safe.
Claim replay record	The replay-protection artifact used for claim-domain settlement paths.
`ClaimTxPackage`	The wallet-side canonical envelope for claim-domain settlement flows.
Compliance-profile wallet	A wallet or interface that adds disclosure, retention, warning, or jurisdiction-specific behavior above the core protocol.
Corporate Archive	A long-lived record kept outside the base protocol for audit, tax, accounting, or enterprise review.
Data availability	The layer that keeps required published data reachable for later validation or evidence review.
`EncPack`	The encrypted payload surface attached to confidential ownership or receiver metadata.
Evidence Package	A structured bundle of transaction, proof, policy, and supporting metadata for later review.
`FeeEnvelope`	The processing guarantee that answers who pays fees, in what asset, and under which limit.
`FraudProof`	The conflict-triggered evidence object that proves a punishable misuse, replay, or policy violation.
Issuer	An external party responsible for asset-backed or rights-backed claims above the core protocol.
`LiabilityDomain`	The hidden responsibility scope attached to delayed, offline, or autonomous execution.
`Locker`	The external custody surface that holds an asset outside Z00Z while Z00Z privately moves the internal right.
`LockerID`	The internal right or handle representing control over an externally custodied asset surface.
Neutral protocol	The posture in which the core system validates correctness without operating user financial services for them.
Nullifier	A domain-separated anti-replay artifact. It is about replay safety, not a generic public notion of spentness.
Open research	A lane where important questions remain unsettled or still require validation.
`PaymentRequest`	A wallet-side receive-intent object that carries receiver parameters and handoff context.
Privacy budget	The practical idea that privacy can be spent through behavior, timing, metadata, repeated counterparties, and disclosure choices.
Privacy threat model	The visibility boundary that separates hidden wallet-local ownership meaning from public settlement evidence, operational metadata, service disclosures, and fraud-triggered reveal.
Publication	The act of moving bounded artifacts toward shared validation and settlement.
Public-claim boundary	The rule that technically ambitious design still needs safe, accurate phrasing about what is live, who owns a promise, and who carries responsibility.
`ReceiverCard`	A receiver-facing input package used by the live request-bound receive flow.
`RewardAuthorization`	The bounded authorization object that bridges review into private useful-work payout.
Right	An authority object without inherent value. It lets the protocol move bounded control, not only money-like value.
`RightLeaf`	The live HJMT settlement object for a confidential non-coin right under the current generalized settlement contract.
Selective audit	The narrower evidence mode for one reviewer, enterprise, or policy purpose.
Settlement evidence	The public commitments, deltas, proofs, roots, and publication artifacts needed to verify a transition.
Selective disclosure	A scoped disclosure capability that reveals information to a defined party without turning the whole protocol into a surveillance surface.
`SettlementLeaf`	The generalized HJMT settlement leaf family over terminal cash, rights, and vouchers.
`SettlementPath`	The live canonical storage path for one committed settlement leaf in the generalized settlement tree.
Soft confirmation	A pre-checkpoint acknowledgement that a package or batch has entered the publication path but is not yet final settlement.
Spendable capability object	A broader private right object that can represent machine, service, access, compute, data, or mandate authority.
Wallet-local possession	Ownership material and transfer preparation that remain in the wallet until publication turns them into settlement evidence.
Steward	A foundation, team, or bounded coordinating body that may maintain work but must not be confused with the protocol itself.
`Tag16`	A short scan or routing tag used with owner metadata and encrypted payload lookup.
Target architecture	A corpus-defined intended system shape that should not be described as already shipped.
`TxPackage`	The wallet-side canonical envelope for ordinary transfer preparation.
Validator	A role that verifies whether candidate artifacts satisfy protocol rules.
Voucher	A conditional-value object. It can carry bounded redemption or policy without becoming the same thing as final cash.
`VoucherLeaf`	The live settlement object for one conditional-value voucher in the current generalized settlement contract.
Watcher	A role that observes and reports evidence, inconsistencies, or challenge surfaces without replacing settlement authority.
`WorkPackage`	The canonical submission envelope for a claimed useful-work contribution.

Do Not Confuse These Pairs

Do not confuse	Why the distinction matters
Asset vs right	One carries value; the other carries authority.
Voucher vs right	A voucher can encode conditional value; a right grants bounded action or control.
Data availability vs settlement	Being publicly reachable is not the same as being final truth.
Privacy vs anonymity	Narrow visibility and scoped evidence are not the same as claiming total untraceability.
Watcher vs validator	Watchers observe and report; validators decide rule compliance.
Publication vs checkpoint	Publication starts a shared path; checkpoint closes it into settlement.

How To Read New Terms Safely

When you meet a new term, ask three questions:

Is this a protocol term, a service term, or a maturity term?
Does it change what the wallet knows, what the network knows, or what the public can verify?
Is the corpus describing this as live evidence, target architecture, or open research?

Those questions will keep you aligned even before you learn the entire terminology inventory.

Abbreviation Posture

The corpus allows abbreviations such as PQ, DA, TxPackage, and AssetLeaf because they compress recurring technical meaning. It does not use abbreviations as a way to hide ambiguity. A good rule for new readers is to use the full phrase once, then accept the shorter term once the concept is clear. That keeps docs readable without weakening the architecture.

Responsibility Map

Vocabulary is also a responsibility map. When a page says protocol, it should not quietly mean wallet company, issuer, operator, or bridge service. When a page says disclosure, it should not quietly mean that the core protocol always knows private state. When a page says asset, it should not quietly mean every external promise made by a service layer. The glossary matters because bad nouns quickly become bad responsibility claims.

That is why Z00Z keeps separate words even when a looser product narrative might sound easier. Precision lets the reader ask the right follow-up question: who owns the claim, who holds the evidence, who can validate it, who can challenge it, and who is only a service layer above the core? If a page blurs those boundaries, the page usually starts to overclaim maturity, privacy, settlement, or legal posture.

When you see this kind of term	Main question to ask	Safe reading
Protocol term	Who can validate it?	Checkpoint, typed evidence, and shared rules decide it.
Wallet term	Who knows the private meaning?	The wallet carries local possession, receiver data, and local interpretation until publication is needed.
Service term	Who owns the promise?	Issuers, bridges, merchants, auditors, and archives own their own promises above the protocol.
Maturity term	Is this live now?	`Target architecture` and `open research` are not shipped facts.
Disclosure term	Who gets to see what?	Disclosure should be scoped, purposeful, and narrower than public visibility.

This is also why the table above mixes object words, settlement words, privacy words, network words, and maturity words in one place. The goal is not just to define each noun in isolation. The goal is to stop the reader from importing one word into the wrong responsibility layer and then misreading the rest of the page.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

Corpus Terminology And Abbreviations Reference sections 3 through 6 and section 8 are the primary authority for the term families, abbreviations, aliases, and cross-paper ownership model used on this page.
Main Whitepaper appendix A and sections 3 through 6 are the direct glossary-style anchor for AssetLeaf, TxPackage, ClaimTxPackage, checkpoint language, wallet-local possession, privacy boundaries, and disclosure vocabulary in the core protocol thesis.
Uniqueness Whitepaper sections 4 and 5 explain why naming precision changes the public category claim instead of acting as mere glossary polish.

Z00ZBlockchain