Z00Z logo

Z00ZBlockchain

FAQ

Common questions about Z00Z category, privacy, settlement, wallets, tokens, use cases, maturity, support, and safety boundaries.

Fast Routing Table

If you are asking about… Short answer Best next page
What Z00Z is A privacy-preserving settlement protocol, not a universal service stack What Is Z00Z
Whether a feature is live Check the page’s maturity note and evidence anchors Live vs Target
Lost backups or wallet recovery Support does not have a hidden recovery switch Wallet Recovery Safety
Security or privacy incidents Use the sensitive-reporting path, not ordinary public support Responsible Disclosure
Repo-local docs or build failures Follow the local verification path first Troubleshooting

Use the table to choose the first route. Use the deeper answer sections below when the short route still leaves a trust, maturity, or safety boundary unclear.

What is Z00Z in one sentence?

Z00Z is best described as a privacy-preserving settlement protocol with wallet-local ownership meaning, narrow public settlement evidence, and optional disclosure paths layered above that core. That is intentionally narrower than calling it a full service stack, an exchange, or a universal wallet platform.

Is this repository the full protocol implementation?

No. This repository is a docs and site workspace. It proves the public documentation surface, the whitepaper corpus, the build and verification flow for the site, and the current wording of reader-facing claims. It does not by itself prove that every runtime subsystem discussed in the papers is already shipped here as local code.

Does privacy mean no one can see anything?

No. The safe claim is limited public observability, not total invisibility. Public observers can still see checkpointed artifacts and timing surfaces. Operators and external services may still see workflow-specific information. The intended boundary is that private ownership meaning stays wallet-local where possible and disclosure stays scoped rather than universal.

Is there an official wallet with managed recovery?

That is not the right mental model. The legal corpus prefers language such as reference wallet or reference implementation because it preserves the software-versus-service boundary. The current support posture should not imply hosted custody, staff-controlled recovery, or a hidden universal restore switch.

If I lose my seed or backup, can the protocol restore my funds?

No. The current architecture treats recovery as wallet-side and operational, not as a protocol-side clawback power. If private recovery material is lost, the protocol does not magically reconstruct it from a public account table. That is why the safety rule against sharing or losing backups is so strict.

How do I know whether a feature is live or still target architecture?

Read the page’s visible Maturity: note and then check the evidence section. In this repo, mature wording should be tied either to repo-local files or to explicit content/whitepapers/ citations. If the language sounds broader than the evidence, treat it cautiously and compare it with the security or developer pages.

Where should I start if a local docs command fails?

Use Troubleshooting. The live repo commands are the ones defined in package.json and explained in README.md. For most contributor problems, the shortest reliable path is npm ci, then npm run lint, then npm run verify.

Where should security bugs or privacy leaks be reported?

Do not post sensitive exploit details in ordinary public support threads. Use the security flow documented under /docs/security, especially Responsible Disclosure. Public issues are for non-sensitive docs and repo problems, not for live exploit writeups or secret material.

Does Z00Z endorse third-party issuers, bridges, or services?

Not by default. The legal architecture is explicit that third-party assets, overlays, issuers, and regulated services keep their own responsibilities. A docs mention, integration possibility, or ecosystem narrative does not magically turn an external service into a native protocol guarantee.

Are audits already complete for every major surface?

That would be too broad a claim. The safer question is: which surface was reviewed, against what evidence, and with what residual risk left open? Use Audits And Reviews to interpret current and future review claims without collapsing them into one reassuring label.

Is Z00Z already end-to-end post-quantum secure?

No. The post-quantum paper is explicit that Z00Z is not end-to-end post-quantum secure today. What can be said more safely is that the system has a PQ-friendly settlement and storage boundary that makes migration more plausible, while authorization and confidential amount protection remain narrower and harder frontiers.

Can I contribute without touching protocol code?

