IN-SCOPE VULNERABILITIES

The following focus areas are illustrative only and do not independently establish bounty eligibility. A finding qualifies for a reward only if it demonstrates an explicitly listed impact under the Security Impact & Severity Classification section:

• Stealing or loss of funds
• Unauthorized transaction
• Transaction manipulation
• Price manipulation
• Fee payment bypass
• Balance manipulation
• Contracts execution flows
• Cryptographic flaws

Security Impact & Severity Classification

Only vulnerabilities affecting in-scope deployed smart contracts and demonstrating a realistic, reproducible security impact are eligible for rewards.

Critical Severity

Vulnerability Type	Classification Criteria
Theft of user funds	Direct unauthorized theft exceeding $250,000
Permanent freezing of funds	Irrecoverable freezing of user funds exceeding $250,000
MEV exploitation	Exploitable contract vulnerability causing direct unauthorized financial losses exceeding $250,000
Governance manipulation	Unauthorized manipulation of governance voting that materially changes the actual execution outcome
Protocol insolvency	A vulnerability causing a demonstrable, unrecoverable protocol shortfall exceeding $250,000

Note: Ordinary arbitrage, expected slippage, legitimate trading activities, and normal market price fluctuations do not automatically qualify as Critical vulnerabilities.

Critical Severity Reward Calculation

• The base reward for Critical smart contract vulnerabilities is 10% of the directly affected funds, with a minimum of $30,000 and a maximum of $250,000, while the final reward is determined by the team based on economic impact, funds at risk, and other relevant factors.
• Reward = min(250,000, max(30,000, 10% × Funds Directly Affected))
• For Critical vulnerabilities involving governance manipulation, protocol insolvency, MEV, or other impacts that cannot be directly measured by stolen funds, rewards must be evaluated based on the actual consequences rather than automatically applying the financial-loss formula.

High Severity

Vulnerability Type	Classification Criteria
Theft of user funds	Direct unauthorized theft exceeding $5,000 and up to $250,000
Temporary freezing of funds	User funds exceeding $5,000 remain inaccessible for at least 24 consecutive hours
Permanent freezing of rewards	Permanent inability to claim accrued rewards exceeding $5,000

Temporary freezing must result from an actual smart contract vulnerability. Expected protocol behavior, normal transaction failures, temporary RPC issues, and insufficient market liquidity do not independently qualify.

Fund theft vulnerabilities must have a realistically exploitable attack path. Theoretical abnormal balances without demonstrated financial impact are insufficient.

Medium Severity

Vulnerability Type	Classification Criteria
Unbounded Gas consumption	Exploitable abnormal Gas consumption causing measurable operational or financial impact
Contract execution failure	Smart contract unable to operate due to lack of token funds
Block Stuffing	Demonstrable disruption of contract operations through economically feasible block-resource exploitation
Gas theft	Unauthorized extraction of Gas-related assets exceeding $1,000

Medium-severity vulnerabilities must demonstrate actual, reproducible impact. Normal Gas costs, expected execution failures, and theoretical inefficiencies without security consequences are excluded.

Low Severity

Reward: $100–$1,000 USD

Reproducible smart contract issues that cause measurable deviations from documented functionality without direct financial loss or material security impact.

Eligible findings must:

Affect an explicitly in-scope contract.

Demonstrate actual functional or security impact.

Include a valid Proof of Concept (PoC).

Code style issues, best-practice recommendations, feature requests, and purely theoretical vulnerabilities are excluded.

General Rules & Exclusions

1. Proof of Concept: A reproducible PoC demonstrating the actual vulnerability and its impact is mandatory.

2. Funds at Risk: Only funds directly accessible through a realistic exploit are counted. Total TVL, future deposits, projected fees, and hypothetical losses are excluded.

3. Repeatable Attacks: Hypothetical repeated attacks are not automatically aggregated. Repeatability is evaluated based on realistic exploit conditions and demonstrably effective on-chain restrictions or mitigation mechanisms.

4. Protocol Fees: Only protocol fees directly exposed through the vulnerable execution path are counted. Future fee accruals are excluded. Withdrawal limits apply only when technically enforceable.

5. Privileged Access: Authorized DAO, Guardian, or administrator actions and centralization risks are excluded unless an exploitable unauthorized privilege escalation or access-control bypass is demonstrated.

6. Market Risks: Normal arbitrage, expected slippage, insufficient liquidity, impermanent loss, and ordinary market fluctuations are excluded. Oracle manipulation or flash-loan attacks exploiting an actual contract vulnerability remain eligible.

