The safest contact page is not the one with the longest list of inboxes. It is the one that helps readers avoid impersonation, oversharing, and wrong-channel reports. This repository currently proves some contact surfaces and only implies others. The page should stay honest about that.
Verify The Channel Before You Send Anything
Use these checks first:
| Check | Why it matters |
|---|---|
| Is the channel published in the current docs, repo, or a signed project announcement? | Reposted contact details are easy to spoof |
| Does the request belong in public support or private security disclosure? | Wrong routing can widen harm |
| Are you about to send a secret, recovery bundle, or private exploit detail? | If yes, stop and change the route |
| Is the person contacting you through a DM instead of a published project surface? | That is a common impersonation pattern |
If you cannot verify the route, do not assume urgency is proof of legitimacy.
Current Published Surfaces This Repo Can Support
The current repository can directly support these contact-adjacent paths:
| Need | Current proven surface |
|---|---|
| Docs or build issue in this repo | The public issue and pull-request workflow attached to github.com/z00z-labs/z00z-website |
| General navigation inside the docs | The support and developer pages in this repo |
| Security-sensitive reporting rules | Responsible Disclosure |
| Legal and privacy wording boundaries | The legal and security pages published in content/docs/ |
What this repo does not clearly prove on its own is a staffed support email, a media desk, a partnership inbox, or a universal legal mailbox. Those may exist in live project operations later, but they should not be invented here without published evidence.
Routing By Question Type
Use the narrowest correct route:
| Request type | Best route |
|---|---|
| Docs typo, broken page, bad link, or repo-local build problem | Public repo issue or pull request |
| Contributor workflow question | Developer Support first, then the repo workflow if still unresolved |
| Wallet safety confusion or recovery panic | Wallet Recovery Safety before contacting anyone |
| Security bug, privacy leak, or scam report | Responsible Disclosure, not a public issue |
| Media, partnership, or legal outreach | Only the channels explicitly published in the live docs or signed project materials |
This table is intentionally conservative because over-routing is safer than under-routing when secrets or trust are involved.
What Not To Send
No matter which channel you choose, do not send:
- seed phrases;
- private keys;
- wallet export files;
- raw recovery bundles;
- private exploit payloads in public threads;
- personal documents unless a separately published and justified process requires them.
Most honest support or contributor flows do not need any of that information.
Why This Page Avoids Big Promises
The legal corpus warns against language that makes the project sound like a hidden service operator. A contact page can accidentally do exactly that if it implies full customer support, recovery custody, or enterprise-service coverage that the repo cannot prove. The safer posture is to publish only what exists, route sensitive matters carefully, and leave unproven channels unclaimed until they are actually public.
That is not a weak contact page. It is a safer one.
Contact Routing Table
| Contact need | Safer route | What to include | What not to include |
|---|---|---|---|
| Documentation correction | Public repo issue or contribution path | Page, route, expected wording, source citation | Wallet secrets or exploit details |
| Security report | Responsible disclosure path | Minimal repro, affected layer, impact, redacted evidence | Public exploit steps or secrets |
| Legal inquiry | Legal/contact route when available | Role, question, public document reference | Private keys, user data, unsupported claims |
| Developer help | Developer support route | Command, path, error, repo state | Personal secrets or unrelated logs |
| Contribution coordination | Contribution path | Scope, files, evidence, verification command | Sensitive vulnerability detail |
The table is intentionally conservative. Contact pages create trust expectations, so they must avoid implying a guaranteed response time, official operational support for every third party, or staff-controlled recovery. The safest contact route is the one that asks for the least sensitive evidence that can still move the issue forward.
Non-Response And Redirect Boundaries
Some questions may be redirected or left unanswered if they ask for secrets, demand wallet recovery that support cannot perform, request legal advice outside the documented public materials, or depend on a third-party service that the project does not operate. A redirect is not a refusal to care. It is a boundary that protects users and keeps the public channel from pretending to own systems it does not control.
Verification Rules
Before sending anything, verify that the route is linked from the current website or repository. Do not trust a contact channel only because it appears in a screenshot, social message, or copied support thread. If the issue is sensitive, do not include exploit details in a public contact attempt. If the issue is legal, keep the request factual and tied to public documents. If the issue is wallet recovery, do not send secret material even if the channel appears official.
Evidence Expectations
A contact request should include only the evidence needed for its category. Documentation requests need a page and source. Developer requests need a command, path, and error. Security reports need a minimal private reproduction. Legal inquiries need the public claim or document being discussed. Contribution coordination needs scope and verification. More evidence is not automatically better; oversized evidence can create privacy and support risk.
Redirect Examples
Broken Markdown belongs to troubleshooting or contribution. A suspected phishing channel belongs to responsible disclosure. A question about whether a whitepaper claim is current belongs to source authority and developer support. A request to recover lost secrets cannot be solved by contact routing and should be redirected to wallet recovery safety. These redirects are part of user protection.
Review Notes
Contact pages should be reviewed for implied promises. A phrase like “official support” can imply staff, response time, custody, or endorsement that the repo does not prove. Use route names and categories instead. “Use responsible disclosure for sensitive security reports” is safer than “contact us for any security issue” because it says what evidence belongs there and what does not.
The page should also be checked against scams. Attackers imitate contact instructions. That is why channel verification, no-secret rules, and independent navigation from the official site matter. Do not rely on screenshots, copied links, or urgent DMs for trust.
Final Boundary
A contact page should never train users to trust urgency. It should train them to verify channels, minimize evidence, avoid secrets, and choose the route that matches the issue. That is especially important when a request claims to be legal, security, or wallet-related.
If the current site does not publish a specific contact mechanism for a category, the page should not invent one. It should route to the documented support or disclosure surface and state the boundary clearly for readers.
Silence is safer than fake authority.
Read Next
Read Responsible Disclosure for sensitive reports, Developer Support for builder questions, and Contribute for ordinary docs or source-mapping work.
Evidence and Further Reading
github.com/z00z-labs/z00z-website,README.md, andpackage.jsonare the current repo-local surfaces that anchor the public docs issue, contribution, and verification workflows referenced here.- Legal Architecture Whitepaper section 17 and sections 4, 9, and Appendix A explain why public materials must avoid implying hidden custody, exchange, recovery, managed-service posture, or unsupported contact authority.
- Privacy Threat Model And Metrics section 7 and sections 4, 9, and 10 are the source anchors for why sensitive details, metadata, exploit paths, wallet UX, and disclosure telemetry need narrower routing than ordinary support.
- Main Whitepaper sections 5, 9, 10, and Appendix D reinforce the self-custodial, wallet-local, and operator-boundary model that makes secret-handling discipline essential on every contact path.
- Responsible Disclosure is the adjacent page for security-sensitive routing.