Radiant

Triaged by Immunefi

Submit a Bug
29 March 2023
Live since
No
KYC required
$200,000
Maximum bounty
23 May 2024
Last updated

Program Overview

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 by Threat Level

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 low smart contract bug reports will be rewarded USD 1 000.

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

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

Smart Contract

Critical
Level
USD $20,000 to USD $200,000
Payout
PoC Required
High
Level
USD $5,000 to USD $20,000
Payout
PoC Required
Medium
Level
USD $1,000 to USD $5,000
Payout
PoC Required
Low
Level
USD $1,000
Payout
PoC Required

Websites and Applications

Critical
Level
USD $20,000
Payout
PoC Required
High
Level
USD $6,000
Payout
PoC Required
Medium
Level
USD $2,000
Payout
PoC Required

Assets in scope

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.

Impacts in scope

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table.

Smart Contract

  • Any governance voting result manipulation
    Critical
    Impact
  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
    Critical
    Impact
  • Permanent freezing of funds
    Critical
    Impact
  • Protocol insolvency
    Critical
    Impact
  • Theft of unclaimed yield
    High
    Impact
  • Permanent freezing of unclaimed yield
    High
    Impact
  • Temporary freezing of funds for at least 3 minutes
    High
    Impact
  • Smart contract unable to operate due to lack of token funds
    Medium
    Impact
  • Block stuffing for profit
    Medium
    Impact
  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
    Medium
    Impact
  • Unbounded gas consumption
    Medium
    Impact
  • Smart contract fails to deliver promised returns, but doesn’t lose value
    Low
    Impact

Websites and Applications

  • Taking down the application/website
    Critical
    Impact
  • Execute arbitrary system commands
    High
    Impact
  • Retrieve sensitive data/files from a running server such as /etc/shadow, database passwords, and blockchain keys(this does not include non-sensitive environment variables, open source code, or usernames)
    High
    Impact
  • Taking state-modifying authenticated actions (with or without blockchain state interaction) on behalf of other users without any interaction by that user, such as, changing registration information, commenting, voting, making trades, withdrawals, etc
    High
    Impact
  • Subdomain takeover with already-connected wallet interaction
    High
    Impact
  • Direct theft of user funds
    High
    Impact
  • Malicious interactions with an already-connected wallet such as modifying transaction arguments or parameters, substituting contract addresses, submitting malicious transactions
    High
    Impact
  • Changing non-sensitive details of other users (including modifying browser local storage) without already-connected wallet interaction and with up to one click of user interaction, such as changing the first/last name of user, or en/disabling notification
    Medium
    Impact
  • Improperly disclosing confidential user information such as email address, phone number, physical address, etc
    Medium
    Impact
  • Subdomain takeover without already-connected wallet interaction
    Medium
    Impact

Out of Scope & Rules

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

  • Attacks that have been addressed in a prior or ongoing audit
  • 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
  • Cosmetic issues
  • 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 POC 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