Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/reserve-protocol/reserve-index-dtf/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Reserve Protocol is committed to the security of the Reserve Folio protocol and rewards security researchers who responsibly disclose vulnerabilities through our bug bounty program.

Responsible Disclosure

We value the security community’s contributions and provide fair compensation for valid vulnerability reports that help keep the protocol safe.

​
Scope

The bug bounty program covers vulnerabilities in the Reserve Folio smart contracts and associated infrastructure.

​
In Scope

Primary Scope:
  • Folio.sol
  • FolioDeployer.sol
  • FolioProxy.sol
  • StakingVault.sol
  • FolioGovernor.sol
  • GovernanceDeployer.sol
DAO Contracts:
  • FolioDAOFeeRegistry.sol
  • FolioVersionRegistry.sol
  • Rebalancing mechanisms
  • Auction systems
  • Access control
  • Fee calculations
  • Mint/redeem operations
  • Staking and rewards
  • Governance operations

​
Out of Scope

The following are NOT eligible for bounties:
  • Known issues from previous audits (if not yet patched)
  • Issues in third-party contracts or tokens
  • Front-end or UI issues (unless they expose smart contract vulnerabilities)
  • Phishing or social engineering attacks
  • Network-level attacks (DDoS, etc.)
  • Issues requiring unlikely governance actions
  • Gas optimization suggestions (unless they prevent DoS)

​
Severity Classification

​
Critical

Critical Severity

Definition: Vulnerabilities that can lead to:
  • Direct theft of user funds
  • Permanent freezing of funds
  • Protocol insolvency
  • Unauthorized minting of shares
Examples:
  • Exploit allowing theft of all Folio assets
  • Bypass of access controls for critical functions
  • Arithmetic errors causing fund loss

​
High

High Severity

Definition: Vulnerabilities that can lead to:
  • Theft of funds requiring specific conditions
  • Temporary freezing of funds
  • Manipulation of rebalancing/auctions for profit
  • Severe governance manipulation
Examples:
  • MEV attacks exceeding normal bounds
  • Auction manipulation causing significant value leakage
  • Reentrancy allowing unauthorized state changes

​
Medium

Medium Severity

Definition: Vulnerabilities that can lead to:
  • Limited fund loss under specific conditions
  • Griefing attacks with significant impact
  • Minor governance manipulation
  • DoS of specific functions
Examples:
  • Gas-based DoS attacks on auctions
  • Edge cases in fee calculations
  • Minor price manipulation

​
Low

Low Severity

Definition: Vulnerabilities with minimal impact:
  • Very limited fund risk
  • Griefing with minimal impact
  • Information disclosure
Examples:
  • Gas inefficiencies causing minor issues
  • Non-critical information leaks
  • Edge cases with negligible impact

​
Reward Structure

Rewards are determined based on severity, impact, and quality of the report.
Exact bounty amounts are determined on a case-by-case basis considering:
  • Severity and impact
  • Quality of the report
  • Presence of proof-of-concept
  • Suggested fix
  • Responsible disclosure practices

​
Typical Ranges

SeverityTypical Reward Range
Critical50,000−50,000 - 250,000+
High10,000−10,000 - 50,000
Medium2,000−2,000 - 10,000
Low500−500 - 2,000
Exceptional findings with high-quality reports, PoCs, and suggested fixes may receive rewards at the higher end of the range or beyond.

​
How to Report

1

Prepare Your Report

Include:
  • Clear description of the vulnerability
  • Steps to reproduce
  • Proof of concept (code or test)
  • Potential impact assessment
  • Suggested fix (optional but appreciated)
2

Contact the Team

DO NOT create a public GitHub issue or discuss publicly.Contact through:
  • Security email: [Contact through official Reserve channels]
  • Immunefi platform (if available)
  • Direct message to core team members
Public disclosure before the team has patched the issue disqualifies you from bounty rewards.
3

Wait for Acknowledgment

The team will acknowledge receipt within 48 hours and provide an initial assessment within 7 days.
4

Collaborate on Fix

Work with the team to:
  • Verify the vulnerability
  • Develop and test a fix
  • Coordinate disclosure timing
5

Receive Reward

After the fix is deployed:
  • Reward amount is determined
  • Payment is processed
  • Public acknowledgment (if desired)

​
Report Quality Guidelines

​
Excellent Reports Include

Clear Description

Concise explanation of the vulnerability and its root cause

Reproduction Steps

Step-by-step instructions to reproduce the issue

Proof of Concept

Working code demonstrating the vulnerability

Impact Analysis

Assessment of potential damage and affected users

Suggested Fix

Proposed solution or mitigation strategy

Edge Cases

Discussion of related edge cases or variations

​
Example Report Structure

