Responsible Disclosure Playbook

Security research does not end when we find a bug. It ends when the bug is fixed in production and users are protected. The period between discovery and disclosure is fragile: it involves trust, operational secrecy, and clear timelines. This playbook is how we handle that period.

Initial discovery

When we identify a vulnerability, we create an internal case file with the following fields:

• Severity. Critical, high, medium, or low, based on exploitability and impact.
• Affected scope. Specific versions, components, and configurations.
• Prerequisites. Stake, network position, special keys, or user interaction required.
• Proof of concept. A working reproduction on a private testnet.
• Attack scenario. How the bug could be exploited in production.
• Mitigation options. Suggested patches and their trade-offs.

We do not discuss the bug on public channels, issue trackers, or social media during this phase. We also do not run the exploit on mainnet.

Contacting the team

We use the protocol’s official security contact if one exists. If not, we contact the core maintainers through private, authenticated channels. The initial message contains:

1. A high-level description of the issue class without revealing the exact trigger.
2. A proposed timeline for full disclosure.
3. Our public PGP key if encrypted communication is required.
4. A request for acknowledgement of receipt.

We do not attach the full exploit in the first message. We verify that the recipient has the authority and incentive to respond.

Timeline negotiation

Our default timeline is 90 days from the date of acknowledgement. For critical vulnerabilities that are actively exploitable or already known to attackers, we may propose a shorter window. For complex fixes that require hard forks, we may extend it, but only with written agreement and a clear public commitment from the team.

We avoid “indefinite” timelines. A disclosure date concentrates the mind and protects users who assume the code is safe until they are told otherwise.

Coordination during the fix

While the patch is being developed, we:

• Review proposed fixes and look for bypasses.
• Test the patched version against our reproduction.
• Provide guidance on regression tests and monitoring signals.
• Help draft the public disclosure if the team requests it.

We do not demand attribution, but we do require factual accuracy in the public post-mortem. If a team downplays the severity, we reserve the right to publish our own technical analysis.

Public disclosure

When the disclosure date arrives, we publish:

• A technical summary with enough detail for independent reproduction.
• The affected versions and the patched version.
• The timeline of the coordination.
• Acknowledgement of the team’s fix effort, if they engaged constructively.
• A note on whether the vulnerability was observed in the wild.

We do not publish full exploit code unless the bug is already being actively exploited and the public needs to defend itself. In that case, we coordinate with law enforcement and incident-response teams.

Handling non-responsive teams

If a team does not acknowledge receipt within 14 days, or does not provide a credible plan within 30 days, we may disclose earlier with a clear explanation of the breach of coordination. Our obligation is to the users of the protocol, not to the team’s public relations schedule.

Closing note

Responsible disclosure is a trust protocol. It only works when both sides act in good faith. Our reputation depends on keeping our side of the bargain, and we expect the same from the teams we work with.