Responsible disclosure is not just a courtesy rule. In a privacy-focused system, careless reporting can increase harm before anyone has reproduced the issue. Publicly posting a wallet secret, a live exploit path, or a replayable proof artifact can turn an ordinary bug report into an active incident. This page exists to prevent that outcome.
What Belongs In This Flow
Use the security disclosure path for findings such as:
- secret or recovery-material exposure;
- privacy-boundary failures that reveal more than the docs claim;
- authorization, replay, or value-validity bugs;
- supply-chain or build-tooling issues that could compromise published outputs;
- support scams, impersonation campaigns, or disclosure channels that ask users for forbidden data;
- fraud-trigger or external-service issues when public detail would help attackers before mitigation.
Do not use public issue threads for those cases.
What To Avoid Immediately
Before sending anything, stop and avoid these common mistakes:
| Do not do this | Why it is dangerous |
|---|---|
| Post exploit steps in a public issue or chat | It can convert a limited bug into a wider incident |
| Paste seed phrases, recovery bundles, private keys, or raw wallet exports | Reviewers should never need them to validate ordinary reports |
| Send secrets to social DMs, moderators, or unofficial helpers | Private messaging is the easiest place for impersonation and data theft |
| Promise an impact level before reproducing the issue | Wrong severity language can create panic or false assurance |
If you already exposed sensitive material publicly, treat that as part of the incident and say so immediately.
What A Good Report Should Include
A useful report does not need to be long. It needs to be reproducible and scoped.
At minimum, include:
- the affected page, workflow, or subsystem;
- the observed behavior;
- the expected behavior;
- the smallest reproduction path you know;
- whether the issue affects confidentiality, authorization, value validity, liveness, or trust framing;
- whether private user data or secrets were involved.
For docs and site issues in this repository, it is often enough to name the page path, the exact command run, and the visible result. For protocol-design or privacy-boundary issues, cite the relevant content/whitepapers/ passage that appears to conflict with the observed behavior.
Current Channel Discipline
This repository can prove the process rules more clearly than it can prove a staffed private inbox. That means the safe channel discipline must stay conservative:
- use public issue tracking only for non-sensitive docs, build, or content bugs;
- use Support for ordinary troubleshooting;
- use a project-controlled private route for security-sensitive findings whenever that route is explicitly published in live project materials;
- if no private security channel is currently published, request a secure route without including the exploit details in the public request.
That last rule is important. The absence of a public inbox is not permission to publish the exploit payload in the open.
Severity Framing
Use severity language that matches what is actually at risk:
| Severity hint | Typical impact |
|---|---|
| Critical | Live theft, key compromise, forged authorization, or broadly weaponizable secret exposure |
| High | Significant privacy failure, replay bypass, major trust-boundary misrepresentation, or operator path that can cause serious user harm |
| Medium | Important but more bounded leakage, verification bypass in a narrower lane, or attack path requiring meaningful preconditions |
| Low | Hardening issue, minor docs-security drift, or defense-in-depth weakness without immediate exploit value |
If you are unsure, describe the facts first and let the triage process adjust the label.
What This Page Does Not Promise
This repo snapshot does not prove a reward program, a bounty schedule, legal safe-harbor text, or a fixed response-time SLA. It also does not prove that every disclosure lane is staffed around the clock. What it does provide is the non-negotiable behavioral baseline: protect users first, keep exploit detail out of public threads, route ordinary support and sensitive security separately, and avoid sending secrets to anyone.
That is a real and useful contract even before a larger disclosure program is formalized.
Related Pages
Open Incident Response if the issue is already active or public. Open Audits And Reviews if you want to understand what kind of evidence a future disclosure resolution should publish. Open Contact only for non-sensitive routing questions; it is not a substitute for secure reporting.
Disclosure Routing Flow
The routing decision comes before the full explanation. If a report contains exploit steps, wallet secrets, private logs, personal data, or a privacy leak that becomes worse when publicized, do not post it in an ordinary public issue. Send only the minimum evidence needed to reproduce and triage. If the report is a typo, broken link, stale claim, or non-sensitive build issue, ordinary support is usually enough.
Evidence Handling
A good disclosure report should include the affected page, file, command, route, or workflow; the expected behavior; the observed behavior; the smallest reproduction; and the reason public detail may be harmful. It should not include seed phrases, private keys, decrypted wallet exports, unnecessary screenshots, or third-party personal data. If the issue involves a wallet-risk report, redact aggressively and describe the class of secret rather than the secret itself.
Severity should be conservative and evidence-based. Critical means active theft, secret exposure, forged authorization, or a broadly exploitable integrity path. High means serious privacy degradation, impersonation, or validation bypass. Medium and low issues still matter, but they should not be inflated into emergency language without evidence.
Ordinary Support Separation
Responsible disclosure is not the right path for every typo, broken link, or local setup issue. Ordinary support remains appropriate when public reproduction does not increase harm. The separation matters because security channels become weaker if they are filled with normal support traffic, and public support becomes dangerous if reporters paste exploit details or secrets there.
Use one rule: if publication helps attackers or exposes private material, keep it private. If publication only helps maintainers reproduce an ordinary docs failure, use the normal support path. When unsure, choose the safer path first and let triage redirect it.
Review Notes
Disclosure guidance should be reviewed from the attacker’s point of view. If the page encourages reporters to include too much detail publicly, it may turn a vulnerability report into an exploit guide. If the page asks for too little, triage becomes guesswork and reporters may send repeated oversized messages. The right balance is minimal reproducible private evidence for sensitive issues and ordinary public evidence for non-sensitive issues.
This page should also avoid bounty language unless a current official program exists. A safe disclosure path is not the same thing as a public bug-bounty promise, guaranteed response time, or legal safe harbor.
Final Boundary
Disclosure guidance should be practical enough to follow during stress. If a reporter cannot decide whether a finding is sensitive, the page should push them toward the private route first and let triage redirect safely with minimal public exposure.
Read Next
Read Incident Response for active events, Supply Chain for dependency and asset reports, and Contact for non-sensitive routing.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 6 and 10 and sections 4, 7, 8, and 9 are the main source anchors for why privacy failures, metadata leakage, network exposure, and service-side disclosure surfaces need careful reporting boundaries.
- Legal Architecture Whitepaper sections 16 through 18 and sections 4, 9, and Appendix A define the steward-versus-service boundary, safe public wording, and the warning against implying hidden universal control or recovery powers.
- Proof-of-Useful-Work Whitepaper sections 5, 8, and 11 reinforce the broader project rule that evidence should be structured, challengeable, and narrower than social trust theater.
- Main Whitepaper sections 5, 8, 9, 10, and Appendix D explain the wallet-local, publication, and checkpoint-bound boundaries that help determine whether an issue is ordinary support, security-sensitive disclosure, or a broader incident.