# Vulnerability Report: [Title]

## Summary
Brief one-paragraph description

## Severity
[Critical/High/Medium/Low] with justification

## Vulnerability Details
Detailed technical explanation

## Proof of Concept
```solidity
// Working code example

​
Impact

  • Who is affected
  • What can be stolen/broken
  • Likelihood of exploitation

​
Steps to Reproduce

  1. Step one
  2. Step two …

​
Suggested Fix

Proposed solution with code if possible

​
References

  • Related issues or similar vulnerabilities
  • Audit reports or documentation

## Response Timeline

<Steps>
  <Step title="Acknowledgment: 48 hours">
    Initial receipt confirmation
  </Step>
  
  <Step title="Assessment: 7 days">
    Severity determination and validation
  </Step>
  
  <Step title="Fix Development: Variable">
    Depends on complexity (1-4 weeks typical)
  </Step>
  
  <Step title="Deployment: Variable">
    May require governance approval
  </Step>
  
  <Step title="Bounty Payment: Within 30 days">
    After fix is deployed and verified
  </Step>
</Steps>

## Safe Harbor

<Info>
  **Legal Protection**
  
  Security researchers who:
  - Report vulnerabilities responsibly
  - Follow the disclosure process
  - Do not exploit vulnerabilities for profit
  - Do not publicly disclose before patching
  
  ...will be protected from legal action by the Reserve team.
</Info>

## Responsible Disclosure Policy

<AccordionGroup>
  <Accordion title="Required Practices">
    ✅ Report privately to the team
    
    ✅ Allow reasonable time for patching
    
    ✅ Cooperate with the team on verification
    
    ✅ Coordinate public disclosure timing
  </Accordion>
  
  <Accordion title="Prohibited Actions">
    ❌ Public disclosure before fix
    
    ❌ Exploiting vulnerabilities for profit
    
    ❌ Testing on mainnet with real funds
    
    ❌ Attacking user accounts
    
    ❌ Degrading protocol availability
  </Accordion>
</AccordionGroup>

## Testing Guidelines

<Card title="Test on Local/Testnet Only" icon="flask">
  **Recommended:**
  - Local Foundry fork
  - Public testnets (Sepolia, Base Sepolia, etc.)
  - Private test deployments
  
  **Not Allowed:**
  - Mainnet testing with real funds
  - Testing that affects live users
  - DoS attacks on production systems
</Card>

## Previous Bounties

<Info>
  Information about past successful bounty claims may be shared publicly (with researcher permission) to demonstrate the program's effectiveness and reward quality contributions.
</Info>

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="What if my finding is a duplicate?">
    The first reporter of a unique vulnerability receives the bounty. Duplicate reports are not eligible.
    
    However, if your report provides significantly better analysis or a more severe variation, partial rewards may be considered.
  </Accordion>
  
  <Accordion title="Can I report issues found by AI tools?">
    Yes, but the same quality and validity standards apply. AI-generated reports without validation or understanding are not eligible.
  </Accordion>
  
  <Accordion title="Are gas optimizations eligible?">
    Generally no, unless:
    - They prevent a DoS attack
    - They fix an actual vulnerability
    - They have critical security implications
  </Accordion>
  
  <Accordion title="What about findings from previous audits?">
    Known issues from published audits are not eligible unless:
    - They were marked as acknowledged but not fixed
    - You discover a new variation or related issue
    - The fix was incomplete
  </Accordion>
  
  <Accordion title="How are bounties paid?">
    Payments are typically made in:
    - USDC or stablecoins
    - ETH
    - Other agreed-upon cryptocurrencies
    
    Payment method can be discussed during the reporting process.
  </Accordion>
</AccordionGroup>

## Contact Information

<Warning>
  **Do not use these channels for support questions or general inquiries.**
  
  Security reports only.
</Warning>

<Card title="Security Contact" icon="envelope">
  For vulnerability reports, contact the Reserve team through:
  - Official security channels (check Reserve Protocol website)
  - Encrypted communication if available
  - Immunefi platform (if program is listed)
  
  Include "SECURITY VULNERABILITY" in the subject line.
</Card>

## Related Documentation

<CardGroup cols={2}>
  <Card title="Security Audits" icon="shield-check" href="/resources/audits">
    Review previous security audits
  </Card>
  <Card title="Architecture" icon="sitemap" href="/essentials/architecture">
    Understand the protocol architecture
  </Card>
  <Card title="Smart Contracts" icon="file-contract" href="/api-reference/core/folio">
    Contract API documentation
  </Card>
  <Card title="Development" icon="code" href="/development">
    Set up a local testing environment
  </Card>
</CardGroup>

Build docs developers (and LLMs) love

Get started for freeTalk to us