Vulnerability Disclosure Policy Template for Web3 Protocols

By the Guardian team Updated November 2026 6 min read

Quick answer. Yes. The template below adapts CISA's vulnerability disclosure policy template to web3, with scope by contract address, a security.txt contact, safe harbor, response times, exclusions, rewards and disclosure timing.

Watch: Vulnerability Disclosure Policy Template for Web3 Protocols 1:38

Video transcript

Yes, there is a disclosure policy template built for web3. It adapts CISA's template to protocols, with scope by contract address and a security.txt contact.

Without one, a researcher who finds a bug in your contracts may have no safe, fast way to tell you.

The policy covers scope, how to report, safe harbor, response times, exclusions, and rewards and public disclosure.

Response times are a promise. Acknowledge within one business day, confirm severity within five, update every seven days, and say when the fix ships. Pick defaults your team can meet.

Publish a security.txt file under RFC 9116, served over HTTPS, with the required Contact and Expires fields. Keep it current. Guardian's exchange benchmark found Coinbase's and Bitstamp's files expired.

CISA commits to acknowledging within three business days, while SEAL notes teams often target twenty four hours. HackerOne publishes resolved reports in thirty days unless either side objects.

Live exploits need something else. SEAL Safe Harbor is a separate onchain agreement for whitehat rescues, and rescued funds must be returned within 72 hours.

With Vanguard, Guardian hosts and manages your bug bounty with fifty thousand dollars in Critical matching. Managed Security runs triage and impact validation end to end.

Read the full template to copy it, or talk to Guardian about handing over your bug bounty.

A vulnerability disclosure policy tells researchers what they may test, how to reach you and what you promise in return.

Without one, a researcher who finds a bug in your contracts may have no safe, fast way to tell you.

The template works with or without a paid program. If you run one, see how to set up a web3 bug bounty.

What the Policy Must Settle

Two public references set the method:

ISO/IEC 29147:2018: the international standard for vendors on receiving vulnerability reports and disclosing remediation.
CISA's template: authorization, guidelines, test methods, scope, reporting and what reporters can expect.

SEAL, the Security Alliance, adds the web3 layer. It says bounty platforms "do not replace security contacts, triage ownership, or disclosure discipline."

Together they give seven sections:

Section	What it settles	Method source
1. Scope	What researchers may test, and how	CISA scope and test methods
2. How to report	Where reports go, what they include	RFC 9116, CISA
3. Safe harbor	Legal cover for good-faith research	CISA authorization, SEAL Safe Harbor
4. Response times	What you commit to, and when	CISA, SEAL
5. Out of scope	What is banned or not eligible	CISA test methods, Immunefi defaults
6. Rewards	Whether you pay	CISA bounty note
7. Public disclosure	When findings go public	CISA, SEAL, HackerOne

The Policy Template

Copy the text below and publish it at a stable URL. Sections 3 and 4 adapt CISA's wording.

Replace everything in [brackets]. Bracketed numbers are suggested defaults: change them to what your team can meet.

1. Scope

This policy covers the [protocol name] systems below. Any system not listed is out of scope, including third-party contracts, oracles and bridges we integrate.

Smart contracts at the addresses listed on [link to deployments page], by chain.
[app URL] and the APIs it calls.
Code in [repository links], at the deployed commits.

Test only on a local fork, never on mainnet or a public testnet. Use an exploit only as far as needed to confirm it.

2. How to Report

Send reports to the contact listed at [your domain]/.well-known/security.txt. Anonymous reports are welcome.

Please include:

The chain, contract address and function, or the affected URL.
The impact, and the funds or users at risk.
Steps to reproduce, with a runnable proof of concept on a fork.
A way to reach you, if you want updates.

Report as soon as you confirm an issue. Do not send a high volume of low-quality reports.

3. Safe Harbor

If you make a good faith effort to follow this policy, we will consider your research authorized. We will work with you to resolve the issue quickly.

We will not recommend or pursue legal action related to your research. If a third party does, we will make this authorization known.

Optional, only if you have adopted SEAL Safe Harbor:

During an active exploit, whitehat rescues fall under our SEAL Safe Harbor terms at [link]. Rescued funds must go to [recovery address] within 72 hours.

4. Response Times

We will:

Acknowledge your report within [1 business day].
Confirm validity and severity within [5 business days].
Update you at least every [7 days] until it is fixed.
Tell you when the fix is deployed.

