Setting Up a Bug Bounty

Welcome to Hats Finance's Bug Bounty Program. This guide is designed to assist protocols in setting up and managing a bug bounty with us, ensuring a structured and effective approach to securing smart contracts. For real-time step-by-step assistance, please refer to our detailed Hats Bug Bounty onboarding template.

Defining the Bug Bounty's Scope and Objectives

The first step in setting up a bug bounty is defining its scope and objectives. Determine what you hope to achieve: Is it a general security check, specific vulnerability assessments, or both? Pinpoint critical components of your smart contract that require special attention, such as high-value pools or unique governance mechanisms.

Documentation and Organization of Your Codebase

Code Documentation: Ensure your code is thoroughly documented. This includes clear comments and a comprehensive readme file explaining the overall architecture and functionalities.

Version Control: Maintain an organized version control system using platforms like GitHub.

Testing and Deployment Scripts: Provide testing scripts and deployment procedures to help researchers understand how your system operates. Configure continous integration - such as github actions - to that you are sure your tests all pass and are easily reproducible.

Accessibility and Understanding Access to Codebase: Ensure the codebase is accessible to researchers. Make private repositories available to the Hats team and bug bounty participants.

Clarify Dependencies: List and explain any external dependencies your contract has.

Disclose Known Vulnerabilities: It is important for researchers to not waste time describing vulnerabilities that your team is already aware of, so you should be as clear and complete as possible in this regard. If you have (for example) github issues describing such vulnerabilities, mention these in the description of your scope. If your code was audited before, provide such earlier audit reports

Disclosure of Past Incidents

If your protocol has experienced security incidents in the past, provide details. Understanding past vulnerabilities can guide researchers to focus on potential recurring issues.

Establishing Communication Channels

Dedicated Communication: Set up a channel for communication with researchers, like a Discord server or Telegram group.

Availability for Queries: Assign team members to respond to queries from researchers promptly.

Preparation for Post-Bounty Activities

Implementing Fixes: Have a strategy for addressing and implementing recommendations or fixes from the bounty.

Understanding Arbitration: Familiarize yourself with Hats Finance’s arbitration process for dispute resolution.

Launching Your Bug Bounty

Vault Setup: Define your vault committee, which should consist of security researchers, developers, and essential project personnel. Create a bounty vault using your project tokens. Earn Hats tokens through farming post-TGE (Token Generation Event).

Vault Rules & Guidelines: Define the in-scope code, severity types, total rewards, and competition duration. Customize severity descriptions and submission guidelines as needed. Share these decisions with the Hats team and use our Vault Editor to set up your vault.

Responsibilities of the Committee: The committee is responsible for monitoring and triaging audit reports, and communication with the submitter. These reports are encrypted, and can only be read by the committee (and not by HATs), so make sure you save the PGP keys that you need to read the messages.

Known Issues Document: Add this to your repository with a link in the vault description. Optional Documentation: Create documentation of the protocol and architecture, including diagrams.

Example of Severity Descriptions

Critical Severity: Includes economic attacks, cryptographic flaws. Prize capped based on the potential risk.

High Severity: Covers temporary inability to transfer tokens, transient consensus failures.

Medium Severity: Includes gas griefing, denial of service.

Low Severity: Non-critical functional issues with no fund risk.

Limitations: Reporters will not receive a bounty for known issues, vulnerabilities made public, “centralization risks”, or attacks requiring leaked private keys.

By preparing meticulously for your bug bounty with Hats Finance, you facilitate a smoother process and demonstrate your commitment to security. Start securing your protocol's future with Hats Finance today.