The phrase “private object” is one of the most important ideas in the Z00Z docs. It sounds abstract until you see what problem it solves. Most blockchain systems start by treating public state as the default truth and then ask how to hide pieces of it. Z00Z starts by treating value, requests, rights, and supporting evidence as things a wallet can hold and prepare locally before the public layer needs to know about them.
That is why the docs do not talk only about balances. A balance is a useful summary after settlement, but it is a poor beginner model for a system that is trying to separate possession, transfer preparation, settlement, and optional disclosure. Private objects make those stages visible.
Minimal Vocabulary For This Page
These terms are enough to read the rest of this page without jumping to the glossary first.
| Term | Plain-language meaning on this page | Why the distinction matters here |
|---|---|---|
| Wallet-local possession | The wallet can hold and prepare a private object before public settlement. | Ownership is not reduced to a public balance row. |
| Checkpoint | The public boundary that turns publication into final settlement. | It separates local handoff from network finality. |
| Settlement evidence | The narrow public proofs and records needed to verify a checkpointed transition. | It explains what becomes public without turning Z00Z into a public account graph. |
| Voucher | Conditional value, not final cash. | Not every private object is ordinary money. |
| Right | Authority to do something, not value. | Z00Z is about bounded control, not only hidden transfer amounts. |
| Payment request | A receiver-side object that tells the sender how the receiver wants the handoff structured. | The receiver is more than an address. |
| Shielded pool | A shared on-chain privacy domain; a Zcash-style shielded transfer is the simplest example. | It makes the comparison section concrete. |
What Counts As A Private Object
In the current corpus, you can think about five beginner-level examples:
- Asset objects for clean final value.
- Right objects for bounded authority without direct value.
- Voucher objects for conditional value that is meaningful without being the same thing as final cash.
- Payment request objects for receiver-led acceptance conditions and wallet safety.
- Evidence objects for proving, auditing, or challenging what happened without turning the whole wallet state into a public transcript.
These examples matter because they show that Z00Z is not only trying to hide a coin transfer. It is trying to define a wider grammar for private digital possession and later settlement.
Why The Object Model Changes The Category
When a wallet holds a private object, it is not merely caching a future public account change. It is holding the material that defines what can be transferred, what conditions apply, what receiver context matters, and what evidence may later need to be shown. That pushes real meaning into the wallet layer.
The result is a different first question. In a public account system, the first question is often “what does the global state say right now?” In Z00Z, the first question is closer to “what does the wallet currently possess, what can it prepare safely, and what must become public only if settlement is required?”
Public Accounts, Shielded Pools, And Z00Z Private Objects
This section is a comparison between three architectural families. It is not saying that they are minor variations of one shared state model. The point is the opposite: they overlap on settlement and privacy concerns, but they start from different primitives and teach the user to think about ownership in different ways.
On this page, shielded pool means the family of privacy systems where value moves inside a shared on-chain shielded domain. A Zcash-style shielded transfer is the easiest reference point. Amounts, note ownership, or transaction details may be hidden far better than in a public account chain, but the chain still hosts the shared transfer domain itself. Z00Z overlaps with that family on privacy goals, but the current corpus keeps making a different claim: Z00Z is not best described as “another shielded pool.” It is described as a wallet-local private-object system with later checkpointed settlement.
| Model | Default truth location | What moves first | What becomes public | What the user is really holding |
|---|---|---|---|---|
| Public account chains | Shared ledger | An account balance change | Much of the state, address, and activity history | Control over a public account relationship |
| Shielded-pool systems, including Zcash-style shielded transfers | Shared public chain with a shielded transfer domain | A private transfer inside the shared shielded domain | A public chain event with stronger hiding around the transfer internals | Control over privately spendable notes inside a shared shielded domain |
| Z00Z private-object model | Wallet-local possession plus later settlement | A typed private object package prepared locally | Narrow checkpointed settlement evidence | Possession of a typed object that can later be settled |
If you only remember one distinction, make it this one: a public account chain starts from a public account map, a shielded-pool system starts from a shared shielded transfer domain, and Z00Z starts from wallet-local possession of typed objects that later produce narrow settlement evidence.
This table is not meant to dismiss other designs. It is meant to show why Z00Z keeps insisting on the object metaphor. The system wants the user to think in terms of held objects and bounded publication, not only in terms of balances. If you need the broader comparison map, read Comparisons. If you need the wallet boundary behind the last row, read Wallet-Local Possession. If you need the object categories behind “typed object,” read Assets, Vouchers, And Rights.
Lifecycle From Local Possession To Evidence
The critical distinction is that publication happens after meaningful local state has already existed. The public layer does not invent the object from nothing. It verifies and settles a bounded transition involving an object that was already being held, routed, or constrained in the wallet layer.
Assets, Rights, Vouchers, Requests, And Evidence
Assets are the simplest starting point because they map to value most directly. The asset object is what lets Z00Z talk about cash while still refusing to make the public account graph the default truth surface.
Rights matter because many real systems need authority without pretending that every authority is value. A right can grant action, delegation, or bounded control while still staying conceptually different from cash.
Vouchers matter because conditional value is not the same as dirty or broken cash. The assets, rights, and vouchers paper spends real effort separating them so the system can support richer economic flows without pretending all value has identical guarantees.
The three-object model. Native cash stays clean. Conditional value lives in vouchers. Authority lives in rights.
Payment requests matter because the receiver is not just an address. The receiver is part of the acceptance boundary. A request can express what kind of object is expected, what safety rules should apply, and what a wallet should quarantine or refuse.
Evidence matters because private systems still need shared proof surfaces. Evidence objects let Z00Z explain how claims, receipts, and challenge material can exist without turning the protocol into a public diary.
Live Evidence Versus Target Architecture
The object model appears across the current corpus as a core architectural idea, but not every future object family should be described as equally mature. The strongest current reading is that private objects are the right mental model for understanding Z00Z, and that assets, rights, vouchers, requests, and evidence form the teaching surface for that model. The wider family of object types and service overlays remains target architecture and should stay labeled that way.
How Private Objects Change Wallet Responsibility
The object model also changes what a wallet is responsible for. In a public account world, a wallet can look like a convenience layer over shared state. In the Z00Z model, the wallet is closer to a safety boundary. It carries possession material, evaluates receiver context, shapes package creation, applies local policy, and may later decide how evidence or disclosure packages are handled.
That does not make the wallet identical to the protocol. It means the protocol and the wallet have different jobs, and the docs should describe both carefully. Once a reader understands that distinction, later pages about receiver flow, liability, selective disclosure, or developer APIs become much easier to read without confusion.
Why Not Just Call Them Balances
“Balance” is a useful result after settlement, but it is a weak teaching model before settlement. It hides the distinction between value, authority, request state, conditions, and evidence. Private objects keep those meanings separate long enough for the reader to see why Z00Z can support richer flows without pretending every object has the same guarantees or the same public footprint.
That separation is also what makes later policy, refund, audit, or rights stories readable. Without it, every advanced page would sound like a special case bolted onto one generic payment metaphor. The object language keeps those later distinctions honest from the start.
Why Readers Should Care
This page is not only for protocol readers. Builders need it because APIs and wallet flows make less sense when everything is translated into public-account terms. Researchers need it because comparison arguments depend on what is being compared. Legal reviewers need it because responsibility attaches differently when a system is built around wallet-local possession and optional service layers. Users need it because the wallet becomes a safety boundary, not merely a dashboard.
Read Next
- Read Live Versus Target Architecture next so you can separate core object claims from future object-family expansion.
- Read Main Whitepaper if you want the full protocol context for the lifecycle shown above.
- Jump into Protocol when you want deeper settlement and object-family 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 2 through 5 define the private-object thesis, canonical state objects, checkpoints, and wallet-local possession model summarized here.
- Uniqueness Whitepaper sections 2 through 5 explain why private rights transfer and wallet-local possession change the system category.
- Assets, Rights, And Vouchers Whitepaper sections 3 through 6 define the asset, voucher, and right split used by this page.
- Corpus Terminology And Abbreviations Reference section 3 provides the shared object vocabulary that keeps these explanations consistent.