We will be as transparent as we can about the fix, including anything that delays it.

5. Out of Scope

These are not allowed, or not eligible:

Testing on mainnet, public testnets or third-party systems.
Denial of service, or traffic-heavy automated testing.
Phishing or social engineering of our team, users or partners.
Physical attacks on offices, devices or people.
Moving, freezing or accessing funds or data that are not yours.
Attacks that need leaked keys, or privileged roles acting as designed.
Best practice suggestions without a demonstrated impact.
Known issues, including acknowledged findings in our published audits.

6. Rewards

Keep one option and delete the other:

No rewards: "We do not pay for reports. With your permission, we credit you at [credits page]."
Bug bounty: "Valid in-scope reports are rewarded under our bug bounty at [bounty page], on its terms."

7. Public Disclosure

Keep the report confidential until we confirm the fix is deployed.
We aim to publish a joint write-up within [30 days] of the fix.
Share your draft with us before you publish.
If a fix takes longer, we will tell you why and agree on a new date.
During an active exploit, we may warn users at once.

Policy version [1.0], last updated [date].

Publish a security.txt File

RFC 9116 defines security.txt, a plain-text file that tells researchers where to report. SEAL lists it among the standard ways to reach a security team.

The RFC's rules:

Serve it at /.well-known/security.txt, over HTTPS, as text/plain.
Include Contact and Expires; both are required.
Set Expires less than a year ahead (recommended).
Sign it with an OpenPGP cleartext signature (recommended).
Point the Policy field at your policy.

A minimal file:

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-10-31T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

Files go stale. Our exchange bug bounty benchmark found Coinbase's and Bitstamp's files expired.

Put the same contact in your repository's SECURITY.md, which SEAL also lists.

Choices Before You Publish

Decision	Options	Reference point
Acknowledgment	1 to 3 business days	SEAL: teams often target 24 hours; CISA: 3 business days
Disclosure delay	Set days after the fix	HackerOne: resolved reports public in 30 days unless either side objects
Rewards	None, or a linked bounty	CISA's template allows either
Live exploits	Adopt SEAL Safe Harbor	Separate agreement, 72-hour return
Reporter identity	Anonymous, pseudonymous or named	CISA's template accepts anonymous reports
AI-generated reports	Accept, require disclosure, or exclude	State the rule either way

If You Adopt SEAL Safe Harbor

SEAL describes its Safe Harbor as an onchain agreement that pre-authorizes whitehat interventions during active exploits. A DAO adopts it with a governance vote and onchain registration.

It only applies when an exploit is in progress or imminent. It is not a channel for bug reports.

SEAL calls a 10% rescue bounty "standard in the industry" and recommends a cap matching your bug bounty's maximum. The other terms are in our setup guide.

Keep scope current, too. SEAL warns that if new deployments are not covered, whitehats cannot legally intervene.

How Guardian Helps

With Vanguard, Guardian hosts and manages your bug bounty, with $50,000 in Critical matching. Triage uses tuned AI and tracks known issues from the audit.

With Managed Security, Guardian runs the program end to end: hosting, triage and impact validation, severity disputes and a drafted fix.

Scope and rules are agreed with you, so this policy is a ready starting point. Weighing a bounty against an audit? Read what each catches.

Frequently Asked Questions

What is the difference between a vulnerability disclosure policy and a bug bounty?

A disclosure policy says what researchers may test, how to report and what you promise in return, with or without payment. A bug bounty adds rewards. CISA's template covers both cases, and a bounty still needs the policy.

Is security.txt required?

RFC 9116 is Informational, not a mandate. If you publish the file, it requires Contact and Expires fields, served over HTTPS at /.well-known/security.txt. SEAL lists it as a standard security contact.

Does a disclosure policy cover whitehat rescues during an exploit?

No. It covers good-faith research under the policy. Rescues during an active exploit fall under SEAL Safe Harbor, which a protocol adopts separately and which requires whitehats to return rescued funds within 72 hours.

How fast should a protocol acknowledge a vulnerability report?

CISA's template commits to 3 business days. SEAL notes that teams often target 24 hours. For contracts holding funds, aim for the faster end, and staff the inbox to meet it.

Sources

Hand your bug bounty to Guardian

Guardian hosts your bounty, triages reports and tracks known issues from your audit.

Talk to Guardian Explore Vanguard