# 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: I**ncludes 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hats.finance/for-projects/setting-up-a-bug-bounty.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.