Reporting Vulnerabilities

Relix takes security seriously. No matter how careful the design and implementation, a live network will always benefit from extra eyes reviewing its code, infrastructure, and configuration. If you discover a weakness in any Relix component, we want to hear about it quickly, privately, and with enough detail to fix it safely.

This page explains how to report vulnerabilities, what information is helpful, and what you can expect from the Relix team in return.

---

1. What is in scope?

In general, the following areas are considered in scope for vulnerability reports:

• Core protocol and node software

  • Consensus implementation

  • Networking and P2P layers

  • Execution engine and EVM integration

• Official Relix infrastructure

  • Public RPC endpoints operated by the Relix team

  • Official testnet infrastructure where clearly indicated

• First-party smart contracts and dApps

  • Contracts and frontends developed or maintained by the Relix core team

  • Staking, governance, bridge, or system contracts explicitly branded as part of Relix

• Documentation and configuration examples

  • Official guides that, if followed exactly, would lead to an insecure setup

  • Sample configs that expose users to unnecessary risk

Issues affecting third-party projects built on Relix (independent dApps, exchanges, or tools) should be reported directly to those teams. If you are unsure who owns a component, you can still contact us; we will try to route the information appropriately.

---

2. What is out of scope?

The following are usually not treated as security vulnerabilities:

• Typos, minor layout issues, or purely cosmetic problems

• General product feedback or UX complaints

• Attacks that require full compromise of a user’s own device or wallet

• Automated scanner output without proof of impact

• Theoretical weaknesses that cannot be demonstrated in a realistic scenario

That said, if you are unsure whether something matters, it is better to report it. We prefer a cautious report that turns out to be benign over a serious issue left unreported.

---

3. How to report a vulnerability

To keep users and validators safe, please do not disclose vulnerabilities publicly before the Relix team has had a chance to assess and address them.

You can report privately using one of the official channels:

• Email: a dedicated security contact address (to be published in the main docs / website footer)

• GitHub: security advisories or private issues in relevant relixchain repositories

• Direct contact: via the official Telegram or other agreed private channel, if you already work with the team

When you reach out, clearly label the message as a security issue or vulnerability report so it is triaged quickly.

---

4. Information that helps us investigate

A concise, well-structured report speeds up triage and fix deployment. Where possible, include:

• Summary

  • One or two sentences describing the issue and potential impact

• Impact

  • What could an attacker achieve?

  • Which users, validators, or systems are affected?

• Technical details

  • Exact component: repository, contract address, endpoint, or service

  • Relevant code snippets, commit hashes, or configuration fragments

  • Preconditions required for the attack to work

• Steps to reproduce

  • A minimal, clear set of steps or a script that reproduces the issue

  • Any test accounts or addresses you used during testing

• Environment

  • Network (Relix Testnet, internal dev environment, etc.)

  • Node/client version, OS, and tool versions where applicable

If you have ideas about how to fix the issue, feel free to include them, but they are not required. A clean reproduction is always more valuable than a speculative patch.

---

5. Responsible testing guidelines

We strongly encourage security research, but it must be done in a way that does not put users or the network at risk. In particular:

• Do not exploit beyond what is needed to demonstrate impact

  • Avoid stealing funds, disrupting service, or modifying real user data.

  • Use test accounts and minimal amounts wherever possible.

• Do not perform denial-of-service attacks on public infrastructure

  • Large-scale traffic floods or resource exhaustion tests should only be done with explicit prior approval.

• Do not access or attempt to access private data

  • If you accidentally encounter sensitive information (keys, credentials, logs), stop and include that fact in your report.

• Respect legal boundaries

  • Your testing should comply with local laws and any terms of service that apply.

If in doubt about whether a particular test is appropriate, ask first. A short message to the security contact can prevent accidental harm.

---

6. Our commitment to reporters

When you report a vulnerability privately and in good faith, you can expect the Relix team to:

• Acknowledge receipt

  • Confirm that we have seen your report and are investigating.

• Triage the issue

  • Assess severity and potential impact.

  • Determine whether immediate mitigation is needed.

• Communicate appropriately

  • Keep you informed about the status of the issue when possible.

  • Coordinate on timing of any public disclosure so users and operators have time to patch.

• Recognize your contribution

  • With your consent, credit you in release notes or a security acknowledgements page when the fix is deployed.

  • Where a formal bug bounty or rewards program exists, evaluate eligibility under those rules.

We do not pursue legal action against researchers who follow responsible disclosure practices and avoid harming users or the network.

---

7. Future bug bounty and incentives

As Relix moves closer to mainnet and the protocol surface stabilizes, a formal bug bounty program may be introduced to:

• Provide structured rewards for high-impact findings

• Encourage targeted review of critical components (consensus, staking, bridges, etc.)

• Offer clear rules for scope, reward tiers, and eligibility

Details of any such program will be published through:

• The official website: https://relixchain.com

• The Relix GitHub organization: https://github.com/relixchain

• Official social channels (X, Telegram, and others)

Until then, we still value and welcome responsible security research, even in the absence of a formal bounty.

---

8. Summary

If you see something that might compromise Relix, tell us privately, clearly, and with enough detail to act on it. In return, we will treat your report seriously, work to fix the underlying issue, and recognize your role in helping keep the network safe.

Security is not a one-time audit; it is an ongoing collaboration between protocol developers, infrastructure operators, dApp teams, and independent researchers. Your reports are a critical part of that collaboration.