Yes. This repo already supports useful contributions in docs, navigation, search coverage, claim discipline, source alignment, and workflow correctness. A careful rewrite that removes overclaiming or improves safe user routing is meaningful protocol-adjacent work because it changes what readers believe the system can actually do.

Where do I go next?

Go to Troubleshooting for concrete command help, Wallet Recovery Safety for secret-handling rules, Developer Support for builder questions, or /docs/security if the issue may be sensitive.

Newcomer Questions

If you are new to Z00Z, start with three boundaries. First, the docs describe a protocol and site corpus, not a guarantee that every future product surface is live. Second, privacy is layered: settlement privacy, transport privacy, wallet behavior, and disclosure safety are separate. Third, evidence matters: a claim should point to a whitepaper, a repo file, a verification command, or a review note. If an answer depends on maturity, the safe answer says so.

Protocol And Wallet Questions

Protocol questions should usually route to the main whitepaper and protocol docs. Wallet questions should route to wallet-local possession and wallet recovery safety. Do not treat a wallet support answer as a promise that support can recover secrets or reverse a lost local state. The FAQ should keep repeating that public settlement evidence is not a public account table and that private ownership meaning depends on local wallet material.

Legal and token questions need conservative wording. Z00Z docs should not imply yield, dividends, managed custody, official exchange services, official bridge guarantees, or blanket compliance. External issuers, lockers, wallets, and services keep their own responsibilities. If a question asks whether a third party is endorsed or guaranteed, the safe answer is no unless a current official source says otherwise.

Developer And Contributor Questions

Developer answers should point to real local commands and files. If a question asks how to validate the website, the answer is npm run verify, backed by scripts/verify.sh. If a question asks where route content comes from, point to content/, _meta.yaml, and src/lib/content/. If a question asks whether a protocol feature exists in this website repo, separate docs evidence from protocol implementation evidence.

Contributor answers should be equally bounded. A useful contribution can improve docs, routing, source mapping, examples, or review evidence. It should not add unsupported product promises. If a contribution includes security-sensitive material, do not route it through ordinary public contribution channels.

Safety Questions

The shortest safety answer is: do not share secrets, do not trust DMs, and do not treat support as custody. If a helper asks for recovery words, private keys, wallet exports, remote access, or unredacted logs, stop and use the security path. If a page tells you that a service is official or guaranteed, verify that claim against the current legal and security pages before relying on it.

Review Notes

FAQ answers should be short, but short does not mean unsupported. Each answer should either point to a deeper page or state the boundary directly. The highest-risk FAQ answers are the ones about recovery, privacy, post-quantum security, external services, tokens, and maturity. Those answers should stay conservative even if a simpler answer would sound more attractive.

The FAQ should also avoid becoming a second specification. If an answer needs more than a compact boundary, route to the owning docs page. That keeps future changes centralized and prevents support copy from drifting away from the corpus.

Final Boundary

The FAQ should answer quickly, then route precisely. If a short answer would hide maturity, source, security, legal, wallet, or service boundaries, the answer should be longer or link to the deeper page that owns the answer and the evidence behind it.

When in doubt, the FAQ should choose safety and source traceability over speed.

Short answers still need evidence.

Read What Is Z00Z for orientation, Security Overview for trust boundaries, Wallet Recovery Safety for secret handling, and Contact for routing.

Evidence and Further Reading

  • Main Whitepaper sections 2, 5, 9, 10, and 12 define wallet-local possession, recovery limits, operator boundaries, and the current maturity line between live and target surfaces.
  • Privacy Threat Model And Metrics sections 3, 4, 7, 9, and 10 are the main source anchors for limited public observability, observer-specific risk, scoped disclosure, wallet behavior, and telemetry caution.
  • Post-Quantum Migration Whitepaper sections 3, 4, 8, 10, and 12 explain why the correct cryptographic claim today is narrower than “fully PQ secure.”
  • Legal Architecture Whitepaper sections 4, 7, 9, 10, 17, and Appendix A provide the safe public-claim formulas for self-custody, reference implementations, optional disclosure, and external-service responsibility.