The main whitepaper is the center of gravity for the public Z00Z story. If you need to know why the system exists, what its core objects are, why checkpoints matter, how privacy and settlement fit together, or where the architecture opens into later rights and ecosystem lanes, this is the paper that sets the terms.
It should also be read with the right posture. The main whitepaper is the canonical thesis document, but it mixes live core boundaries, target architecture, and future expansion lanes. Read it as a map, not as one undifferentiated production claim.
That does not mean it should be read straight through with no strategy. The paper is broad by design. It moves from category and protocol thesis into settlement objects, privacy, external assets, governance, legal boundary, native asset posture, and roadmap language. If you try to absorb all of that in one undifferentiated pass, you are likely to blur together what the paper treats as live core direction, target architecture, or optional expansion vectors.
This page is therefore a guided reading companion. It tells you what each major section controls, what question you should bring into it, and when to jump out into a companion paper instead of staying inside the main document longer than necessary.
What The Main Paper Controls
| Section family | What it owns | Why it matters |
|---|---|---|
| Sections 1 and 2 | Why Z00Z exists, why public account chains leak too much by default, and how the category differs from privacy-only narratives. | This is the shortest rigorous explanation of the system. |
| Section 3 | Canonical state objects, transaction packages, replay boundaries, and checkpoints. | These are the nouns every later page depends on. |
| Sections 4 through 6 | Rollup architecture, digital cash, offline ownership, privacy, and selective disclosure boundaries. | This is where the system-level behavior becomes concrete. |
| Sections 7 through 11 | External assets, publication/scalability, security, governance/legal boundary, and ecosystem posture. | These sections widen the thesis without changing the core object model. |
| Section 12 and appendices | Implementation status, roadmap split, glossary, and comparison boundary. | This is where maturity discipline enters the reading flow. |
A Practical Reading Sequence
If you are reading the main paper for the first time, use this order.
- Read sections 1 and 2 slowly. They set the vocabulary for everything else.
- Read section 3 with a notebook mindset. You are collecting the canonical nouns: object, package, checkpoint, evidence, replay boundary.
- Read sections 4 through 6 for system behavior. This is where the architecture turns from a slogan into an interaction model.
- Decide whether you need breadth or depth next. Breadth means continue into sections 7 through 11. Depth means jump into a companion paper that owns the exact concept you care about.
- Read section 12 before you repeat claims elsewhere. It keeps the architecture honest by separating what is already live from what remains target design.
That sequence minimizes the most common reading error: understanding the ambition of the system before understanding the tightness of the core model.
Section-By-Section Reader Goals
| Main paper section | Reader goal | Leave with this understanding |
|---|---|---|
| 1. Why Z00Z | Understand the problem being solved. | Public state is powerful for shared verification and weak for cash-like privacy. |
| 2. Protocol Thesis | Get the category sentence right. | Z00Z is organized around private objects, local possession, and checkpointed settlement evidence. |
| 3. Protocol Core | Learn the canonical nouns. | Objects, packages, and checkpoints are not decorative terms; they move the truth boundary. |
| 4. Rollup Architecture | Understand publication and verification flow. | Publication, validation, and settlement are related but not identical. |
| 5. Digital Cash And Offline Ownership | See why wallet-local possession matters. | The wallet is a control boundary, not only a user interface. |
| 6. Privacy And Selective Disclosure | Understand the privacy claim carefully. | Privacy is structural, while disclosure is scoped and optional. |
| 7 to 11 | Understand how the thesis extends outward. | External assets, security, governance, legal posture, and ecosystem design all build on the same core model. |
| 12 | Learn maturity discipline. | The paper itself distinguishes live surfaces from target architecture. |
Glossary Starter Before You Dive In
If you only stabilize a few terms before reading, make them these:
- Checkpoint
- The validation boundary that turns a published candidate transition into final settlement.
- Wallet-local possession
- The rule that ownership material and transfer preparation stay local until publication becomes necessary.
- Settlement evidence
- The public roots, deltas, proofs, and references that let observers verify a finalized transition.
- TxPackage
- A bounded wallet-side transfer or claim package that can later be validated, published, and settled.
- Selective disclosure
- A scoped wallet or service capability layered on top of privacy, not a core protocol right to inspect private state.
These terms are enough to keep the paper coherent while you read. You can fill in the larger vocabulary later in Terminology.
When To Leave The Main Paper
One of the best reading habits is knowing when the main paper has done enough.
Leave for the terminology reference when you find yourself repeatedly decoding names instead of following the argument. Leave for the legal architecture paper when service separation, disclosures, responsibility, or public-claim limits become the main issue. Leave for the privacy threat model when you need a real adversary analysis instead of a high-level privacy thesis. Leave for the post-quantum migration paper when you need precise communication about current cryptographic boundaries and migration gates. Leave for the DAO or tokenomics papers when governance and treasury design stop being a side issue and become the main topic.
This does not weaken the main paper. It shows that the corpus has proper authority boundaries.
Live Evidence, Target Architecture, And Companion Papers
The main paper is strongest when you want the whole-system argument. It is not the best place to pretend every detail has identical maturity. Some surfaces are already treated as current or live direction. Others are explicit expansion paths. Still others are deliberately handed off to companion papers so the main thesis can stay focused.
Reader Types And Best Exit Paths
Different readers should leave the main paper at different times. A builder may leave after sections 3 through 6 and continue in the developer or protocol docs where local repo anchors become more concrete. A legal or communications reader may jump sooner into the legal architecture paper after sections 10 through 12. A privacy reviewer may stop after section 6 and continue into the privacy threat model rather than reading the rest of the paper as if it were a substitute threat analysis. A strategy or ecosystem reader may follow the later sections and then branch into tokenomics, DAO, or use-case papers.
Thinking this way turns the main whitepaper into a hub rather than a monolith. It helps you read with purpose instead of with guilt about not consuming every page in one pass.
That means a careful reader should always ask two questions while reading:
- Is this section explaining the core protocol direction, or a later extension?
- Does a companion paper own the exact boundary I care about more precisely?
Those two questions prevent overclaiming without forcing the reader to become a lawyer on every page.
Read Next
- Read Terminology if the paper’s nouns still need a stable beginner glossary.
- Read Roadmap before you turn section 12 into external product or launch claims.
- Jump into Protocol when you want to follow the object and settlement model with more local detail.
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.
- Main Whitepaper sections 1 through 12 are the direct authority for this guide, especially sections 2, 3, 6, and 12.
- Corpus Terminology And Abbreviations Reference sections 3, 5, and 8 support the glossary starter and the claim that the corpus has separate concept owners.
- Uniqueness Whitepaper section 10 and section 11 support the reading discipline around comparison boundaries and final positioning.