Radiant

Radiant Capital is the first omnichain money market atop LayerZero, where users can deposit and borrow a variety of supported assets across multiple chains, seamlessly.

$RDNT, an OFT-20, is Radiant's native utility token. Layer Zero Labs’ omnichain fungible token (OFT) interoperability solution enables native, cross-chain token transfers. With LayerZero’s guarantee of valid delivery, the token is burned on the source chain and minted on the destination chain directly through the token contract.

Ecosystem participants can lock Radiant liquidity tokens to receive a share of protocol revenue from borrowers’ loan repayments in the form of a variety of blue chip assets. Locking RDNT liquidity also activates the ability to earn $RDNT emissions from borrowing and lending within the money market, as well as rights to vote in governance on the future direction of the protocol.

For more information about Radiant, please visit radiant.capital

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

For the purposes of determining report validity, this is a Primacy of Impact program. Learn more about report validity best practices here: Best Practice - Primacy of Impact vs Primacy of Rules.

All smart contract and web/app bug reports must come with a PoC with an end-effect impacting an asset-in-scope in order to be considered for a reward. Explanations and statements are not accepted as PoC and code is required.

Rewards for critical smart contract vulnerabilities are further capped at 10% of the funds at risk. In cases of repeatable attacks, only the first attack is considered unless the smart contract cannot be upgraded or paused. However, there is a minimum reward of USD 20 000 for Critical smart contract bug reports.

Rewards for high smart contract vulnerabilities are further capped at 100% of the funds at risk. In cases of repeatable attacks, only the first attack is considered unless the smart contract cannot be upgraded or paused. However, there is a minimum reward of USD 5 000 for High smart contract bug reports.

Rewards for medium smart contract vulnerabilities with direct monetary impact are further capped at 100% of the funds at risk. In cases of repeatable attacks, only the first attack is considered unless the smart contract cannot be upgraded or paused. However, there is a minimum reward of USD 1 000 for Medium smart contract bug reports. All other valid Medium smart contract bug reports will be rewarded USD 1 000.

Known issues highlighted in the following audit reports are considered out of scope:

• https://github.com/peckshield/publications/tree/master/audit_reports/PeckShield-Audit-Report-RadiantV2-v1.0.pdf
• https://twitter.com/zokyo_io/status/1638856299629907973
• https://github.com/blocksecteam/audit-reports/blob/main/solidity/blocksec_radiant_v2.0.pdf

Payouts are handled by the Radiant team directly and are denominated in USD. However, payouts are done in USDC.

Smart Contract

Websites and Applications

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.

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.

For more information on PoCs please visit: Proof of Concept (PoC) Guidelines and Rules

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.

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. You may compensate a disclosing party if you would like to after all known vulnerability details have been disclosed.
• 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.

The following vulnerabilities are excluded from the rewards for this bug bounty program:

• Attacks that the reporter has already exploited themselves, leading to damage
• Attacks requiring access to leaked keys/credentials
• Attacks requiring access to privileged addresses (governance, strategist)

Smart Contracts and Blockchain

• Incorrect data supplied by third party oracles
  • Not to exclude oracle manipulation/flash loan attacks
• Basic economic governance attacks (e.g. 51% attack)
• Lack of liquidity
• Best practice critiques
• Sybil attacks
• Centralization risks

Websites and Apps

• Theoretical vulnerabilities without any proof or demonstration
• Attacks requiring physical access to the victim device
• Attacks requiring access to the local network of the victim
• Reflected plain text injection ex: url parameters, path, etc.
  • This does not exclude reflected HTML injection with or without javascript
  • This does not exclude persistent plain text injection
• Self-XSS
• Captcha bypass using OCR without impact demonstration
• CSRF with no state modifying security impact (ex: logout CSRF)
• Missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”) without demonstration of impact
• Server-side non-confidential information disclosure such as IPs, server names, and most stack traces
• Vulnerabilities used only to enumerate or confirm the existence of users or tenants
• Vulnerabilities requiring un-prompted, in-app user actions that are not part of the normal app workflows
• Lack of SSL/TLS best practices
• DDoS vulnerabilities
• Feature requests
• Issues related to the frontend without concrete impact and PoC
• Best practices issues without concrete impact and PoC
• Vulnerabilities primarily caused by browser/plugin defects
• Leakage of non sensitive api keys ex: etherscan, Infura, Alchemy, etc.
• Any vulnerability exploit requiring browser bugs for exploitation. ex: CSP bypass

The following activities are prohibited by this bug bounty program:

• Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
• Any testing with pricing oracles or third party smart contracts
• Attempting phishing or other social engineering attacks against our employees and/or customers
• Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
• Any denial of service attacks that are executed against project assets
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty