The quickest way to misread Z00Z security is to assume there is one giant protection claim that covers everything equally. The corpus does not defend that idea. Instead, it separates different security questions by layer: what public observers can see, what a wallet must keep private, what operators can delay or correlate, what external services remain responsible for, and which statements are still target architecture rather than finished deployment fact.
That layered view is not a rhetorical preference. It is the only way to keep security statements technically honest. A protocol may have a strong settlement boundary while still leaving transport privacy, disclosure tooling, recovery ergonomics, or operator automation at a lower maturity level. A reader-facing overview page should make that visible before anyone starts comparing slogans.
The Layer Map
The table below is the shortest useful map of the current security surface.
| Layer | What it protects | Main strength | Residual risk that must stay visible |
|---|---|---|---|
| Settlement and storage boundary | Replay-safe public validity and checkpoint continuity | Public truth is organized around typed artifacts, roots, and canonical replay checks | Valid settlement does not automatically imply private transport, perfect uptime, or full service safety |
| Wallet boundary | Private ownership meaning, local recovery state, and secret material | Ownership meaning stays wallet-local rather than living in a public account table | Lost keys, bad backups, endpoint compromise, and careless sharing still harm users |
| Cryptographic boundary | Authorization, stealth reception, encrypted payloads, and confidential amount semantics | The current lane is specific and concrete, not hand-wavy | It is not end-to-end post-quantum secure today, and some confidentiality surfaces remain a harder future frontier |
| Operator boundary | Publication, observation, alerts, and byte availability | Roles are separated so liveness and observation do not silently become settlement authority | Aggregators, watchers, and archives can still correlate timing, delay publication, or fail operationally |
| Disclosure boundary | Scoped evidence for reviewers, operators, or counterparties | The architecture allows selective and purpose-bound disclosure language | Full corporate-audit overlays remain a stronger future lane than the current repo can prove |
| Legal and stewardship boundary | Public claims, role containment, and non-custodial posture | Safe formulas exist for describing the protocol without turning it into a hidden operator stack | Bad wording can still imply exchange, custody, or universal recovery power that the design rejects |
None of those rows cancels the others. They simply answer different questions.
Three Rules For Reading Security Claims
Use these three rules whenever you read or write a security sentence about Z00Z:
- Ask which layer owns the claim.
- Ask what evidence supports it in this repository or the whitepaper corpus.
- Ask which residual risk is still outside the claim.
For example, “wallet-local ownership meaning is not stored as a public balance table” is a scoped protocol-and-wallet statement. “No one can ever correlate a payment” is not. The first has an owner and a boundary. The second erases transport, timing, service, and user-behavior risk.
Present-Tense Versus Target-Lane Security
The current repository gives you strong documentation evidence, but it does not give you a complete production inventory. That distinction should stay visible across the whole family.
Safe present-tense claims in this repo include:
- the whitepaper corpus distinguishes wallet-local possession from public settlement evidence;
- the docs can publish maturity notes, support flows, and security boundaries consistently;
- the repo verification path for site changes is real and inspectable.
Claims that still need stronger caveats include:
- fully landed selective-disclosure workflows;
- mature enterprise audit overlays;
- complete operator-grade recovery automation;
- end-to-end post-quantum protection across all live surfaces.
When in doubt, use narrower language and point to the deeper page that carries the evidence.
How The Deeper Pages Fit Together
Think of the rest of the security family as focused drill-downs:
| Page | Best use |
|---|---|
| Threat Model | For adversaries, misuse cases, and failure classes |
| Crypto Policy | For cryptographic scope, migration language, and non-claims |
| Supply Chain | For repo-local dependency and tooling trust boundaries |
| Responsible Disclosure | For safe reporting behavior |
| Audits And Reviews | For evidence expectations and review interpretation |
| Privacy Metrics | For measuring quality without inventing a fake universal score |
| Incident Response | For severity classes and communication discipline during failures |
This page should leave you with one durable conclusion: Z00Z security is strongest when each layer stays narrow, explicit, and evidence-backed. The docs become untrustworthy when they collapse those layers into a single promise.
Layered Responsibility Map
The diagram is a responsibility map, not a guarantee chain. A strong protocol layer does not repair unsafe wallet backups. A careful wallet cannot make an external issuer honest. A transport layer cannot turn voluntary disclosure into secrecy. Governance cannot fix a claim that was marketed as live without implementation evidence. Documentation sits at the end of the loop because public wording controls what users and contributors think each layer can do.
What Can Fail Where
| Failure area | Example failure | Correct security posture |
|---|---|---|
| Protocol | Replay or validation bug | Treat as security-sensitive until reproduced and scoped |
| Wallet | Seed disclosure, endpoint compromise, unsafe backup | Support cannot recover secrets; route to wallet safety guidance |
| Network | Timing correlation or low-load route exposure | Treat as privacy degradation, not settlement failure |
| Service | Issuer, bridge, locker, or support-channel leak | Name the external service boundary explicitly |
| Governance | Reward fraud, challenge failure, AI review overreach | Use DAO and PoUW evidence gates |
| Docs | Unsupported assurance or stale maturity language | Correct the claim and cite the owning source |
Evidence Ladder
Security confidence should climb an evidence ladder. A whitepaper gives the claim vocabulary and threat model. A docs page translates it for readers. A local verification command proves that this site still builds and renders. A focused test or simulation proves a bounded behavior. A code review or audit can support a narrow implementation claim. An incident review can prove that one failure was understood and corrected. None of those steps replaces the others.
Use the lowest sufficient claim. If only a paper exists, write “the corpus defines.” If local docs verification passed, write “the site verifies.” If a component has a review, write the component and scope. If an external service is involved, name that service separately. This ladder keeps the security overview readable without making it vague.
Review Notes
The overview should be the page reviewers use to reject blanket security language. If a later page says “secure,” ask which layer. If it says “private,” ask which observer. If it says “audited,” ask which scope. If it says “supported,” ask which public route and response boundary. The overview is successful when it makes those questions feel normal rather than exceptional.
Security work also has a documentation risk: readers may remember the strongest phrase and forget the caveat. Keep tables, diagrams, and evidence blocks close to the claim they constrain. Do not move caveats to a remote legal page when the security page itself creates the expectation.
Read Next
Read Threat Model for adversaries, Crypto Policy for cryptographic wording limits, Privacy Budget for behavior-level leakage, and Incident Response when an issue may already be active.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 3 through 10 are the main source anchors for adversary classes, visibility boundaries, privacy metrics, anti-patterns, wallet UX, network boundaries, disclosure, and telemetry limits.
- Main Whitepaper sections 3, 5, 6, 8, 9, 10, and 12 explain wallet-local possession, checkpointed settlement evidence, operator boundaries, and current-versus-target maturity lines.
- Post-Quantum Migration Whitepaper sections 3, 4, 7, 8, and 12 define the current cryptographic boundary, migration caveats, and why explicit suite identity matters.
- Legal Architecture Whitepaper section 16 and sections 4, 7, 9, 17, and Appendix A provide the safe public-claim matrix used to keep this overview conservative.
- DAO Whitepaper section 9 anchors governance-abuse, challenge, bond, and emergency-path boundaries.