Vulnerability Disclosure

policy If you believe you have found a vulnerability in the Note Systems contracts, site or app, report it privately through one of the channels below. Do not open a public issue, post on social media or contact individual contributors. Any reward depends on an active bug bounty programme and its published terms. The programme is not currently announced live; private vulnerability reports are still welcome.

This policy is also published in machine-readable form at /.well-known/security.txt (RFC 9116) and as SECURITY.md in the repository root.

Channels

The PGP key is marked pending. Confirm the key and its fingerprint through an authenticated channel before encrypting sensitive details.

Do not send a report through the app, the site’s contact form, X direct messages or a public chat. If you have tried the channels above and received no acknowledgement within 24 hours, post a message on X to @notesystems saying only that you have sent a report and its identifier, without any detail.

What to Include

A complete report lets us reproduce the issue on the first attempt. Include:

1. Target: contract name, chain, deployed address and the commit or tag you tested against. Say whether it is the public testnet, a fork, or a mainnet deployment.
2. Summary: one paragraph. What an attacker can do, and to whom.
3. Severity you propose, using the severity matrix, with the funds at risk if you have estimated them.
4. Steps to reproduce: exact calls, arguments, ordering, block or timestamp conditions, and any prerequisite state.
5. Proof of concept: preferably a Foundry test that passes when the bug is present and fails when it is fixed. A transaction hash on testnet is acceptable. Never include a mainnet exploit transaction.
6. Impact: what is lost, frozen or mis-priced; whether it is repeatable; which invariant on the Invariants page it breaks.
7. Suggested fix, if you have one. A tested patch can help triage; it does not establish reward eligibility.
8. Your details: how to reach you, a PGP key or fingerprint if you want encrypted replies, and whether you wish to be credited by name, by handle, or not at all.

Encrypted Report Template

Prepare the information below locally. The published key is pending: request a verified secure submission channel before sending sensitive reproduction details. Do not encrypt to an unverified key.

-----BEGIN NOTE SYSTEMS VULNERABILITY REPORT-----
Report date (UTC):
Reporter handle / name:
Contact (email or PGP fingerprint):
Credit preference: [name | handle | anonymous]

Target
  Contract(s):
  Chain / network:
  Address(es):
  Commit or tag:
  Phase: [testnet | mainnet guarded | mainnet full | fork]

Summary (one paragraph):

Proposed severity: [Critical | High | Medium | Low]
Estimated funds at risk (USD) and how measured:

Steps to reproduce
  1.
  2.
  3.

Proof of concept
  [ ] Foundry test attached (file name):
  [ ] Testnet transaction hash:
  [ ] Other:

Impact
  Assets affected:
  Repeatable: [yes | no]
  Invariant(s) violated:

Suggested fix (optional):

Disclosure
  [ ] I have not shared this report with any other party.
  [ ] I have not exploited this on any deployment holding user funds.
  Preferred public disclosure date (>= 90 days from report unless agreed):
-----END NOTE SYSTEMS VULNERABILITY REPORT-----

What Happens Next

You may appeal a severity decision once, with new evidence, within 7 days of triage. The full committee reviews appeals.

Coordinated Disclosure Timeline

Note Systems follows a 90-day coordinated disclosure policy.

• Day 0: report received and acknowledged.
• Day 3: triage complete. If the vulnerability is being exploited or is trivially discoverable, the timeline is shortened and the reporter is told the new date.
• Day 7: fix plan communicated for Critical and High. For immutable core contracts a fix may mean a pause of new issuance through SeriesRegistry, a new core version, and guidance for live series; existing escrow cannot be modified.
• Day 7 to 60: fix developed, tested against the reporter’s proof of concept, reviewed, and deployed through the documented governance path. governance delays are public; where a queued upgrade would reveal the vulnerability before it is fixed, the proposal description states only that it is a security fix and the details follow at disclosure.
• Day 90: public disclosure. Note Systems publishes an advisory on this site and on @notesystems with the description, impact, fix, timeline and credit. The reporter may publish at the same time.
• Earlier disclosure is agreed in writing once a fix is deployed and users who need to act have had at least 7 days.
• Later disclosure may be requested by Note Systems once, for up to 30 days, where a fix depends on a governance vote that has not yet completed. Beyond day 120 the reporter may publish regardless.

If Note Systems does not respond within the acknowledgement or triage targets, the reporter may escalate publicly that a report is outstanding, without technical detail, at any time.

Out of Scope for Disclosure Rewards

Reports about the following are read and acted on where needed, but are not eligible for a bounty: third-party services, social engineering, physical security, spam or rate limiting on the site, missing security headers without a demonstrated impact, and clickjacking on pages with no sensitive action. The full list is on the bug bounty page.

Acknowledgements

Researchers who report a valid vulnerability are credited here, with their permission, once the issue is fixed and disclosed.

No public acknowledgements are listed yet.