GoNode takes security seriously. This document describes how to report security vulnerabilities, how we respond to reports, and how we coordinate disclosure.

Security updates are provided for the following versions:

Once GoNode reaches 1.0 (expected Season 6), we will follow semantic versioning with security updates for the current major version and the previous one.

Public issues are visible to attackers before we can fix the problem. Please use the private reporting channels below.

Primary: Email

Send reports to: security@gonode.dev

GPG encryption is strongly encouraged. Our public key is published at:

• https://simplego.dev/gonode-security.gpg (once live)
• Key fingerprint: (to be published at Phase 1 launch)

Secondary: GitHub Security Advisories

Use GitHub's private vulnerability reporting feature at: https://github.com/saschadaemgen/GoNode/security/advisories/new

This creates a private discussion between you and the maintainers.

What to include in your report:

1. Vulnerability type (e.g., remote code execution, privilege escalation,
   information disclosure, smart contract exploit, cryptographic flaw)

2. Affected component(s) (e.g., service node runtime, specific smart
   contract, wire protocol, onion routing)

3. Impact assessment (what an attacker can do)

4. Steps to reproduce (or proof of concept code)

5. Your environment (OS, Go version, GoNode version, network)

6. Suggested remediation (if you have one)

7. Your preferred attribution for the acknowledgement (real name,
   handle, or anonymous)

8. Whether you plan to publish research about this (and timeline)

We commit to the following response timeline:

Critical vulnerabilities (remote code execution, fund loss, key compromise) may be fixed and deployed faster, with disclosure delayed until operators have updated.

We use a simplified severity scale:

A formal bug bounty program will launch at Phase 2 (Season 3, approximately month 14 of the project). Until then, we acknowledge researchers through:

• Public thanks in release notes
• Attribution in our CONTRIBUTORS.md
• Swag from the Foundation (stickers, t-shirts)
• Potential airdrop eligibility if substantial

Planned bounty structure (Phase 2+):

Bounties will be paid in the researcher's choice of EURC, USDC, or GoCoin (post-TGE).

• GoNode service node runtime (github.com/saschadaemgen/GoNode)
• Smart contracts deployed to Arbitrum One
• Client library integrations
• Wire protocol implementation
• Onion routing layer
• Swarm coordination protocol
• Audit challenge protocol
• Official Foundation websites (simplego.dev/gonode)

The following are excluded from responsible disclosure but may still interest us:

• Third-party integrations (report to the third party)
• Vulnerabilities in upstream dependencies (Go stdlib, OpenZeppelin, etc.) - report to upstream first
• Social engineering attacks against individuals
• Physical attacks against hardware
• DDoS attacks (except architectural amplification issues)
• Vulnerabilities requiring already-compromised user credentials
• Outdated software versions not under active support
• Issues in test/staging environments (unless they indicate production issues)

We ask that security researchers:

• Do not access, modify, or delete data belonging to other users
• Do not disrupt network operations during testing
• Stay within the scope described above
• Report vulnerabilities promptly once confirmed
• Follow coordinated disclosure timelines
• Do not use findings for personal gain (beyond authorised bounties)

Researchers who follow these guidelines will not face legal action for their research activities.

We follow a 90-day coordinated disclosure timeline, consistent with industry standards (Project Zero, CERT/CC):

Day 0:   Vulnerability reported privately
Day 0-7: Triage and severity assessment
Day 7:   Acknowledgement of receipt sent
Day 7-14: Reproduction and impact analysis
Day 14:  Fix development begins (high/critical)
Day 30:  Draft fix ready for internal review
Day 60:  Fix ready for deployment
Day 60-75: Operators notified via private channel, asked to update
Day 75:  Fix deployed, network transitioning to patched version
Day 90:  Public disclosure with CVE (if applicable)

Adjustments:

• Earlier disclosure may be coordinated if the vulnerability is already being exploited
• Later disclosure may be requested for particularly complex issues or if operators need more time to update
• Immediate disclosure is never done without coordination except in extreme circumstances

Smart contracts have unique security considerations because they cannot be patched like traditional software. Our approach:

• Minimum 2 independent security audits before mainnet
• Formal verification for critical paths (where feasible)
• Bug bounty on testnet deployments
• Extensive unit and integration testing (95%+ coverage)

• No upgrade mechanisms for economic logic (intentional)
• Timelock on parameter changes (minimum 24 hours)
• Multi-sig control during Phase 0-3 (3-of-5)
• Deployer keys burned at Phase 4 (month 36)
• Continuous monitoring via Forta agents

If a critical smart contract vulnerability is discovered post-deployment:

Option 1: Pausable functions (Phase 0-3 only)
  - Foundation multisig can pause affected functions
  - Users protected while fix developed
  - Pause function removed at Phase 4

Option 2: Migration contract
  - Deploy new contract
  - Users migrate funds from old to new
  - Old contract remains but deprecated

Option 3: Live with the bug
  - If severity is low and no fix is safe
  - Document publicly, mitigate off-chain

We cannot guarantee recovery of user funds in the event of a critical smart contract exploit. Users should understand this risk.

GoNode relies on several cryptographic primitives. If you find weaknesses:

• In our implementations: report via security@gonode.dev
• In underlying algorithms (Ed25519, X25519, AES, etc.): report to the algorithm maintainers, notify us for awareness
• In our protocol design: report via security@gonode.dev for architectural discussion
• Post-quantum concerns: especially welcome, as we actively monitor this space

Specific cryptographic dependencies:

• Emergency releases: Published to main branch, announced immediately via all channels
• Security releases: Published with 24-hour operator notification window
• Regular releases: Include accumulated security improvements

Operators should subscribe to at least one:

• Security mailing list: security-announce@gonode.dev (once live)
• GitHub security advisories: watch the repository
• Matrix channel: #gonode-security:simplego.dev
• RSS feed: simplego.dev/gonode-security.rss

Nodes that run outdated software may be flagged and receive reduced rewards.

For details on GoNode's security architecture, threat model, and defensive measures, see:

• ARCHITECTURE_AND_SECURITY.md - Full threat model
• WIRE_PROTOCOL.md - Protocol-level security
• SMART_CONTRACTS.md - On-chain security

Security researchers who have contributed to GoNode's security will be listed here. Contributions are categorised by severity of finding.

This section will be populated as researchers report vulnerabilities. First entries expected during Phase 1 testnet.

GoNode Security Policy v1 - April 2026 IT and More Systems, Recklinghausen, Germany