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. Reports in scope of the bug bounty are rewarded under its terms; everything else is still welcome and is acknowledged on this page with the reporter’s permission.

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

Channel	Address	Use it for
Email	security@note.systems	All reports. Encrypt with the PGP key below
PGP key	/security/pgp.txt key to be published	Encrypting email reports and verifying our replies
X direct message	@notesystems	First contact only: request a PGP key or confirm receipt. Never send exploit detail over X
Emergency	Subject line beginning [CRITICAL] to security@note.systems	An exploit that is live or imminent on a deployment holding funds

The email address is monitored continuously. Only the security committee (three members appointed by governance) reads the mailbox and the X inbox. Nobody else at Note Systems sees a report before triage.

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 raises the payout within the severity range.
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

Copy the block below into a file, fill it in, encrypt it to the key at /security/pgp.txt and attach it to your email.

-----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

Step	Target	What you receive
Acknowledgement	24 hours	A report identifier and the name of the committee member handling it
Triage	72 hours	Provisional severity, whether the report is in bounty scope, and any questions
Fix plan	7 days for Critical and High	How the fix will be deployed: pause, upgrade through UpgradeTimelock, core replacement, or parameter change; see Upgrade safety
Payout	14 days from severity confirmation	Payment under the bug bounty terms, after KYC where required
Disclosure	90 days from report, or earlier by agreement	Joint publication, credit, and the advisory text for your review

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. Timelock 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.

Date	Researcher	Severity	Advisory
—	—	—	None yet