> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notareum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security disclosure

# Security Disclosure

Notareum handles cryptographically signed identity for blockchain resources, collateralized validator economics, and governance-controlled protocol parameters. Security is a protocol-wide priority. This page defines how to report a vulnerability, the disclosure timeline you can expect, the bug bounty structure, and the scope.

## Reporting

Contact: `security@notareum.org`

Do not file public GitHub issues, forum posts, Discord messages, or tweets for security-relevant findings. Public disclosure before a coordinated fix exposes users to avoidable harm and disqualifies the finding from bounty eligibility.

Include:

1. A concise description of the vulnerability.
2. Affected component (contract address, SDK package + version, dApp URL).
3. Impact: what a malicious actor could achieve.
4. Reproduction steps or a working proof of concept.
5. Your preferred bounty-reward recipient address (EVM address is sufficient).
6. Whether you want public attribution after disclosure.

## PGP

For sensitive disclosures, encrypt your report to the security PGP key.

* Key ID: `TBD, published alongside the first audit report`
* Fingerprint: `TBD`
* Key URL: `https://notareum.org/.well-known/security-pgp.asc`

The key is refreshed annually. Always fetch the current key from the URL above, not from caches.

## Acknowledgement

Initial acknowledgement within **48 hours** of report receipt. Triage result and severity assessment within **5 business days**. Fix targets depend on severity (see timeline below).

## Disclosure timeline

Coordinated disclosure operates on a **90-day** standard timeline:

1. **Day 0.** Report received. Acknowledgement sent within 48 hours.
2. **Day 0–5.** Triage, severity assessment, internal reproduction.
3. **Day 5–30.** Fix development for Critical/High. Shorter for trivial fixes; longer for invariant-level redesigns may warrant an extension request.
4. **Day 30–60.** Audit of the fix by independent reviewers where warranted.
5. **Day 60–90.** Coordinated deployment across affected contracts and SDKs. Advisory drafted.
6. **Day 90.** Public advisory published. Researcher attributed (if they opted in). CVE filed where applicable.

Extensions beyond 90 days are negotiated if the fix requires governance or a contract upgrade via the standard 7–14 day timelock. Researchers are kept informed throughout.

## Severity

Severity is assessed using a CVSS-style qualitative scale adapted for crypto-economic systems:

* **Critical.** Direct theft of user funds, arbitrary minting, indefinite loss of protocol control, or invariant violation in a core contract.
* **High.** Indirect theft (requires secondary conditions), severe economic griefing (forced slashing, stuck validators), material governance bypass.
* **Medium.** Denial of service on non-critical paths, unintended access to governance metadata, signature-scheme weaknesses under non-standard assumptions.
* **Low.** Informational, low-impact inconsistency, documentation-only issues.

## Bug bounty

A reward is paid in `$NOTA` at the severity-appropriate tier. Amounts below are illustrative and ratified by governance at program activation; see the latest bounty announcement on `forum.notareum.org` for authoritative figures.

| Severity | Reward range (NOTA) |
| -------- | ------------------- |
| Critical | 250,000 – 1,000,000 |
| High     | 50,000 – 250,000    |
| Medium   | 10,000 – 50,000     |
| Low      | 1,000 – 10,000      |

Rewards within the range are determined by:

1. Impact magnitude and reach (funds at risk, number of affected users).
2. Exploitability (immediate vs requires improbable preconditions).
3. Report quality (clarity, reproducibility, patch suggestion).
4. Uniqueness (first reporter of a given class of bug).

Duplicate submissions: only the first qualifying report per issue is eligible. Subsequent reporters of the same underlying issue may receive acknowledgement but not the bounty.

Payouts occur after the coordinated disclosure window closes. Researchers holding sanctioned addresses or located in sanctioned jurisdictions are ineligible; treasury compliance constraints apply.

## Scope

### In scope

* All deployed Notareum contracts on supported networks: `NotaRegistry`, `VerificationEngine`, `ValidatorStaking`, `NOTAToken`, `veNOTA`, `FeeManager`, `SlashingManager`, `AccessManager`, `Governor`, and any `NotareumVestingVault` instances referenced in the release manifest.
* Source in the `contracts` repository on `main` and any tagged release.
* The TypeScript SDK (`@notareum/sdk`), Python SDK (`notareum`), and Rust SDK (`notareum`).
* The reference dApp (`dapp` repository).
* The canonical `addresses.json` distribution and its signature-verification path.

### Out of scope

* Findings that require physical access to a user's device or social-engineering the user.
* Denial of service against L1 gas markets (e.g., congestion).
* Attacks on third-party dependencies (OpenZeppelin, ethers, web3.py, alloy) unless the attack is made exploitable by Notareum-specific usage.
* Theoretical attacks without demonstrable exploitability under realistic parameters.
* Informational gas optimizations that do not enable an attack.
* Findings against end-user wallets that happen to integrate Notareum; those go to the wallet vendor.

## Safe harbor

Good-faith security research conducted under this policy will not be pursued for:

1. Violations of applicable anti-hacking laws (e.g., CFAA).
2. Violations of anti-circumvention laws (e.g., DMCA).
3. Breaches of Notareum's terms of service.

Provided that the researcher:

* Makes a good-faith effort to avoid privacy violations, data destruction, or service disruption.
* Limits testing to accounts they own or have explicit permission to use.
* Reports promptly and gives Notareum a reasonable opportunity to remediate before public disclosure.
* Does not exploit the vulnerability for direct personal benefit beyond the bounty.

Researchers who operate within these limits are authorized to conduct the research described, and Notareum will not initiate legal action. We will cooperate with researchers facing third-party legal action arising from authorized research performed in good faith under this policy.

## Post-mortem policy

After any exploited vulnerability (in scope or out), Notareum publishes a post-mortem within 30 days of resolution containing:

* Timeline of the incident from discovery to resolution.
* Root cause analysis.
* Impact assessment (funds affected, users affected).
* Fix description and verification.
* Process improvements adopted to prevent recurrence.

Post-mortems are published at `github.com/notareum/audits/postmortems` and cross-posted on the Mirror blog.

## Hall of fame

Researchers who responsibly disclose vulnerabilities are listed (with permission) on a community hall of fame at `security.notareum.org`. Hall-of-fame entries include the researcher handle, date, severity, and a sanitized description of the finding.

## Not a vulnerability

A few classes of report we commonly receive but do not treat as vulnerabilities:

* "The contract is upgradeable." UUPS upgradeability is an intentional design, gated by timelocked governance.
* "Validators can collude." Collusion is an explicit threat model; the protocol addresses it via slashing, stake requirements, and economic cost analysis. Reports must show an attack cheaper than the modeled cost bound.
* "A user can create a misleading `.nota`." Issuer misrepresentation is covered by verification levels and revocation; this is the protocol's normal operating model.
* "Gas costs are high on L1." Out of scope.

## Related pages

* [Community](community.md)
* [Whitepaper](whitepaper.md)
* [Smart Contracts Overview](../smart-contracts/overview.md)
* [Changelog](../reference/changelog.md)