> ## 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. # Bug Bounty Program > Report security vulnerabilities and earn rewards ## 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. 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 **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 **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 **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 **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 | Severity | Typical Reward Range | | ------------ | -------------------- | | **Critical** | $50,000 - $250,000+ | | **High** | $10,000 - $50,000 | | **Medium** | $2,000 - $10,000 | | **Low** | $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 Include: * Clear description of the vulnerability * Steps to reproduce * Proof of concept (code or test) * Potential impact assessment * Suggested fix (optional but appreciated) **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. The team will acknowledge receipt within 48 hours and provide an initial assessment within 7 days. Work with the team to: * Verify the vulnerability * Develop and test a fix * Coordinate disclosure timing After the fix is deployed: * Reward amount is determined * Payment is processed * Public acknowledgment (if desired) ## Report Quality Guidelines ### Excellent Reports Include Concise explanation of the vulnerability and its root cause Step-by-step instructions to reproduce the issue Working code demonstrating the vulnerability Assessment of potential damage and affected users Proposed solution or mitigation strategy Discussion of related edge cases or variations ### Example Report Structure ````markdown theme={null} # 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 Initial receipt confirmation Severity determination and validation Depends on complexity (1-4 weeks typical) May require governance approval After fix is deployed and verified ## Safe Harbor **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. ## Responsible Disclosure Policy ✅ Report privately to the team ✅ Allow reasonable time for patching ✅ Cooperate with the team on verification ✅ Coordinate public disclosure timing ❌ Public disclosure before fix ❌ Exploiting vulnerabilities for profit ❌ Testing on mainnet with real funds ❌ Attacking user accounts ❌ Degrading protocol availability ## Testing Guidelines **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 ## Previous Bounties Information about past successful bounty claims may be shared publicly (with researcher permission) to demonstrate the program's effectiveness and reward quality contributions. ## Frequently Asked Questions 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. Yes, but the same quality and validity standards apply. AI-generated reports without validation or understanding are not eligible. Generally no, unless: - They prevent a DoS attack - They fix an actual vulnerability - They have critical security implications 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 Payments are typically made in: - USDC or stablecoins - ETH - Other agreed-upon cryptocurrencies Payment method can be discussed during the reporting process. ## Contact Information **Do not use these channels for support questions or general inquiries.** Security reports only. 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. ## Related Documentation Review previous security audits Understand the protocol architecture Contract API documentation Set up a local testing environment ```