Radiant

All smart contracts of Radiant can be found at https://github.com/radiant-capital/v2. However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.

Though only the proxy contracts are listed as in-scope, current implementation and any further updates to the implementation contracts are considered in scope. When reporting a bug, please make sure to select the relevant proxy smart contract as the target.

Impacts only apply to assets in active use by the project like contracts on mainnet or web/app assets used in production. Any impact that applies to assets not in active use, like test or mock files, are out-of-scope of the bug bounty program unless explicitly mentioned as in-scope.

Smart Contracts - PoC, Smart Contract bug reports are required to include a runnable Proof of Concept (PoC) in order to prove impact.

Specific to Mainnet Deployment -

• The RDNT token is not intended to ever be part of the rewardTokens list in the MFD contract.
• There is no intention of setting the Eligibility mode to DISABLED.
• Chainlink feeds are not covered by this bounty program.

Web/App - Bug reports are required to include a Proof of Concept (PoC) in order to prove impact. In general, all blackbox testing is allowed unless it takes down the application/website. In case of such, the whitehat must ask for permission from the project in the Immunefi dashboard first if the attack would take down the application/website.

Whitehats are highly encouraged to review any potential subdomains and what specific port(s) are in scope. Even though the domain may be the same, different ports may point to different assets.

Proof of Concept (PoC) Requirements

The PoC must clearly demonstrate how the issue would be exploitable in a production environment. Theoretical or non-reproducible findings will not be considered. For more information on PoCs please visit: Proof of Concept (PoC) Guidelines and Rules.

Ethical Behavior Requirements:

Responsible disclosure is predicated on ethical behavior. These guidelines outline best practices for the community as whole, whether you are reporting, or the recipient of a report. By stating that you adhere to this policy, you’re claiming to handle vulnerability information ethically, and abide by the following:

• Do not attempt to leverage a vulnerability, or information of its existence, as part of a financial trading strategy or otherwise for financial gain.
• Do not attempt to compromise systems upon which development of a product relies; including but not limited to compromising development systems, accounts, domains, email etc.
• Do not attempt to sell vulnerability information or exploits.
• Do not ask for any form of compensation from an affected party outside of the Immunefi platform.
• Do not disclose a bug or vulnerability on mailing lists, public boards, forums, social media or any other channel prior to Responsibly Disclosing to the organizations you have a published relationship with
• Do not attempt any illegal acts, including phishing, physical attacks, DDoS, or any attempt to gain access without authorization

3rd Party Affected Projects:

In the case where we become aware of security issues affecting other projects that have never affected Radiant, our intention is to inform those projects of security issues on a best effort basis.

In the case where we fix a security issue in Radiant that also affects other projects, our intention is to engage in responsible disclosures with them as described in the adopted standard, subject to the deviations described in the deviations section below.

Deviations from the Standard:

In the case of a counterfeiting or fund-stealing bug affecting Radiant, however, we might decide not to include those details with our reports to partners ahead of coordinated release, as long as we are sure that they are not vulnerable.