Incident response is where overclaiming becomes most dangerous. In a calm moment, vague language only confuses readers. During an active incident, it can cause real harm: users may post secrets publicly, operators may report speculation as fact, and maintainers may imply a level of control or recovery power that the system does not actually have.
This page defines the conservative response model for the current docs surface. It does not claim that every future operator workflow, automation loop, or enterprise escalation lane is already live. It defines what can be said and done safely when something goes wrong.
Severity Model
Use the smallest severity class that still captures the risk.
| Severity | Typical examples | Default priority |
|---|---|---|
| Critical | Live theft path, exposed recovery secrets, forged authorization, or broadly exploitable integrity failure | Immediate containment and private coordination |
| High | Significant privacy degradation, reproducible replay or validation bypass, trusted-channel impersonation, or operator surface causing serious user harm | Urgent triage with user-protection messaging |
| Medium | Bounded leakage, denial-of-service risk, workflow confusion that could become harmful, or important but precondition-heavy flaws | Investigate promptly and narrow blast radius |
| Low | Hardening issue, minor docs-security drift, or low-probability misuse path with meaningful prerequisites | Queue, track, and fold into normal review work |
Severity is about consequence and exploitability, not about how dramatic the wording sounds.
Ownership By Layer
Different incidents belong to different owners.
| Incident type | Primary owner | Why |
|---|---|---|
| Docs or support-channel misinformation | Documentation and support maintainers | The public trust surface is the thing that failed |
| Wallet secret leakage or recovery confusion | User first, then wallet/support guidance | The protocol cannot reverse private key loss automatically |
| Privacy-boundary failure | Security and protocol reviewers | The visibility contract may have drifted |
| Operator publication or availability failure | Operators and incident coordinators | Liveness and observation surfaces need evidence and status discipline |
| External issuer, bridge, or custody failure | The external service operator first | Those duties remain outside native protocol guarantees |
This ownership map prevents one of the worst incident-response habits: assuming every serious problem must have the same responder or the same remediation path.
First Actions For Users
If you suspect active user harm, the safest initial actions are simple:
- stop sharing additional information;
- do not send seed phrases, recovery bundles, or private exports to anyone;
- preserve the smallest useful evidence set, such as screenshots of the public error, page URL, and the exact step that triggered it;
- move security-sensitive reporting into the responsible-disclosure path;
- treat social DMs, urgency pressure, and requests for remote access as hostile until independently verified.
These actions matter because many incidents in privacy systems involve confusion and impersonation before they involve protocol breakage.
First Actions For Maintainers And Reviewers
Maintainers should default to evidence control and scope control:
- separate confirmed facts from hypotheses;
- decide whether the problem is public-safe to discuss;
- remove or correct misleading public copy quickly if the docs themselves widened the risk;
- preserve reproduction steps privately when public detail would increase exploitability;
- say which layer failed, not just that “there is an incident.”
The legal corpus strongly supports this discipline. Public statements should remain factual, role-bounded, and free of implied hidden control powers.
Communication Discipline
Incident communication should answer four questions in order:
- What happened?
- Which users or systems might be affected?
- What should those readers do right now?
- What is still unknown?
Anything beyond that should wait for evidence. This is especially important for privacy incidents. A message that promises “funds are safe” or “privacy is unaffected” before the right layer has been checked can become its own trust failure later.
What This Repository Can Prove Today
The current repo can prove:
- the wording rules for how incidents should be described;
- the public docs paths where users will look for guidance;
- the repo-local verification flow for correcting misleading content quickly;
- the separation between support routing and security-sensitive disclosure.
The current repo does not prove:
- a fully staffed operations center;
- automatic reorg or publication repair for every operator lane;
- a universal recovery mechanism for lost user secrets;
- a single published channel that already covers every future incident class.
That is why this page emphasizes disciplined communication and user-protective behavior over heroic promises.
After The Immediate Response
When the immediate risk is under control, the follow-up should include:
- what was confirmed;
- what changed in docs, tooling, or process;
- what remains a residual risk;
- whether the issue belongs in Audits And Reviews, Privacy Metrics, or both.
An incident is only truly closed when the public explanation becomes more precise than it was before the incident.
Incident Routing Flow
Routing comes before reassurance. A privacy degradation, wallet secret leak, DA outage, censorship alert, support scam, or docs claim error may require different owners and different public language. The first job is to preserve evidence safely and decide which layer can act. The second job is to communicate what users should do without revealing exploit detail or implying hidden control.
Evidence Preservation
Preserve the smallest useful evidence set: affected route, command, public error, timestamp, version, and safe reproduction steps. Do not preserve or redistribute secrets. Do not post full logs if they contain wallet material, tokens, personal data, or exploit detail. If public communication is needed, keep it factual and bounded: affected layer, known impact, user action, next update path, and unknowns.
Claim Corrections
Some incidents are not code incidents. A public page may overstate recovery, imply guaranteed privacy, or suggest an unsupported contact route. Treat claim corrections as incident-response work when the wording could cause user harm. The fix may be a docs patch, evidence note, redirect, or warning rather than a code change.
Post-incident review should ask whether the page that misled readers had the right source anchors, maturity label, and support routing. If not, update the docs as part of containment. A resolved incident with unchanged misleading docs is not fully resolved.
Review Notes
Incident-response wording should be written for stress, not for ideal readers. During an incident, users skim. The first action should be visible, specific, and safe: stop sharing secrets, preserve minimal evidence, avoid DMs, use disclosure routing, or wait for a scoped update. Long explanations can follow after containment.
Reviewers should also check that incident pages do not imply powers the project lacks. A docs team can correct public wording. A protocol maintainer can patch code in scope. A support page cannot reverse lost secrets, force an external issuer to redeem, or guarantee that a third-party service behaved honestly.
Final Boundary
Incident response is complete only when users know what to do, maintainers know which layer owns the issue, and public wording no longer implies more certainty than the evidence supports publicly.
Read Next
Read Responsible Disclosure for sensitive reports, Troubleshooting for ordinary local failures, 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 explain why timing, disclosure, transport, wallet UX, and service-layer failures can create real privacy incidents without changing the narrow settlement theorem.
- Main Whitepaper sections 8, 9, 10, 12, and Appendix D distinguish fail-closed settlement behavior from operator, availability, and recovery surfaces that remain narrower or less mature.
- Legal Architecture Whitepaper section 16 and sections 4, 9, 17, 18, and Appendix A provide the public-claim rules that incident communications should follow so they do not imply custody, hidden control, or stronger operational authority than exists.
- Responsible Disclosure and Wallet Recovery Safety provide the adjacent user and reporter actions that help keep incidents from widening.
- NIST Cybersecurity Framework: https://www.nist.gov/cyberframework.