7. Duplicates & Known Issues: Previously reported vulnerabilities, publicly disclosed known issues, and multiple reports of the same root cause are not eligible for additional rewards.

8. Impact-Based Classification: Severity is determined by demonstrated exploitability and direct impact, not hypothetical worst-case scenarios.

9. Testing Restrictions: Testing must be conducted in local or forked environments. Unauthorized attacks against production contracts or user funds are prohibited.

10. Effective Date: These rules apply to reports submitted after their official publication and do not retroactively modify previously applicable terms.

Ref Exchange — DEX Smart Contracts

• Repository: https://github.com/ref-finance/ref-contracts
• Directory: ref-exchange/src/
• Files explicitly identified in the historical scope include:
  • account_deposit .rs
  • action .rs
  • admin_fee .rs
  • errors .rs
  • legacy .rs
  • lib .rs

Boosted Farming — Yield Farming Smart Contracts

• Repository: https://github.com/ref-finance/boost-farm
• Directory: contracts/boost-farming/src/
• Including:
  • lib .rs
  • management .rs
  • owner .rs
  • seed .rs
  • seed_farm .rs
  • storage_impl .rs
  • token_receiver .rs
  • utils .rs
  • view .rs

OUT-OF-SCOPE VULNERABILITIES

Privileged Access and Centralization Risks

The following issues are generally excluded:

• Centralization risks alone.
• Actions performed by administrators or governance accounts within their legitimately assigned permissions.
• Attacks that depend on leaked private keys or access credentials.
• Attacks that require control of an already privileged account without exploiting an additional privilege escalation or access control vulnerability.
• Reports that merely identify excessive permissions held by administrators, Guardians, or DAO roles without demonstrating an eligible vulnerability.

However, if an unprivileged user can bypass authorization checks, gain unauthorized privileges, or cause other direct security impacts covered by the program, the issue should be evaluated based on its actual PoC rather than automatically dismissed as a centralization risk.

Economic and External Dependency Risks

The following issues are generally excluded:

• Incorrect price data provided by third-party oracles alone. However, this does not automatically exclude oracle manipulation or flash loan attacks caused by vulnerabilities in the protocol's own code.
• Attacks that require underlying blockchain economic attacks, such as 51% attacks.
• Price impact caused solely by insufficient market liquidity.
• Impacts caused by Sybil attacks.
• Natural depegging of external stablecoins, rather than losses directly caused by protocol code vulnerabilities.

Other Exclusions

• Issues already disclosed in the specified historical audit reports.
• Network-level DoS
• Code best-practice recommendations without a concrete security impact.
• Frontend issues lacking a valid PoC.
• Issues involving only test files or configuration files, unless they are explicitly included in scope and meet the applicable reward criteria.
• Feature requests or product improvement suggestions.
• Keys or API tokens found in GitHub repositories without evidence that they are valid and usable in production.
• Attacks that rely on phishing or social engineering targeting employees or users.
• Activities in which security researchers have already exploited vulnerabilities and caused actual damage.

These exclusions do not necessarily mean that the reported issues have no security relevance. They indicate that such issues may not qualify for paid rewards under the historical Bug Bounty Program.

• Make every effort not to damage or restrict the availability of products, services, or infrastructure. Prohibited direct attack testing against deployed targets on live mainnet or public testnets.
• Avoid compromising any personal data, interruption, or degradation of any service
• Don’t access or modify other user data, localize all tests to your accounts
• Perform testing only within the scope
• Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam
• In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
• Don’t break any law and stay in the defined scope
• Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
• In case that your finding is valid you might be asked for extra KYC verification to proceed with payments
• Perform testing on a private testnet wherever possible
• For more information, check: https://guide.rhea.finance/
• Rhea Finance Historical Audit Reports: https://guide.rhea.finance/developers/audits/previous-audits

Reward Payments

• Payments may be made in USDT, USDC, NEAR, wNEAR, or RHEA on NEAR Protocol.
• The actual payment token is determined by the team.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
• No vulnerability disclosure, including partial is allowed for the moment.
• Please do NOT publish/discuss bugs

We are happy to thank everyone who submits valid reports which help us improve the security. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• ONLY USE YOUR HackenProof ADDRESS (in case of violation, no bounty can be awarded)
• Provide detailed but to-the point reproduction steps
• Employees, spouses, partners, or families of employees, and former employees of Ref Finance team, and any subsidiaries, are not eligible to participate in the Bug Bounty program.