# HackenProof

HackenProof is a leading web3 bug bounty platform for exchanges, protocols, and smart contracts.\ We connect crypto projects with the global hacker community and professional smart contract auditors to uncover security issues. # Services we provide HackenProof web3 services ### Public & Private Bug Bounty Programs The public Bug Bounty program - also known as a vulnerability rewards program (VRP), offers rewards to individuals (security researchers, hackers) for uncovering and reporting software bugs. The public Bug Bounty program has unlimited time and budget and everyone on the platform can participate. This is a great solution for large and mature products. Private Bug Bounty programs. We help the client to hand-pick a limited number of proven researchers with skills and backgrounds that are a good match for their needs. The program is completely anonymous. This is a good solution before starting a public bug bounty program and is also used for pre-release and early products. ### Crowdsourced audits A crowdsourced audit is a time-limited competitive audit that is done by a HackenProof community. The crowdsourced audit has a predictable budget for valid findings and report validation (judging). The HackenProof community consists of independent security researchers, hackers, solo auditors, and traditional company auditors. ### Online Hackathons / Live Hacking Events A live event with a group of top hackers that work on testing your product together with your in-house team for 1-5 days. Great for bringing attention to your product, achieving quick results, and educating your security team. ### Triage services / Reports validation & mediation # Our resources ### Our resources: :bird:Twitter: :robot:Discord: :envelope:Telegram: :timer:LinkedIn: :arrow\_forward:YouTube: :mobile\_phone\_off:Instagram: :blue\_book:Facebook: :envelope\_with\_arrow:Feedback form: ### Official Verified accounts To protect yourself against scammers pretending to be HackenProof, check if the information you have received is really from HackenProof members. #### :timer:LinkedIn | Twitter | Telegram * Yuliia Sokoliuk -> [LinkedIn](https://www.linkedin.com/in/yulia-sokoliuk/) | [Twitter](https://x.com/YSokoliukHP) | [Telegram](https://t.me/Julia_HackenProof) * Eleonora Fedotova -> [LinkedIn](https://www.linkedin.com/in/eleonora-fd/) | [Twitter](https://x.com/El_HackenProof) | [Telegram](https://t.me/Eleonora_HackenProof) * Oleksandr Horlan -> [LinkedIn](https://www.linkedin.com/in/o-horlan/) | [Twitter](https://twitter.com/d0rsky) * Dmytro -> [LinkedIn](https://www.linkedin.com/in/dmytro-matviiv/) | [Twitter](https://twitter.com/DmytroMatviiv) * Anastasiia Matviiva -> [LinkedIn](https://www.linkedin.com/in/anastasiia-matviiva-288279165/) # Security is Core of HackenProof At HackenProof, security isn't just a feature — it's the foundation. We are committed to safeguarding our clients' data, researchers' identities, and the integrity of our platform through globally recognized standards and best practices. ### Security Standards We Follow * **ISO/IEC 27001 Certified**. We are officially certified under ISO/IEC 27001, the international standard for establishing, implementing, and maintaining an Information Security Management System (ISMS). * **ISO 29147** **– Vulnerability Disclosure**. We implement structured processes for receiving and managing vulnerability reports securely and transparently. * **ISO 30111 – Vulnerability Handling**. Our triage and remediation workflows follow best practices for assessing, verifying, and resolving vulnerabilities. * **ISO/IEC 27002 – Information Security Controls.** Our platform incorporates many of the recommended information security controls from ISO/IEC 27002. * **GDPR Compliance – General Data Protection Regulation.** We are fully compliant with the EU General Data Protection Regulation (GDPR). Our data protection framework ensures lawful processing, transparency, user consent management, data minimization, and robust protection of personal information across all our systems and operations.
### Security Features at HackenProof We integrate robust security mechanisms directly into the platform to protect user data and facilitate safe vulnerability coordination: * End-to-end encryption of reports * Two Factor Authentication (2FA) * Auth (Google/GitHub) * User Login History Tracking * Role -Based Access Control (RBAC) to programs ### Vulnerability Classification at HackenProof At HackenProof, we follow a structured and transparent **vulnerability classification framework** to ensure fair and consistent evaluation of all reported issues. This system helps both researchers and program owners clearly understand the severity and business impact of vulnerabilities. * Read the full guide**:** [Vulnerability Classification Documentation](/bug-bounty/vulnerability-classification) # Integrations # Slack Get notifications in Slack from HackenProof about new reports, report status, and report severity changes How the connection HackenProof -> Slack works This guide explains how our Slack bot can help companies when they run a bounty program at HackenProof. As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your Slack server, the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) * report status changes * report severity changes

Note! The Slack bot will not re-send messages when changes happen. The bot will change the previous message that is related to a specific report. ## Connect the HackenProof bot to your Slack space * Select a Bug Bounty Program that you want to integrate with your Slack workspace. * Go to the Integrations section and click on the Slack app:

* Click on '**Add to Slack'** button

* Select your preferred Slack channel, then click the **'Allow'** button:

* Now your bug bounty program is connected to your Slack space:

## Approve the HackneProof Slack bot (important). Note! If you are not a Slack space admin, you should ask someone from your team to approve the HackneProof Slack bot. To approve the HackenProof bot in your Slack space: * Click on your **workspace name** in the top-left corner.

* From the dropdown menu, select **"Settings & administration"** and then click on **"Manage apps"**. This will take you to the app management page.

* In the **'Manage apps'** section, you'll see a list of available apps and integrations. Find the **'HackenProof Notifications**' app and click on it.

* Navigate to the 'App Details' tab

* Click on 'Approve' button

## Connect the bot to the Private channel To add a HackenProof notification bot to your Slack private channel: * Navigate to the settings of the preferred private Slack channel.

* Choose the **'Integrations'** section.

* Click on **'Add app'** button.

* Find the **'HackenProof Notifications'** app and click on **'Add'** button.

## Good to know 1. If a company has a few programs, and you want to connect all of them to your Slack space, then you need to set up the integration for each program. 2. You can use different Slack channels for different programs. # Discord Get notifications in Discord from HackenProof about new reports, report status, and report severity changes ## How the connection HackenProof -> Discord works This guide explains how our discord bot can help companies when they run a bounty program at HackenProof. As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your Discord server, the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) * report status changes * report severity changes

Note! The discord bot will not re-send messages when changes happen. The bot will change the previous message that is related to a specific report. ### Good to know 1. If a company has a few programs, and you want to connect all of them to your discord server, then you need to set up the integration for each program. 2. You can use different discord channels for different programs. # Telegram Get notifications in Telegram from HackenProof about new reports, report status, and report severity changes ## How the connection HackenProof -> Telegram works This guide explains how our Telegram bot can help companies when they run a bounty program at HackenProof. Note! Telegram bot works only for the individual Telegram account, so if 5 people from your team want to get notifications in Telegram - all 5 people have to connect to the Telegram bot. As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your Telegram account, the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) * report status changes * report severity changes

Note! The Telegram bot will re-send a message when changes happen with the specific report. ### Good to know 1. Telegram bot works only for the individual Telegram account, so if 5 people from your team want to get notifications in Telegram - all 5 people have to connect to Telegram bot. 2. If you have a HackenProof account that is related to a few companies - you will get notifications from all those companies. # Zapier (Webhook) Get notifications in your favorite apps from HackenProof about reports through the Zapier Webhook This guide explains how to send notifications through [Zapier](https://zapier.com/) WebHook to the app supported by Zapier ## How the connection HackenProof -> Zapier Webhook works This guide explains how our Zapier WebHook can help companies when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your Zapier account, the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) In this version, we don't send information about changes in reports like Report Status or Report Severity ### Step 1. Generate your ZapierHook URL * Navigate to the Zapier dashboard * Create a new Zap

* Choose Trigger: Webhooks by Zapier

* Choose the Event type: Catch Hook

* Press the Continue button:

* Pick off a Child Key and press Continue. Here you can name it as you wish.

* Copy the ZapierHook URL:

### Step 2. Add the copied ZapierHook URL to HackenProof: * Navigate to your Program integration section and choose Zapier:

* Paste your copied ZapierHook URL and press Connect button

* Press Test Webhook:

* Press the **Test WebHook** button to test the connection (it will send the latest report' data to Zapier) * Also back to Zapier Zap and press the Test Trigger button:

* As a result, you will see a data record. Press **Continue with selected record.**

### Step 3. Connect your App * You can check our ready guides or try to add your apps

# Zapier -> Lark Get notifications in Lark from HackenProof about new reports How the connection HackenProof -> Zapier Webhook works This guide explains how our[ Zapier](https://zapier.com/) WebHook can help companies with notifications when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has[ different stages of reports](https://docs.hackenproof.com/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your[ Zapier account](https://zapier.com/), the Zapier will send notifications about the new reports (that include the Program name, Report title, Report severity, Report URL etc.) ### Step 1. Generate your Zapier Webhook URL * Navigate to your Zapier dashboard. * Create a new Zap.

* Choose Trigger: Webhooks by Zapier.

* Choose the Event type: **Catch Hook.**

* Click the '**Continue'** button.

* Pick off a Child Key and press the '**Continue'** button. **You can name Child Key as you wish.**

* Copy the Zapier Webhook URL.

### Step 2. Add the copied Zapier Webhook URL to HackenProof * Navigate to your Program Integrations section and choose Zapier.

* Paste your copied Zapier Webhook URL and **press the Connect button.**

* Press the **Test WebHook** button to test the connection (it will send the latest report data to Zapier).

* Back to your Zapier and click the '**Test Trigger'** button.

* As a result, you will see a data record. Click the '**Continue with the selected record'** button**.**

### Step 3. Connect your Lark Suite * In this guide, we are going to use [Lark Suite](https://www.larksuite.com/). Before starting working with Lark, you need to connect your Lark account in the Zapier App: Navigate to your Zapier Account and make sure you have the necessary connected app.

* Now navigate to your ZAP to continue creating it: choose Action.

* Find and add Lark.

* Chose the event type **Create New Lark Task (or other event).**

* Click the **'Continue'** button.

* **Action**. Now specify, please, data about your Lark project (the data in the screenshot is just an example). * In the Summary and Description fields, you can add pre-description as shown on the screenshot: * Report Title * Program name: * Report ID: * Report URL: * Report Severity: * Report Status: * Report Target Type

* Specify data in other required and optional fields, and click the '**Continue'** button. * Now you can Test the Zap.

* If everything works for you, Publish the ZAP.

* Check your Lark project.

* If you open any issue ticket you can see the requested data.

# Zapier -> Linear Get notifications in Linear from HackenProof about new reports, report status, and report severity changes ### How the connection HackenProof -> Zapier Webhook works This guide explains how our [Zapier](https://zapier.com/) WebHook can help companies with notifications when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your [Zapier account](https://zapier.com/), the Zapier will send notifications about the following: * **New reports** (that include the Program name, Report title, Report severity, Report URL etc.) ### Step 1. Generate your ZapierHook URL * Navigate to your Zapier dashboard * Create a new Zap

* Choose Trigger: Webhooks by Zapier

* Choose the Event type: **Catch Hook**

* Press the **Continue** button:

* Pick off a Child Key and press the **Continue** button. **You can name Child Key as you wish**.

* Copy the ZapierHook URL:

### Step 2. Add the copied ZapierHook URL to HackenProof: * Navigate to your Program integration section and choose Zapier: * Paste your copied ZapierHook URL and **press the Connect button.**

* Press the **Test WebHook** button to test the connection (it will send the latest report' data to Zapier)

* Back to your Zapier and press Test Trigger:

* As a result, you will see a data record. Press **Continue with the selected record.**

### Step 3. Connect your Linear App * In this guide, we are going to use [Linear App](https://linear.app/). Before starting working with Linear, you need to connect your Linear account in the Zapier App: Navigate to your Zapier Account and make sure you have the necessary connected app

* Now navigate to your ZAP to continue creating it:

* Find and add Linear App.

* Chose the event type **Create Task (or other event)** and press the **Continue** button

* **Action**. Now specify, please, data about your Linear project (the data in the screenshot is just an example). * In the Title and Description fields, you can add pre-description as shown on the screenshot: * Report Title * Program name: * Report ID: * Report URL: * Report Severity: * Report Status: * Report Target Type

* Specify data in other required and optional fields, and press the **Continue** button. * Now you can Test the Zap:

* If everything works for you, Publish the ZAP

* Check your Linear project:

* If you open any issue ticket you can see the requested data:

# Zapier -> Jira Service Management Get notifications in Jira Service Management from HackenProof about new reports, report status, and report severity changes ## How the connection HackenProof -> Zapier Webhook works This guide explains how our Zapier WebHook can help companies when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your Zapier account, the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) ### Step 1. Generate your ZapierHook URL * Navigate to the Zapier dashboard * Create a new Zap

* Choose Trigger: Webhooks by Zapier

* Choose the Event type: Catch Hook

* Press the Continue button:

* Pick off a Child Key and press Continue. Here you can name it as you wish.

* Copy the ZapierHook URL:

### Step 2. Add the copied ZapierHook URL to HackenProof: * Navigate to your Program integration section and choose Zapier:

* Paste your copied ZapierHook URL and press Connect button

### Step 3. Connect your Jira Service Management App * in this sample, we will use Jira Service Management * So now you need to find your App

* in this sample, we will use Jira Service Management

* chose event type Create Request and press the Continue button

* Now specify data about your Jira project in the Site and Projects fields (data in the screenshots is just an example). Project name - is your Jira project where you want to send reports * Choose Request Type, for example, GET IT Help

* Specify Summary: you can use Report Title as a summary * And add a Description that can include a few fields at the same time. Also, you can add some pre-description for each field to understand it in Jira later: * Program name: * Report ID: * Report URL: * Report Severity: * Report Status: * Now, test your action and make your Zap published

* Check your Jira Service Management project for test ticket:

* here is how the report looks like inside:

# Zapier -> PagerDuty Get notifications in PagerDuty from HackenProof about new reports, report status, and report severity changes This guide explains how to send notifications through [Zapier](https://zapier.com/) WebHook to the PagerDuty app ## How the connection HackenProof -> Zapier Webhook works This guide explains how our Zapier WebHook can help companies when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your Zapier account, the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) In this version, we don't send information about changes in reports like Report Status or Report Severity ### Step 1. Generate your ZapierHook URL * Navigate to the Zapier dashboard * Create a new Zap

* Choose Trigger: Webhooks by Zapier

* Choose the Event type: Catch Hook

* Press the Continue button:

* Pick off a Child Key and press Continue. Here you can name it as you wish.

* Copy the ZapierHook URL:

### Step 2. Add the copied ZapierHook URL to HackenProof: * Navigate to your Program integration section and choose Zapier:

* Paste your copied ZapierHook URL and press Connect button

* Press Test Webhook:

### Step 3. Connect your PagerDuty app to send notifications about incoming HackenProof reports * So now you need to find your App

* Now, you need to find and connect Zapier to your PagerDuty space

* Choose your PagerDuty account and event type: Add Trigger Event. Then press the Continue button

* Specify your PagerDuty Integration Key (Note! you can add it as a custom field): * Integration Key can be found in the *PagerDuty space: Service -> Service Directory -> Navigate to your Service space -> Integration tab* * Open the settings of the created Zapier integration and copy the Integration Key ![](https://downloads.intercomcdn.com/i/o/752622418/39077dd3c4439970b958b6c8/image.png) * If you don't have Zapier integration yet, then press the Add an integration:

* find Zapier App and press the Add button:

* Add Description. Here you can all the necessary information that ZapierHook offers you, for example: * Program name: * Report ID: * Report URL: * Report Severity: * Report Status: * Specify Incident Key. You can use Report ID as Incident Key. Specify your PagerDuty Integration Key as a custom field!

* Add optional fields if it's required by your team and press the continue button:

* Now you can test your connection and publish the Zap

* Here is how the result looks like in our demo space:

# Zapier -> Google Chat Get notifications in Google Chat from HackenProof about new reports, report status, and report severity changes ### How the connection HackenProof -> Zapier Webhook works This guide explains how our [Zapier](https://zapier.com/) WebHook can help companies when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your [Zapier account](https://zapier.com/), the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) ### Step 1. Generate your ZapierHook URL * Navigate to the Zapier dashboard * Create a new Zap

* Choose Trigger: Webhooks by Zapier

* Choose the Event type: **Catch Hook**

* Press the **Continue** button:

* Pick off a Child Key and press Continue. **Here you can name it as you wish**.

* Copy the ZapierHook URL:

### Step 2. Add the copied ZapierHook URL to HackenProof: * Navigate to your Program integration section and choose Zapier:

* Paste your copied ZapierHook URL and **press the Connect button.**

* Press the **Test WebHook** button to test the connection (it will send the latest report' data to Zapier) * Back to Zapier and press Test Trigger:

* As a result, you will see a data record. Press **Continue with selected record.**

### Step 3. Connect your Google Chat App * in this sample, we use Google Chat. Before starting working with Google Chat, you need to: * Connect your Google Chat account in the Zapier App: Navigate to your Zapier Account and make sure you have the necessary connected app

* Set up Zapier Bot in the Google Chat space:

* Choose the Hangouts Chat Room where you want the Message to be shown. The Zapier Bot must be added to the room and be configured with the "allowzaps" command.

* Now navigate to your Zapier account to continue creating ZAP:

* find and add Google Chat

* chose event type **Create Message** and press the Continue button

* Now specify data about your Google Chat (data in the screenshot is just an example). You can add a Description that can include a few fields at the same time. Also, you can add some pre-description for each field to understand it in later: * Program name: * Report ID: * Report URL: * Report Severity: * Report Status:

* Now you can Test it.

* if everything works for you, Publish it

* Check your Google Chat space:

# Zapier -> ClickUp Get notifications in ClickUp app from HackenProof about new reports, report status, and report severity changes ### How the connection HackenProof -> Zapier Webhook works This guide explains how our [Zapier](https://zapier.com/) WebHook can help companies when they run a bounty program at HackenProof. Please note! It's Zapier Webhook integration, not Zappier App As you know, HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. Once you connect your bug bounty program to your [Zapier account](https://zapier.com/), the bot will send notifications about the following: * new reports (that includes the Program name, Report title, Report severity, and Report URL) ### Step 1. Generate your ZapierHook URL * Navigate to the Zapier dashboard * Create a new Zap

* Choose Trigger: Webhooks by Zapier

* Choose the Event type: **Catch Hook**

* Press the **Continue** button:

* Pick off a Child Key and press Continue. **Here you can name it as you wish**.

* Copy the ZapierHook URL:

### Step 2. Add the copied ZapierHook URL to HackenProof: * Navigate to your Program integration section and choose Zapier:

* Paste your copied ZapierHook URL and **press the Connect button.**

* Press the **Test WebHook** button to test the connection (it will send the latest report' data to Zapier) * Back to Zapier and press Test Trigger:

* As a result, you will see a data record. Press **Continue with selected record.**

### Step 3. Connect your ClickUp App * in this sample, we use [ClickUp App](https://app.clickup.com/). Before starting working with ClickUp, you need to: * Connect your ClickUp account in the Zapier App: Navigate to your Zapier Account and make sure you have the necessary connected app

* Now navigate to your Zapier account to continue creating ZAP:

* find and add ClickUp App

* chose event type **Create Task (or other event)** and press the Continue button

* Now specify data about your ClickUp project (the data in the screenshot is just an example). You can add a Description that can include a few fields at the same time. Also, you can add some pre-description for each field to understand it in later: * Program name: * Report ID: * Report URL: * Report Severity: * Report Status:

* Now you can Test it.

* if everything works for you, Publish the ZAP * Check your ClickUp project:

# Jira Software Automatically create tickets in your Jira Software for reports from HackenProof with the status Triaged ## How works the connection HackenProof -> Jira HackenProof uses a ticket-based system that has [different stages of reports](/bug-bounty/reports-basics) processing. And when the report is considered valid, it proceeds to the TRIAGED stage. We believe the company may need to connect its HackenProof bounty program to its Jira to work on valid reports to fix them. * Once you connect your bounty program to Jira, it will create a Jira project with the same name as your HackenProof bug bounty program. * Then, all reports that are marked as TRIAGED will appear in your Jira project. Note #1. Only reports with state TRIAGE will appear in the Jira

## How to manage reports in Jira The report/ticket management process and the type of boards you intend to use in Jira depend on your team. For example, it can be a Kanban board with the following flow:

## After you fix the reports Please remember, after developers fix the report, it must be manually marked as RESOLVED in your HackenProof program.

# GitHub Issue Automatically create GitHub issue from HackenProof for reports with any status ## How the connection HackenProof -> GitHub issue works This guide explains how GitHub connection helps companies when they run a bounty program at HackenProof. Once you connect your bug bounty program to your GitHub repository (public or private), you can automatically create a GitHub issue: remember, you can create a GitHub issue for reports with any STATUS ### How to create a GitHub issue * Open the report you want to create a GitHub issue from * Navigate to the prerequisites section of the report and find the GitHub issue section

* Press the Create GitHub issue button. As a result, the appropriate issue will be created in your GitHub repository * Also, in the report's GitHub section, you will find the link to the newly created issue:

### How to connect the GitHub repository to the HackenProof program * Open your HackenProof program which you want to connect to HackenProof * Navigate to the Integrations tab and open GitHub app

* Connect your HackenProof program to GitHub by specifying Repository URL and your GitHub API token

**Repository URL.** Be sure you use the correct Repository URL. Here is a correct sample: , where: * ** * *hackenproof/* - company (owner) * *web3-bug-bounty-platform/issues* - repo issue **GitHub API token.** To create your token: GitHub Settings -> Developer settings -> Personal access tokens

* Press the Generate personal access token

* To create a GitHub issue you will need a token with access to REPO

Make sure to copy your personal access token now. You won’t be able to see it again! Once you specified Repository URL and your GitHub API token you can connect your bug bounty program with GitHub and start creating GitHub issues # GitLab Issue Automatically create GitLab issue from HackenProof for reports with any status ## How the connection HackenProof -> GitLab issue works This guide explains how GitLab connection helps companies when they run a bounty program at HackenProof. Once you connect your bug bounty program to your GitLab repository (public or private), you can automatically create a GitLab issue: remember, you can create a GitLab issue for reports with any STATUS ### How to create a GitLab issue * Open the report you want to create a GitLab issue from * Navigate to the prerequisites section of the report and find the GitLab issue section

* Press the Create GitLab issue button. As a result, the appropriate issue will be created in your GitLab repository. * Also, in the report's GitLab section, you will find the link to the newly created issue:

### How to connect the GitLab repository to the HackenProof program * Open your HackenProof program, which you want to connect to HackenProof * Navigate to the Integrations tab and open GitLab app

* Connect your HackenProof program to GitLab by specifying the Repository URL and your GitLab API token.

**Repository URL.** Be sure you use the correct Project ID (not name). Here is a correct sample: , where: * - core of our integration * 19980000 - project ID (not a name) * *issues* - repo issue page **GitLab API token.** To create your token: GitLab Project Settings -> Access Tokens

* Generate personal access token. Make sure to copy your personal access token now. You won’t be able to see it again! Once you specified Project URL and your GitLab token you can connect your bug bounty program with GitLab and start creating GitLab issues # VDP iFrame Vulnerability Disclosure Page (VDP) for your website VDP - is the limited iFrame of your bounty program that can be placed on your website as a Vulnerability Report form (page). Read more [here](https://hackenproof.com/blog/for-business/how-to-create-vdp-for-crypto-business) on how to set up and activate VDP. Also, here is an example of the iFrame of HackenProof's bug bounty program: # FAQ # Audit & Bug Bounty (BB) Bug Bounty program - also known as a vulnerability rewards program (VRP), offers rewards to individuals (security researchers, hackers) for uncovering and reporting software bugs. The public Bug Bounty program **has unlimited time and budget and everyone** on the platform can participate. Bug bounty can be done for both closed and open-source code. Audit - is a service that will be done by a specific company auditor for a **limited time and money and by limited specialists**. Auditing can be done for both closed and open-source code. | Option | Bug Bounty | Audit by company | | ------------------------------------------------------------------ | --------------------------------- | ---------------------------------- | | Limited time | usually no | yes | | Limited budget | usually no | yes | | Everyone can submit vulnaribility report | yes (and no for private programs) | no | | Program owner (client) can pay in native token, stable coins, fiat | yes | no (usually stable coins and fiat) | | Only specific company can participate | no | yes | | Can be done for both closed and open-source code | yes | yes | # Crowdsourced Audit & BB Bug Bounty program - also known as a vulnerability rewards program (VRP), offers rewards to individuals (security researchers, hackers) for uncovering and reporting software bugs. The public Bug Bounty program **has unlimited time and budget, and everyone** on the platform can participate. Crowdsourced Audit - this is a **time-limited** service that will be done by a HackenProof **community**. The crowdsourced audit has a **predictable budget** for valid findings and report validation (judging). | Option | Bug Bounty | Crowdsourced Audit | | ------------------------------------------------------------------ | --------------------------------- | ------------------ | | Limited time | usually no | yes | | Limited budget | usually no | yes | | Everyone can submit vulnaribility report | yes (and no for private programs) | yes | | Program owner (client) can pay in native token, stable coins, fiat | yes | yes | | Only specific company can participate | no | no | | Can be done for both closed and open-source code | yes | no | # Penetration testing & BB A penetration test (pen test) is an authorized simulated attack performed on a computer system to evaluate its security. Penetration testers use the same tools, techniques, and processes as attackers to find and demonstrate the business impacts of weaknesses in a system or applications. A pen test is a service that will be done by a specific company for a **limited time and money and by limited specialists**. Pen tests can be done **only for closed code**. Bug Bounty program - also known as a vulnerability rewards program (VRP), offers rewards to individuals (security researchers, hackers) for uncovering and reporting software bugs. The public Bug Bounty program **has unlimited time and budget and everyone** on the platform can participate. Bug bounty can be done **for both** closed and open-source code. | Option | Bug Bounty | Penetration testing | | ------------------------------------------------------------------ | --------------------------------- | ---------------------------------- | | Limited time | usually no | yes | | Limited budget | usually no | yes | | Everyone can submit vulnaribility report | yes (and no for private programs) | | | Program owner (client) can pay in native token, stable coins, fiat | yes | no (usually stable coins and fiat) | | Only specific company can participate | no | yes | | Can be done for both closed and open-source code | yes | no (only closed code) | # Emergency # Reset 2FA How to regain access to your HackenProof account This article helps you to regain access to your [HackenProof](https://dashboard.hackenproof.com/login) account in case you set up the Two-factor authentication (also known as 2FA) and lost access to your Google Authenticator. First of all, please check the [2FA Google guide](https://support.google.com/accounts/answer/185834?hl=en\&ref_topic=2954345) to be sure you've done everything to fix the common issues with 2-Step Verification. If you checked it and still have the same issue then you can ask the HackenProof team to delete the 2FA from your HackenProof account. To delete the 2FA from your HackenProof account: * navigate to your email account that is used for HackenProof authentication; * send a 2FA reset request from your email account to: by specifying the deletion reason. \_ \_ \_ \_ \_ \_ \_ *Note! 2FA deletion* requests are processed at different times of the day, and the expected response time is no more than 48 hours.
# Code of Conduct By partaking in activities on the HackenProof platform, all whitehat hackers pledge to adhere to the HackenProof Code of Conduct (CoC).\ \ This CoC is supplementary to the Terms and Conditions that all hackers must consent to when setting up an account. This Code provides the principles of engagement on the platform and outlines the potential disciplinary measures for any breaches.
### Inappropriate Conduct Interactions on the platform should always maintain a standard of professionalism and respect. Please avoid: * Inundating report threads or sending unnecessary support requests * Leaving derogatory comments * Acting unprofessionally at Live Hacking Events or other real-life instances where you represent HackenProof * Threatening disclosure, especially related to private programs Such conduct hampers the efficiency of the process and does not benefit you as the hacker or the program.\ ### Disruptive Testing and Service Deterioration Hackers must not engage in testing practices that could endanger the platform or services without prior permission. This includes excessive exploitation of vulnerabilities, unauthorized access or usage of accounts or production details not sanctioned per the program's policy, modifying production or database data, causing a Denial of Service, or in any way negatively impacting customer systems. ### Exposure of Private Programs Without Permission Revealing any aspect of a private program on the HackenProof platform is prohibited. This includes disclosing the program name, scope, vulnerability details, bounty structure, account details, or any other information that could identify the program. Such exposure may lead to disciplinary actions. ### Unstructured Vulnerability Disclosure - Public Programs For public programs, hackers should adhere to responsible disclosure guidelines. This involves awaiting the development and release of a patch before publicly disclosing vulnerabilities. ### Unofficial Communication With the Program Team Hackers should only use the authorized communication channels to discuss vulnerabilities submitted to HackenProof. Contacting security teams outside the official channels about submitted reports is a breach of this CoC. HackenProof is the official communication channel unless otherwise stated in the program policy. ### Reputation Manipulation and Duplicate Account Misuse Multiple accounts are not permitted to evade penalties or to gain an unfair advantage on the platform. Similarly, activities that unfairly boost reputation are prohibited. This includes sharing account access, submitting other hackers' work, and improper requests for changes in closure status to maintain reputation. ### Misappropriation of Intellectual Property The unauthorized use of another's intellectual property, including the work of other hackers, is strictly forbidden. ### Manipulative Tactics Attempting to manipulate another party through pretense of a HackenProof employee, another hacker, a program member, or a security team without authorization is prohibited. ### Coercion and Threats Any attempt to extract bounties, money, or services through coercion or threats is prohibited. Cases of extortion or blackmail may be escalated depending on their severity and may be considered criminal offenses. Adherence to this Code of Conduct ensures a secure, ethical, and productive community for all. Let's work together to maintain these standards. # Referral Program HackenProof's Referral Program. Refer Projects to HackenProof & Get Rewarded ### Help Secure Web3 & Get Rewarded This guide walks you through the referral process and the rewards you can expect. Know a project that could benefit from HackenProof’s cutting-edge security solutions? Refer them to us and earn exclusive rewards! Whether you're a cybersecurity enthusiast, an ethical hacker, or simply passionate about blockchain security, your referrals help strengthen Web3 safety — and you get rewarded for it. ### **Why Refer to HackenProof?** HackenProof is the go-to platform for bug bounties and crowdsourced security audits, trusted by top Web3 projects. By referring a project, you contribute to: * Strengthening blockchain security * Connecting projects with top-tier ethical hackers * Driving adoption of industry-leading security solutions And of course, you get rewarded for your efforts! ### **How It Works** Referring a project is simple and rewarding. Follow these three steps: 1. **Submit a Referral** – [Contact us](https://hackenproof.com/contacts) with your details and the project’s information. 2. **We Connect with the Project** – Our team reaches out to introduce HackenProof’s security services. 3. **Earn Your Reward** – Once the project launches its security program, you receive your referral bonus. ### **Rewards Structure** Earn generous rewards when a referred project launches its first security initiative on HackenProof: * **Public Bug Bounty Program:** Get 20% of monthly subscription fees, with no limits. * **Crowdsourced /** **Curated Security Audit and Penetration Testing** **:** Earn 10% of the audit fee, with no limits. Rewards are processed after the project successfully launches its security engagement. # Bug Bounty process ### How it works * You will need to register your account (or the HackenProof team will register), and draft the program rules & rewards, and specify targets for hackers (or our team will lead this process as well) * As soon as everything is agreed with the HackenProof team, the program comes alive. Then HackenProof will make social media announcements and another process around the promotion * Researchers will start submitting vulnerability reports * As soon as you get the report you need to review (or the HackenProof team) it due to the specified program SLA * If the reviewed report is valid you will pay through the HackenProof platform to the researcher ### Before the Bug Bounty * Welcome to [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to get answers to the questions you might have ### During the Bug Bounty * Please **don't break the rules**. If you don't follow Program SLA we will delist you from the HackenProof platform * The final decision on the severity level and a bounty is always on the client, but please **don't try to downgrade** the hacker reward or hide the real severity of the report. If you don't follow the rules we will delist you from the HackenProof platform * If you triage reports by yourself we may still ask you to allow us to review some reports if researchers have notified us of a reduced reward or severity * Please avoid discussing any issues submitted by researchers in an open channel ### After the Bug Bounty * In case you decide to stop running the program for an unpredictable time, you can ask our team to delete your account or just freeze it for an unlimited time (we store your data in accordance with our official policy). # How to start Bug Bounty Steps are required to start working with HackenProof Thanks for choosing HackenProof as your platform for getting vulnerability reports! Our ethical hackers' community will help you to avoid hacks. ### Good to know You can run bug bounty with any range of bounty, but the larger the range of bounty the higher the chance that a hacker will be motivated to participate in your program but not exploit the issue. What do we need from you to run a bug bounty? Program policy that will include: Scope-targets, a Range of bounties, Rules, and a signed agreement & NDA (we will help you with all these things) ### Quick start If you want to skip all steps below welcome to [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to get everything as soon as possible (we're available 24/7 for you) ### Steps to start a bug bounty Here are the steps that need to do to start working with HackenProof: * **Create an account** [**here**](https://dashboard.hackenproof.com/register?sign_up=company). Please use your company domain to register a company account * **Verify your email.** Follow the steps in the email to confirm your email address. * **Create a new program or edit available templates**. You can customize templates and specify your targets, range of bounty, logos, and rules. Here is how to create a well-readable bug bounty program * **Send your program for review by HackenProof.** As soon as you finish your program editing you need to press the PUBLISH button.

press the PUBLISH button to send the program to review

#### 2. When logged in, create a new program:

#### 3. Inside the program page, fill in the details from your VDP page and set the bounty rewards:

#### 4. Tick the VPD checkbox:

#### 5. Click “publish” to send the bounty to the review team

#### 6. Go to Integration section in profile settings:

#### 7. Click on Program’s VPD iFrame to copy and send this info to your developers:

# Vulnerability classification # Web & Mobile This is a vulnerability classification table for web & mobile applications (v2.0) We use the [Common Vulnerability Scoring System](https://www.first.org/cvss/user-guide) to assess the severity of reported vulnerabilities. Below is a classification of accepted issues and their typical severity ratings. | **Severity** | **Example Vulnerabilities** | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🔴 **Critical** |

Payments manipulation
SQL Injection (SQLi)
Remote Code Execution (RCE)
Business logic flaws causing loss of user funds or assets
Command Injection

| | 🟠 **High** |

Subdomain takeover (on domains linked to wallets or sensitive assets)
Stored Cross-Site Scripting (XSS)
Server-Side Request Forgery (SSRF)
Leakage of sensitive user information affecting >15% of users
File Inclusion vulnerabilities
Authentication Bypass: Full or partial bypass of login, session management, or auth tokens.
Insecure Direct Object Reference (IDOR): Accessing unauthorized user data/resources.
Privilege Escalation (Medium–High): User accessing or performing admin-only functions.

| | 🟡 **Medium** |

Reflected Cross-Site Scripting (XSS)
Subdomain takeover (non-wallet domains)
Two-Factor Authentication (2FA) Bypass
Leakage of sensitive user information affecting 3%–15% of users
Cross-Site Request Forgery (CSRF)
Misconfigured exported Android components (e.g., unvalidated deeplinks, WebView loading attacker-controlled URLs leading to session token leakage)

| | 🟢 **Low** |

HTML Injection
Subdomain takeovers without business impact (e.g., over a third-party service without access to cookies, auth, or internal APIs).
No rate limiting on form submissions or public endpoints
Content Spoofing
Broken Link Hijacking

| Please review the [Out-of-Scope Vulnerabilities](/bug-bounty/vulnerability-classification/web-and-mobile/out-of-scope-bugs) before submitting. # Out-of-Scope Bugs **Out-of-scope bugs** are issues that a security program **explicitly does not accept for triage, reward, or remediation**. These bugs are **excluded** either because they pose negligible risk, are too common or theoretical, or fall outside the domain of the responsible team. #### ✅ **General Criteria for Out-of-Scope Bugs** 1. **Low/No Security Impact**\ Bugs that do not meaningfully impact confidentiality, integrity, or availability. 2. **Lack of Practical Exploitability**\ Theoretical vulnerabilities that cannot be reasonably exploited in real-world scenarios. 3. **Non-production or third-party systems**\ Issues affecting non-production environments or systems not owned/controlled by the program owner. ### 🖥️ **Out-of-Scope — Web Applications** | Category | Examples (Typically Out-of-Scope) | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Best practices / Informational** | Missing `HttpOnly` or `Secure` flags (unless leading to a practical exploit), missing SPF/DKIM/DMARC without impact | | **Rate limiting / Bruteforce** | Lack of rate limiting on non-sensitive actions like search fields | | **Clickjacking / Tapjacking** | On pages with no sensitive functionality | | **Open Redirects** | Without demonstrable impact like token theft or phishing | | **CSRF** | On non-sensitive or unauthenticated endpoints, logout CSRF | | **Version disclosure** | Stack banners, server headers, or error messages showing version | | **404s / Debug Pages** | Missing or overly verbose error pages without sensitive data | | **Mixed content** | HTTP resources on HTTPS pages that don’t affect security (e.g., images) | | **Autocomplete enabled** | Unless leading to sensitive data leakage | | **Clickjacking on logout pages** | Considered low-risk unless session fixation/forgery is proven | | **Broken links** | On marketing, documentation, or blog pages | | **Image metadata** | Issues related to image metadata, such as EXIF data leakage or filename disclosure, are typically considered out of scope in bug bounty programs unless they expose sensitive user information or pose a clear security risk. | | **Pre-account takeover** | A pre-account takeover occurs when an attacker registers or gains access to an account *before* the legitimate user does, often by exploiting predictable sign-up flows or reused credentials. | | **Host Header Injection** | Without PoC demonstrating security impact | | **Man-in-the-Middle (MitM) Attacks** | Reports requiring attacker control over network (e.g., open Wi-Fi) without impact via compromised channel | | **Third-Party Assets / Out of Scope Domains** | Vulnerabilities in assets not owned by the company | | **Theoretical / Scanner Reports** | Auto-generated issues, theoretical bugs without practical impact | | **DoS / Resource Exhaustion** | Denial of Service or rate abuse without authentication bypass or security impact | | **Content/Text Injection** | Without control over HTML/CSS or attack vector | | **Content Spoofing** | Without embedded HTML or phishing vector | | **Certificate / TLS / SSL Issues** | Unless leading to data interception or tampering | | **Public Login Panels** | Without proof of vulnerability or impact | | **Software Outdated** | Reports about outdated software/libraries without working exploit | | **Session Fixation** | Session fixation without a demonstrated impact such as privilege escalation or account takeover | |

0day/1day vulnerabilities

Recently (less than 30 days) disclosed vulnerabilities

| | **CORS issues** | CORS misconfigurations without practical proof of concept demonstrating successful extraction of credentials or sensitive data from an attacker-controlled domain | | **Locally-hosted PoC** | Proofs of concept built as a local HTML/JS page that only issues requests to the application or extension and displays the response locally. These do not demonstrate that data is actually accessible or exchangeable over a normal network connection by a real attacker. Where the finding involves a dApp or wallet interaction, the PoC must be hosted and reproduced over the network from a remote origin the researcher controls. | *** ### 📱 **Out-of-Scope — Mobile Applications** | Category | Examples (Typically Out-of-Scope) | | -------------------------------------- | ------------------------------------------------------------------------------ | | **Root/Jailbreak Detection Bypass** | If the app doesn't promise root/jailbreak protection explicitly | | **Debug Logs / Stack Traces** | Unless they expose sensitive data like credentials or tokens | | **Insecure storage** | Low-risk data stored insecurely (e.g., cache files) with no PII or auth tokens | | **Obfuscation / Reverse Engineering** | Lack of obfuscation or repackaging protections | | **Code decompilation** | Reporting the fact that the app can be decompiled | | **Permissions declared but unused** | Common in many Android apps and not a security issue | | **Clipboard access** | Unless sensitive data is copied to the clipboard | | **End of Life platforms** | The platform/version is no longer supported. | | **Rate Limit Bypass via IP/Device ID** | Changing IP/device ID to bypass rate limits with no further impact | | **MitM/Local Attacks** | Without clear proof of data manipulation or impact | # Smart contracts This is a vulnerability classification table for smart contracts (v2.0) This table outlines how we categorize smart contract vulnerabilities by severity. Classifications are based on financial loss, disruption of core functionality, or manipulation of contract outcomes in live systems. | **Severity** | **Example Vulnerabilities** | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🔴 **Critical** |

- Direct theft of funds or NFTs
- Permanent freezing of funds or NFTs
- Governance result manipulation (e.g., vote hijacking, quorum bypass)
- Protocol insolvency (e.g., under-collateralization, unbacked tokens, critical mispricing)
- Unauthorized Minting / Burning of Tokens: If not covered, include direct manipulation of token supply.

| | 🟠 **High** |

- Temporary freezing of funds or NFTs
- Theft of unclaimed funds (e.g., yield, royalties)
- Permanent freezing of unclaimed funds
- Oracle Manipulation (High): Influencing on-chain price feeds or data sources.

| | 🟡 **Medium** |

- Theft of gas (unbounded loops, expensive operations exploitable by attackers)
- Gas limit / Out-of-Gas vulnerabilities
- Poor gas handling leading to transaction failure, loss of funds, or halted functionality
- Denial of Service (DoS)
- Gas exhaustion, block stuffing, or malicious state manipulation that disrupts contract availability
- No-profit attacks (Griefing)
- Attacks that damage the protocol or users without financial gain for the attacker

| | 🟢 **Low** |

- Failure to deliver promised returns
(e.g., staking pool advertises fixed APY but underperforms due to bugs or flawed logic)
- Uninitialized Storage Variables: Can lead to privilege escalation but often low-risk.

| If the issue is not under one of the mentioned vulnerabilities, we use the [Common Vulnerability Scoring System](https://www.first.org/cvss/user-guide) to assess the severity of your vulnerability. **Disclaimer:** Any **privileged** actions may be considered grounds for a severity downgrade or vulnerability disqualification. # Blockchain protocols This is a vulnerability classification table for blockchain protocols (v2.0) This classification applies to vulnerabilities that affect the core blockchain protocol or node-level consensus/security. | **Severity** | **Example Vulnerabilities** | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🔴 **Critical** |

- Direct theft of funds (e.g., ledger corruption, consensus manipulation)
- Permanent freezing of funds (irrecoverable protocol-level lock)
- Total network shutdown
- Network unable to confirm transactions
- Resolution requires a hard fork
- Consensus Manipulation or Fork Creation: Beyond shutdown, include the risk of chain split or invalid blocks.

| | 🟠 **High** |

- Application-level Denial of Service (DoS)
- Causes any node to crash under specific payloads or conditions
- Attack can be mitigated via firewall rules
- Temporary freezing of network transactions
- Temporary freezing of funds (e.g., liveness failure)

| | 🟡 **Medium** |

- Application-level DoS affecting a subset of nodes (non-catastrophic)
- Unintended smart contract behavior due to protocol quirks or edge-case consensus rules
- Time Manipulation Attacks: Exploiting timestamp dependencies in consensus or smart contract behavior.
- Block Reorg Exploits: Minor reorganizations that can affect specific dApps or applications.

| | 🟢 **Low** |

- Shutdown of <25% of network nodes (non-critical, no brute-force)
- Transaction fee modification or miscalculation without economic impact
- P2P Gossip Layer Issues: e.g., propagation delays, non-malicious message flooding, etc.

| If the issue is not under one of the mentioned vulnerabilities, we use the [Common Vulnerability Scoring System](http://159.89.29.143/redirect?url=https://www.first.org/cvss/user-guide) to assess the severity of your vulnerability. # Reports Basics Here are all possible states of reports

### Open report: * **New** - once a report has been submitted it receives a New state. At this stage it’s possible to delete a report, if you have changed your opinion. * **In Review** - The triage team starts the validation process of the submission. * **Need More Info** - if the triage team needs additional details for validation they ask for it. If we don’t hear back from you for more than 15 days, such report will be automatically closed as 'Not Applicable', but without reputation points deduction. * **Triaged** - once we approve the report as a valid security issue, we forward it to the client’s security team to assess its severity and recommend a fix. * **Paid** - the company paid for the valid report to the researcher ### Closed report: * **Resolved** - the report was valid and was fixed. * **Duplicate** - the reported vulnerability has been reported before. In this case, vulnerabilities found on other platforms are also considered duplicates (even if they have not yet been fixed) and if the Company has provided evidence to the HackenProof Triage team that such a vulnerability was found on another platform. * **Informative** - the report was useful for the company but there is no need in immediate action or a fix. * **Out of scope** - the report was useful for the company but the issue is not in the focus of the program. * **Not Applicable** - the report was not valid or it’s not connected with the security of the application. * **Spam** - the report was not a valid security issue or didn’t have any useful information for the company. * **Disclosed** - the report is disclosed to the public.

Variations of states for Disclosed reports

The triage team can adjust the visibility of the report, it can be one of these: * Visible * Partially * Hidden In a state of partial visibility, the team can choose what types of information to disclose: * Report title * Author name * Rewards * Comments * Severity * State * Participants * Creation date * Timeline * Target * Vulnerability details * Validation steps * Impact * Recommended fix * Additional information * Attachments

# Points Guide Executive methodology of hackers points calculation ## Hacker leaderboard score The hacker score is calculated by adding your reputation score to the bounty score. **Hacker score = Reputation score + Bounty score** ### Reputation score (Reports) For each report, you can get a specific number of points. There is a fixed amount of points for resolved reports, depending on their severity (e.g. "Low", "Medium", "High", "Critical"). * **Status "Resolved"**: * Low = +10pt * Medium = +30pt * High = +50pt * Critical = +100pt Also, you can earn bonus points for the report if it will be closed as "Informative" or as "Duplicate", or the team can grant you points for the well-prepared report\*. * **Status "****Informative****"** = 2pt * **Status "****Duplicate****"** = 5pt In case your report is closed as "N/A" or "Spam", you will lose reputation points accordingly * **Status "****N/A****"** = -5pt * **Status "****Spam****"** = -20pt If your report was closed as **"Out of scope"** you will not receive or lose any reputation points. ### Bounty score (Money) The bounty score is calculated by dividing your total earned rewards by 100. Bounty score = **total earned bounty / 100** #### How to get extra 80 reputation points HackenProof allows hackers to fill out their profiles and receive up to 80 additional reputation points. You will get the following reputation points: * Reputation for AVATAR = 30 * Reputation for COUNTRY = 10 * Reputation for BIO = 20 * Reputation for SOCIAL = 20 # Crafting a well-readable report This page offers a comprehensive guide to enhancing the quality of vulnerability reports. Overall, we have seven input placeholders, all of which are necessary and will be helpful in the investigation of your findings. Let's go through each one step by step: 1. **General info** – Vulnerability Title: Provide a short description of the vulnerability and the affected asset. Use the specified names or CVE/CWE IDs if available, but keep it concise and on-topic. 2. **Target** – Specify the vulnerability target: Carefully select from the list and double-check before submitting, as a misclick can cause unnecessary delays in our research. 3. **Target – Vulnerability** category: This is similar to "Vulnerability Title," but more general. Fill it out informatively to help us categorize and triage reports more efficiently. 4. **Target – Serenity** level: Choose one of the preset levels (none, low, medium, high, and critical) or use the CVSS calculator for complex issues. The CVSS calculator is recommended for accuracy.

1. **Vulnerability details**: Describe your finding, including all issue-related themes and relevant external information (links/screenshots). Make it useful for understanding the problem's origin and possible mitigation/fixes. If referencing an article, provide a brief summary and share the link. 2. **Validation steps**: Explain how you achieved the exploitation of your finding. Mention the exact URL/IP/Port where the vulnerability appears and provide clear, step-by-step instructions for validation. 3. **Note on file upload**: To have proof of your finding, always include screenshots or screen capture videos. Ensure that your file is fully uploaded before proceeding with the next one.

Lastly, some recommendations for text styles:

* Use bold, italic, and headers to create logical paragraphs, but don't overdo it. Use these styles to highlight important points.

* Organize information with quotes and numbered/not-numbered lists for clarity.

* Shorten long links using the "link" button, placing the short name in square brackets and the link in rounded brackets.

* Insert code snippets between "\`\`\`" to allow immediate use.

* Utilize the toggle preview tool to review your text block's appearance on the triage side. * You can always view the markdown guide by clicking the far-right button.

* To insert an image, copy it (cmd/ctrl+v) from your file manager and paste it into your report body (use the toggle preview tool if necessary).

* Remember to click on the checkbox and publish your finding. Well-written reports are more likely to be quickly validated and awarded a higher bounty. # Report Submission Requirements To maintain high-quality submissions and reduce spam, HackenProof applies certain restrictions that may affect your ability to submit reports. Please review the following policies before submitting. ### 1. Reputation-Based Access Some programs require a minimum amount of **reputation points** to submit reports. If you do not meet the required threshold, you will not be able to submit.

#### How to increase your reputation: * Submit valid reports to other programs * Complete your profile * Participate actively on the platform * Request guidance via our Discord support channel More info about points can be found [here](/bug-bounty/reports-basics/points-guide). > Reputation helps us ensure that researchers submitting to sensitive programs have proven experience. ### 2. Paid Submissions Certain programs use a **paid submission model**.

This means: * Each report submission requires a fee * The fee amount is defined by the program owner * ***Please note:*** fees for paid submissions in Audits are non-refundable. #### How it works: * The submission fee is deducted from your **HackenProof balance** * If your balance is insufficient, you will not be able to submit #### How to fund your balance: * Use existing funds on your account * Make a deposit through the **Payments** tab in your dashboard ### Refund Policy We aim to ensure fair treatment for researchers. In the following cases, your **submission fee will be fully refunded**: * If your report is marked as **Duplicate** (valid issue already reported) * If your report is considered valid * ***Please note:*** A report is considered valid if a bounty has been paid for it. > A duplicate still confirms a valid issue exists. The refund ensures you are not penalized for reporting real findings. Refunds are processed as a **balance cashback** to your HackenProof account. ### Support & Special Cases We provide additional support for specific situations: #### 🏆 Top 100 Researchers If you are in the **Top 100 leaderboard** and encounter an urgent issue: * You can request account credit via support * Our team will review and may fund your submission ### Important Notes * Paid submissions are not intended to penalize valid research, but to reduce spam and improve triage efficiency * In case of valid duplicates or edge cases, the team may review and compensate accordingly * Always review program-specific policies before submitting ### Need Help? If you have any questions or need assistance:\ → Reach out via our [Discord support channel](https://discord.gg/uFW4xqEU) # Company dashboard # Manage programs This guide describes all the possible stages of your programs You have created a program - great! Now, let’s dive into what statuses it has, and what activities may be required from your side. You can create the following types of programs: * Bug Bounty programs (Public or Private) * Contest programs (Time-limited audit) Your programs may have the following statuses: * **Draft.** You just enter the required data and save the introduced changes. You are free to move to the next stage. At this stage, you may need extra help from us with the program draft, or you want to sign legal docs - welcome to [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof). * **In review** by the HackenProof team. After you publish the program, our team will verify it, and you’ll get the approval. In case you have missed providing important details, our team will instruct you on what info should be added. * **Published**. After signing the agreement and paying a deposit for the program. Published programs are visible to our community of researchers, in case you have chosen a public bug bounty program. In the case of Private Programs, you can start inviting your hackers or ask HackenProof to invite hackers that fit your needs. * **Archived**. (in case you don’t need the program, you can decide to archive it). All data is saved, and you can reactivate this program at a later time. You can see the status of your programs in the programs list in your dashboard:

# Manage reports ## Good to know and follow * Please **don't break the rules**. If you don't follow Program SLA we will delist you from the HackenProof platform * Please **don't try to downgrade** the hacker reward or hide the real severity of the report. If you don't follow the rules we will delist you from the HackenProof platform * The final decision on severity level and a bounty is always on the client * If you triage reports by yourself we may still ask you to allow us to review some reports if researchers have notified us of a reduced reward or severity * We review all incoming reports within 2 hours during business hours. And not more than 16 hours even if it's weekends or holidays ## Triaged by HackenProof 95% of our customers choose HackenProof triage (sorting) services, if you are one of them, then don't worry about the reports, our team will take care of them in time * We will review all incoming reports due to your rules and provide the necessary information to make the final decision on time * All relevant conversations between you and the Hackenproof triage team will take place on the platform or in a pre-arranged private group (on Slack, Discord, Signal, etc.). * If you want to make a report (bug) disclosure, our team can help you to create a professional social media blog post and articles to cover this topic ## Triaged by Customers * Please be sure your triage team follows the program SLA and rules of HackenProof * If you need any help with report triage, communication with researchers, or payments please ping the HackenProof team in a pre-arranged private group (on Slack, Discord, Signal, etc.). * If you want to make a report (bug) disclosure, our team can help you to create a professional social media blog post and articles to cover this topic # Share report Share your report with program Viewers If you need to share a specific report with someone who shouldn't have access to the company's or program's reports, you need to use the Viewer role. ### **Viewer (good to know):** * The Viewer doesn't **have access to the company account or programs at all!** * Viewers can see ONLY a specific report that was shared with them and ONLY in their personal accounts. * To start sharing the report, you need to add the person into the program team with the role of Viewer * You can restrict access to previously shared reports by using the UNSHARE button in the report prerequisites. ### How to find shared reports * Open list of reports of the program. * The shared report has a specific label ![](/files/Pp35TpTMD9gGM2q4Y1kE).

### Add Viewer-person To add Viewer: * Go to the relevant program. * Open the **Program Team** section. * Click on the 'Invite to program' button. * Enter the email address or nickname of the person you wish to add. * Select "Viewer" from the drop-down list of user roles. * Click on the 'Invite' button.

### Share Report To share the report: * Open the report that you want to share. * Navigate to the report prerequisites menu (right side of the report) * Find the **Viewers section** and press the '**Share'** button opposite to the necessary viewer

### Unshare Report To share the report: * Open the report that you want to ushare. * Navigate to the report prerequisites menu (right side of the report) * Find the **Viewers section** and press the '**Unshare'** button opposite to the necessary viewer.

### How Viewers see shared report *The viewer does not have access to the company account. Viewer can only see a report that has been shared with them in their personal account.* After you share a specific report with the viewer, they can find it ONLY in their **personal** (hacker) account:

When the viewer opens the shared report, they will see the following information:

# Labels Create, add and manage Labels in your reports to categorize issues **Labels** allow you to associate your Reports with specific issues, categorize and track them, and identify which report belongs to which category. They also help simplify the search process. For example, you can create a label “Internal known issue” and assign it to all related reports. ***Any member of the company or program team can create labels and assign them to reports. Labels created in one program will be available in another program.*** ### Using Labels While using labels, the following operations are accessible: * Create Labels. * Add Labels from the list. * Filter Labels. * Delete Labels from the report ### Adding and removing labels Follow these steps: * Navigate to the Report you need to label. * Navigate to the report prerequisites menu (right side of the report page) * Click on the "Label" section. A drop-down list of labels will appear.

* To add a label, either select one from the list. * To create a new label, type a descriptive name in the 'Add label' field and press Enter. ***Note.*** *You can add multiple labels to the report.*

* To delete a single label, click the ![](/files/VDHJld2Csxm3BP14DBlO)button next to it. * To delete all selected labels, click the ![](/files/IzJBh8SZV391Rh3JNYPw) button located in the labels field.

### Filter Labels After creating and adding labels to the reports, you can filter them in the report list.

# E2E report encryption This guide describes how to encrypt and decrypt reports End-to-end (E2E) encryption is an optional functionality at HackenProof, and by default, this function is turned off. A core of encryption at HackenProof is PGP encryption. ### End-to-end encryption Implementing end-to-end encryption on HackenProof is a simple process and optional, yet it provides a strong layer of security.

End-to-end (E2E) encryption is intended to prevent data from being read or modified by anyone but the sender (hacker) and recipient (company). The reports are encrypted by the sender (hacker) and decrypted by the recipient (company) locally on their device. Any cloud storage providers or other third parties that transmit or store the data between the sender and recipient handle the data as they normally would. ### What can be encrypted? At HackenProof, our end-to-end encryption service extends to a broad range of data, encompassing text (report body) and multiple file formats. Files encryption includes bmp, gif, jpeg, png, pdf, mpeg, mp4, mov, csv, txt, zip, sol, rs, md, ts and more. ### How to turn on E2E encryption To initiate report encryption, a company has to: * generate its own PGP keypair, which consists of a public key and a private key. You can use one of these resources for key generation: * * * then provide a public key to our team at HackenProof. * Once we receive the public key, we enable report encryption for the company and display a label indicating that encryption is in use. For hackers, the process remains unchanged. They submit a report as they always would, specifying data & files which are then encrypted on their end before they go to our backend. ### How to decrypt the report When a company receives an encrypted report it can be: * **decrypted on the platform** by using the appropriate private key (we don't store private keys so the company has to specify it every time to review the report)

Decrypt encrypted report at the platform

* or report can **be downloaded and decrypted locally** using the private key, you can use one of these tools to decrypt the report: * * ### How to share the encrypted report Read here on how [to share a report with the Viewer](/dashboard/company-dashboard/share-report). Then when you add viewers to your program you can start sharing encrypted reports with Viewers, but before that, you will need: * Your private key to decrypt the encrypted report * and specify the public key of the viewer to decrypt the report * As a result, the Viewer will get the encrypted report and he will need his appropriate private key to decrypt the shared report Note, if your report initially was encrypted then you can't share this report with the viewers without re-encryption # Reports decrypting with Mailvelope This guide describes how to decrypt reports with the Mailvelope extension #### Description: [Mailvelope](https://www.mailvelope.com/) is a well-known browser extension that brings OpenPGP encryption to webmail services like Gmail, Outlook.com, and Yahoo Mail. Beyond email, it can also be used to encrypt and decrypt PGP text on web pages. #### Features: * Automatic Detection: Recognizes PGP-encrypted text blocks on web pages. * Inline Decryption: Allows you to decrypt messages directly on the page. * Key Management: Import, export, and manage your PGP keys securely within the extension. * Open Source: The code is open for review on[ GitHub](https://github.com/mailvelope/mailvelope). *** #### Install Mailvelope: * Go to the Chrome Web Store or Firefox Add-ons and search for "Mailvelope." * Click “Add to Chrome” or “Add to Firefox” to install the extension.

*** #### Setup **Key Pair Creating:** To create a Key Pair in Mailvelope, follow these steps: 1. Click the Mailvelope icon in your browser toolbar.

2. Go to the Key Management Tab.

3. Add your Key. In order to send and receive encrypted messages, you first need a Key. The Mailvelope setup screen will help you to either generate a new one or import an existing one

*** **Key Generating** To generate a key in Mailvelope, follow these steps: 1. Generate a New Key: In the Key Management window, look for an option to "Generate Key" and click on it.

2. Fill Out Key Information: * Name: Enter your name or identifier for the key. * Email Address: Enter the email address you want to associate with the key. * Key Size: Choose the key size (e.g., 2048 or 4096 bits) for better security. 3. Set a Password: Create a strong password to protect your private key. Make sure it’s something memorable but difficult to guess.

4. Generate the Key: Click the "Generate" button. Wait a moment while Mailvelope creates your key pair. 5. Confirmation: Once generated, your new key will appear in the Key Management list. Make sure to back up your private key and passphrase securely. 6. Verifying: Verify Mailvelope email address. For security reasons, the server needs to verify the identity of your email address. To do this it will send you an encrypted email with the subject line "Verify your email address" immediately after key creation. * Be sure to open this email in the inbox of your email provider using Mailvelope. * Click on the ‘Show message’ button

* Enter the password associated with your private key * Verify your email address by clicking on the link in the email. *** **Key Importing** To import a key in Mailvelope, follow these steps: 1. Import Key: In the Key Management window, look for an option that says "Import Key." Click on it.

2. Paste or Upload Key: You can either paste the key directly into the provided field or upload a key file from your computer.

3. Confirm Import: After pasting or selecting the key, click "Import keys", then confirm the key import by clicking the 'Confirm' button.

4. Verify the Key: Once imported, you should see the key listed in your Key Management section. Verify that the key details are correct. *** #### Key Backup After generating your key, make sure to back it up. You can export your public and private keys to a secure location. *** #### HackenProof Domain Authorization To authorize the Hackenproof dashboard domain for it to work with Mailvelope, follow these steps: 1. Load the Hackenproof dashboard ( follow the link ). 2. Select the Mailvelope icon in the upper right corner of your browser to open the main menu. 3. Click on the "Authorize this domain" button.

4. A Mailvelope dialogue to add the new domain will open.\ You can leave the fields "Status", "Domain pattern" and "API" unchanged. Click on the ‘OK’ button.

After clicking the "OK" button, Mailvelope will save the entry in the list of authorized domains. There, the entry can be edited at any time. Reload the newly authorized website to activate Mailvelope. *** **Report Decryption** To decrypt the report on the HackenProof platform using Mailvelope, follow these steps: 1. Open the encrypted report.\ Mailvelope will detect the PGP encrypted message and highlight it. 2. Click on the Mailvelope icon or ‘Show text’ button to decrypt the message.

3. Enter the private key password and click on the ‘OK’ button.

4. The decrypted message contents should now be displayed right in the browser. \ \ \ \ \ \ \
# Users and roles Company users and their roles ### Company users and their roles HackenProof allows companies to create as many programs as they need. At the same time, a company can set up different roles and access. Each company can have users with the following roles: * **Company Admin** - will see all programs and reports * **Company Manager** - will see all programs and reports * **Program Manager** - will see ONLY a specific program and its reports * **Program Triager** - will see ONLY a specific program and its reports * **Report Viewer** - doesn't have access to the company account at all! Viewers can see ONLY a report that was shared with them and only in their personal account

The diagram shows that the Program Manager and Program Triager will only have access to the specific programs they were added to. ### Add Company Manager, Admin To add a Company Manager, Admin: * please navigate to the users and roles menu * add a person with an appropriate role

### Add Program Manager, Triager or Viewer To add a Program Manager, Triager or Viewer: * please navigate to the correspondent program * open the Program Team tab * add a person with an appropriate role

### User roles and their permission


	Company Admin	Company manager	Program manager	Program Triager
View Company Dashboard	yes	yes	yes	yes
View Company analytics	yes	yes	no	no
Users and roles in Company	yes	yes	no	no
View Company payments	yes	yes	no	no
View&Edit company profile	yes	yes	no	no
Company Level View	yes	yes	yes	no
View all bounty programs	yes	yes	only a specific program	only a specific program
Create new program	yes	yes	no	no
Edit program settings and profile	yes	yes	yes, only in a specific program	no
Delete program	yes	yes	no	no
View reports of the program	yes	yes	yes, only in a specific program	yes, only in a specific program
Set reports statuses	yes	yes	yes, only in a specific program	yes, only in a specific program
Assign reports	yes	yes	yes, only in a specific program	yes, only in a specific program
Comment on reports	yes	yes	yes, only in a specific program	yes, only in a specific program
Message Researcher	yes	yes	yes, only in a specific program	yes, only in a specific program
Reward report authors	yes	yes	yes, only in a specific program	yes, only in a specific program
View and export reports	yes	yes	yes, only in a specific program	no
Invite Members to the Program	yes	yes	yes, only in a specific program	only other triagers
Assign Triager	yes	yes	yes, only in a specific program	yes
Assign admin	yes	no	no	no
Assign owners	yes	no	no	no
Invite new admin or manager to a Company	yes	no	no	no

### How Company Admin and Manager see account

### How Program Triager and Manager see company account

### How Viewers see account The viewer doesn't have access to the company account at all! Viewers can see ONLY a report that was shared with them and only in their personal account After you shared a specific report with the viewer, they can find it ONLY in their **personal** hacker account:

Viewer personal account = Hacker account

When Viewer opens the shared report, they will see the following data:

# Program/Report Assignee Program/Report Assignee can be a user with the role of company admin, company manager, program manager or triager, who accepted the invitation to the company or program. The program's default assignee user will automatically become the assignee for all future reports of the program #### Set Program Assignee user To set Program assignee: * please navigate to the correspondent program * open the Program Team tab * select the radio button next to the user you want.

**Set Report Assignee user** To set Report Assignee: * please navigate to the correspondent report * open the Report page * navigate to the report prerequisites menu (right side of the report)

* find the Assignee section and click on it to open the user drop-down list

* choose the necessary user and click on the ‘Set’ button

#### Unassign a Program or Report Unassigning a report is not possible once it has been assigned. You can only change the assignee. **To change Program assignee:** * please navigate to the correspondent program * open the Program Team tab * select the radio button next to the user you want to assign

#### To change Report assignee: * please navigate to the correspondent report * open the Report page * navigate to the report prerequisites menu (right side of the report)

* find the Assignee section and click on it to open the user drop-down list

* choose the necessary user and click on the ‘Set’ button

#### Remember! If the default assignee is not specified in the program, then the report assignee by default becomes the user who will be the first to add a comment to the report or change the status of the report. If an assignee has been assigned to the report, but another member of the company or program changes the report's status, that member automatically becomes the assignee of the report.
# Replenish your balance This guide shows on how to replenish your company account balance at HackenProof According to the rules of the HackenProof platform, the company has to replenish its account (deposit). This deposit will use to: * to pay **hackers for valid bugs** on time. * to pay HackenProof **Bug Fee** according to your agreement * to pay the HackenProof **hosting or triage services** fee according to your agreement. So, If you pay for Triage services monthly then we will charge money from your deposit. ### How much should I deposit? #### Case #1: First-time launch program * If you TRIAGE reports BY YOURSELF, then the minimum deposit to pay hackers has to be 1000 USDC (recommended 5 000 USDC) #### Case #2: Usual case * Please replenish your account by an amount that includes Bug Reward + HackenProof Bug Fee. * Also, you can deposit in advance for future valid bugs. All unused money will be returned to your account after you finish your bug bounty program # Hacker dashboard # How to start ### Welcome to HackenProof 👋 Thanks for choosing HackenProof for responsible vulnerability disclosure! Follow these steps to set up your profile and start submitting reports. #### 1. Create an Account Pick a nickname — this is what others will see on your profile and reports. #### 2. Confirm Your Email Check your inbox and click “Confirm email address” to verify your account. #### 3. Complete Your Profile In your profile, you can fill in these sections: * Profile image * Nickname * Country * Bio * My Socials (Website, Github, Twitter, Linkedin) * Profiles from other platforms (Code4rena, HackerOne, Sherlock, etc.) * Hall of Fame / Achievements * Own Articles 📈 Bonus: Completing Profile image, Nickname, CountryBio, and My Socials grants an extra 80 Reputation Points and boosts your profile credibility. #### 4. Explore Bug Bounty Programs Check out available programs: * Public page: * Hacker's Opportunities: #### 5. Find a Vulnerability & Submit a Report * Test targets within scope * Write a clear, reproducible report * Submit it via the program page * Track updates and communicate through your report page #### 6. Check our [official resources](/welcome/readme/our-resources) #### 7. Feedback See something missing or confusing? Let us know!\ 🔗 For any questions, you can request support on [Discord](https://discord.com/invite/NHX6yt73vh). # Submit a report Please remember, that disclosing any bugs found on HackenProof’s Programs is prohibited without approval. For more details, please see the [Terms of Service](/welcome/code-of-conduct). Once you log into your account, you can find available programs on the **Bounties** page and in **Hacker’s Opportunities**. Browse through the list to find a program that matches your expertise.\ Each program page includes detailed information about its scope, rules, and reward structure. Carefully review the program's scope to understand which assets are in-scope and out-of-scope. Additionally, familiarize yourself with the program rules and disclosure guidelines to ensure compliance. Submitting a high‑quality vulnerability report is essential for quick verification and effective remediation. **To help you through the process, follow the steps below:** 1. **Navigate to the program page** where you want to submit your finding.\ Make sure you are on the correct program — each has its own scope, requirements, and rules. 2. **Locate and click the Submit Report button** on the program’s page.\ This will open the report submission form where you can begin entering your details.

3. **Choose the correct target** that best describes where the issue was found.\ Picking the right target helps team understand the context immediately.

4. **Select the category that most accurately reflects the nature of the vulnerability you are reporting.**\ Picking the correct category helps the team quickly understand the type of issue and ensures it gets reviewed by the right experts.

5. **Set the Severity Level**\ Choose a severity rating that reflects how serious the vulnerability is. You can calculate this automatically using a severity calculator or estimate it manually.

6. **Enter a clear, concise title that summarizes the issue.**\ A good title sets expectations and captures the essence of the vulnerability at a glance.

7. **Vulnerability Details** Provide a comprehensive and clear description of the vulnerability you are reporting. This section should explain: * What the issue is — the type of vulnerability. * Where it occurs — the exact component, URL, parameter, feature, or asset that is affected. * How it manifests — what goes wrong and under what conditions it happens. * Impact and risk — potential consequences if the vulnerability is exploited. * Any contextual information that helps the team understand the scope of the issue.

8. **Validation Steps** List the detailed actions required to reproduce and verify the vulnerability. This should be written as a **step‑by‑step process** that anyone reviewing the report can follow exactly: * Enter the vulnerable page or feature URL. * Perform the required actions (e.g., send a specific request, enter input data). * Include the exact values, payload, parameters, headers, or inputs used. * Observe and describe the behavior that confirms the vulnerability.

9. **Supporting Files / PoC** Upload screenshots, logs, or other media that support your submission and help demonstrate the vulnerability. **Instructions:** * Click or drag files into the upload area to attach them to your report. * You may upload **up to 5 files**. * Maximum file size: **50 MB per file**. **Accepted file formats:**\ bmp, gif, jpeg, png, pdf, mpeg, mp4, mov, csv, txt, zip, sol, rs, md, ts

10. **Review your report thoroughly** before submission.\ Check for clarity, completeness, and accuracy — a well‑structured report significantly improves review time. 11. **Use the “Save as Draft” button if you want to save your progress and continue editing later.**\ This is useful when your report is not yet complete or you want to add more details before submitting. 12. **Choose the “Submit Report” button when your submission is complete and ready for review.**\ Once submitted, your report will be sent to the program team for evaluation and triage. **As soon as you submit a report, you can track its status on the report page in your profile.**\ After submission, you’ll be able to see updates such as status changes, comments from the program team, and any modifications to the severity, vulnerability classification, or reward status directly on your submission page. You may also receive notifications or messages requesting additional information — be sure to respond promptly to help with verification and resolution. ***Note:*** \ Remember that you can still change your report within the first 5 minutes after submitting it. # KYC #### KYC Verification Requirements KYC verification via HackenProof is required in the following cases: * Before withdrawing rewards from the platform, if you are a tax resident of the European Union; * When your report is approved and the company requests KYC verification to credit your reward; * When participating in Bug Bounty / Disclosure / Contest programs where access to code is granted only after completing KYC. You will receive a dedicated link and instructions to complete the KYC process. #### How to Complete KYC 1. Open [kyc-support-request ](https://discord.com/channels/918595597769015397/1485703545436242000) . 2. Our support team will provide you with a link to complete KYC verification: ……….. 3. Make sure to follow these requirements carefully: * Use the same email address that is associated with your HackenProof accoun; * Disable any VPN before starting the KYC process; * Notify us once you have completed the process; **⚠️ Important:** * Failure to follow points 1 and 2 will result in an unsuccessful KYC attempt. #### Attempt Limits & Fees * You have 2 free attempts to complete the KYC process; * Each additional attempt (starting from the 3rd) will cost $3; * If your balance is insufficient, please create a [Paid Submissions](https://discord.com/channels/918595597769015397/1485695133633744916) ticket — the Support Team will provide instructions on how to top up your balance. #### Email Policy * If you change the email address associated with your account, your KYC verification will be automatically rejected; * Transferring KYC to a new email address costs $3. #### Important Notice Repeated violations of these requirements (incorrect email, use of VPN, or unnecessary email changes) generate additional operational costs. Please follow all instructions carefully to avoid delays, rejections, or extra fees. # Сreate a crypto wallet Wallet Types at HackenProof ### User Wallets at HackenProof Each company at HackenProof can have a different program currency, it can be USDC (network Base), ETH, BTC, or their native tokens. Depending on clients' program currency HackenProof supports the following wallets on the platform: * USDC (network Base) * ETH * BTC This means as soon as the company pays your bounty reward the **money will be stored at your account in the appropriate wallet,** and you can withdraw money **at any time you want**. *In 95% of cases, you will receive payments for finding and reporting valid vulnerabilities in the form of* USDC (network Base) *to your HackenProof account.* #### External Wallet If a company pays out of the HackenProof platform or if the company pays in their native token, a researcher might be asked to create a specific wallet and provide wallet details. ### Create a crypto wallet When you want to withdraw money from your HackenProof account you will need to set up your personal wallet to which HackenProof will send your bounty #### USDC Wallet For keeping USDC (network Base) you can use a wallet use a direct address from [any exchange](https://cer.live/), that supports it. #### How to Add a User Wallet To add a wallet, follow these steps: **Method 1:** * Go to the **Payments** page * Click the **"Wallet settings"** button

**Method 2:** * Go to the **Profile Settings** page * Navigate to the **My Wallets** section

**Two-Factor Authentication** * If two-factor authentication (2FA) is not enabled in the user profile, the system will prompt the user to set it up in a modal window.

* If 2FA is already enabled, the Wallet Settings modal window will be displayed. #### Adding a Wallet 1. In the modal window, click **Add new wallet**.

2. In the **Currency** field, click on the dropdown and select the desired currency. 3. In the **Network** field, click on the dropdown and select the appropriate network. 4. In the **Address** field, enter the wallet address. 5. In the **Label** field, enter a custom name to easily identify the wallet (optional). 6. Click the **“Save”** button to add the wallet. 7. Click **“Back”** or close the modal (✕) if you want to cancel the process without saving.

9. To confirm the wallet addition, enter the **2FA verification code** and click **Verify**.

Once the verification is successful, the wallet will be added to the user’s profile. # Withdraw bounty #### Withdraw bounty from HackenProof Starting from May 22, 2025, you will receive payments for finding and reporting valid vulnerabilities in the form of USDC to your HackenProof account. Withdrawals related to earnings exceeding $5,000 in total may be subject to additional contractual formalities and verification requirements in accordance with applicable compliance and financial procedures. \ Please note that the $5,000 threshold refers to the total amount earned on the platform, rather than the amount of an individual withdrawal transaction. For example, verification requirements may still apply even if a user withdraws less than $5,000 in a single transaction. Before withdrawing funds, please ensure it's a regular wallet address and not a smart contract address.\ We never send funds to smart contracts. If the provided address belongs to a smart contract, the transaction may result in a permanent loss of funds, and we will not be able to recover them. To withdraw funds, you must add your wallet address to your HackenProof profile, ensure that all your information is accurate and up to date, and enable two-factor authentication (2FA). Withdrawal of funds is not possible without 2FA enabled. Once these requirements are met, you will be able to securely receive your bounty payment.

#### Withdrawal Instructions To withdraw funds, go to the Payments page and click the Withdraw button in the Withdrawn block.

The image below shows the Withdrawal form. At the top, there is a progress indicator with five steps: Currency, Network, Wallet, Amount, and Confirmation. The current step is highlighted, while the remaining steps remain inactive until completed. A summary block displays the key details of your withdrawal, including Currency, Network, Wallet, and Amount. As you move through each step, this block is automatically updated to reflect your selections, providing a clear and consistent overview at all times. Under the summary, you will find the active dropdown field for the current step (in this case, currency selection). The Next button becomes available once the required information is provided, allowing you to proceed to the next step. You can also use the Back button to return to the previous step and modify your selection if needed.

1. **Currency**\ Choose the currency you want to withdraw from the available options. 2. **Network**\ Select the blockchain network through which the transaction will be processed. 3. **Wallet**\ Pick an existing wallet or add a new one if none is added yet. 4. **Amount**\ Enter the amount you wish to withdraw. The minimum withdrawal amount may vary depending on the chosen currency and network, while the maximum amount cannot exceed your available balance. 5. **Confirmation**\ Review all the details and confirm the transaction by entering the two-factor authentication (2FA) code linked to your account to complete the withdrawal process. \ *Please note that the platform may charge a withdrawal fee for certain currencies and networks.* At the confirmation step, you will see a Withdrawal Fee field indicating the fee percentage as well as the exact fee amount in the selected currency.

After creating a payment request, it is immediately assigned the Pending status. ***Note #1!:** Payments are processed at different times throughout the day, and the expected time to receive your funds is no more than 48 business hours.* ***Note #2!:** Currently, the minimum withdrawal amount is 100 USDC.* Once reviewed, the payment request status will change to either Completed or Rejected.

You can view all payment details by clicking the “?” icon next to each transaction. #### Invoice \[only cryptocurrency] In modern conditions, sometimes security researchers need documents to legalize their rewards in their countries. Before withdrawing money, if you need invoices for tax purposes, you should do the following: * Complete the KYC process. * Open a ticket in our Discord and let us know whether you want to withdraw money to a bank card or a crypto wallet. Next, we will prepare an invoice for you and send it for your approval. After all the steps are completed, you will receive your rewards. ***Note #3!*** : After the actual payment, we will NOT be able to help you with documents if you have not requested them before withdrawal. ***Note #4!*** : If a contract has been signed between us and the researcher, and payment is made based on an invoice, withdrawals are available exclusively via the Ethereum network (ERC-20). The use of any other networks or blockchains for payouts is not supported. ***Note #5!*** : Payments to researchers who are tax residents of European jurisdictions are processed exclusively on the basis of a valid invoice. # HackenProof community ### Discord community All communication happens on our HackenProof discord server. * Join the HackenProof security community in :robot:Discord: ### Other HackenProof resources * :bird:Twitter: * :envelope:Telegram: * :timer:LinkedIn: * :arrow\_forward:YouTube: * :mobile\_phone\_off:Instagram: * :blue\_book:Facebook: (will be deprecated) * :envelope\_with\_arrow:Feedback form: # Report ID How to find your Report ID ### Go To Know At the HackenProof platform, **Report ID** is related to the company program ### How to find Report ID #### Option 1. In the list of reports * Navigate to the “My Reports” page. * Make sure that you see exactly the **submitted reports section.** * Find the Report ID in the report list.

#### Option 2. In the report itself * Open the appropriate report

# Policy on Re-Evaluation of Closed Reports According to HackenProof’s established policy, once a vulnerability report has been closed and marked as "Informative" — particularly when the client has explicitly accepted the associated risk and confirmed that there are no plans to remediate the issue — we do not reconsider or re-evaluate the bounty status after more than three months from the date of closure. # Private Program
#### Private Program Private programs are not publicly accessible, and you can only report vulnerabilities to these programs if you receive specific invitations. #### Viewing and Accepting Invitations After receiving an invitation to the private program from the company, you can find it in your email or on the hacker's dashboard. To view invitations on the hacker's dashboard: * go to the User Dashboard * navigate to the ‘Private programs participation’ section Unaccepted invitations are displayed at the bottom of the ‘Private programs participation’ section. To accept an invitation, simply click on the "Accept" button.

#### Viewing Private Programs participation To view hacker's participation in the Private program: * go to the User Dashboard (make sure you are signed in to your account). * navigate to the ‘Private programs participation’ section

Accepted invitations are displayed at the top of the list. Click on the program name to access the program page and submit the report (check out our guide on how to [submit a report](https://docs.hackenproof.com/dashboard/hacker-dashboard/submit-a-report)).

\ \ \
# Contact support If you have a question, feel free to contact us on the channel https\://discord.gg/pGsQpmyeNt or write to support\@hackenproof.com # Company-Auditor dashboard # How to start How to activate company-auditor account ### Introduction At HackenProof, you can: * create a **company-auditor** account to develop your company brand * create a **team-account** to cooperate with other researchers ### Activate company-auditor account In order to create a company-auditor account and be presented in the list you have to: * Register your account as a Company: * **Verify your email** by clicking Confirm email address in the verification email sent to your email. * Write us in [Discord](https://discord.gg/yZHBwmQM2y) or via email () to activate your company-auditor account. Remember, at this moment, you have to use different emails to create hacker and company accounts. But if you have a hacker account and someone else just adds you to their company or team (so you will not be a company owner), then you can use the same email. # Add members How to add members to your company or team ### Add members In order to add members to your company or team: * Navigate to your company account * Open the Users tab:

* Invite members via their emails or nicknames. Remember, only Admins can add other members. * As soon as a member joins your account, they will be able to submit a report as a part of your team. Remember, a researcher can be a member of one company-auditor or team. ### How to switch between accounts In order to switch between company and hacker accounts:

# Submit report Submit report as part of company or team ### Submit report as part of company or team * Navigate to a program page (make sure you are signed in to your hacker account). * Click the Submit Report button in the preferred program.

* Fill in the required fields (check out our guide on how to [craft a well-readable report](/bug-bounty/reports-basics/crafting-a-well-readable-report)). * As soon as you fill in all required fields, press the **Submit as a Company** button.

* as a result, the report will appear in your hacker dashboard and in the company dashboard.

Remember, when you submit a valid report as a Company member, a report' bounty will be paid to the Company balance (not to the hacker balance) # Contact support If you have a question, feel free to contact us on the channel https\://discord.gg/qxNzXgTj or write to support\@hackenproof.com # MCP Server The HackenProof MCP (Model Context Protocol) server connects AI assistants like Claude Code and Claude Desktop to the HackenProof bug bounty dashboard. It enables AI-assisted triage — reading reports, changing states, setting severity, posting comments, managing labels, and batch operations — all through structured tool calls. ### Quick Start #### 1. Get your credentials **API Key** — get it from your HackenProof dashboard[ account settings](https://dashboard.hackenproof.com/user/profile).

#### 2. Add the MCP server to your config **Claude Code** — add to `.mcp.json` in your project root, or `~/.claude/.mcp.json` globally: ``` { "mcpServers": { "hackenproof": { "type": "http", "url": "https://mcp.hackenproof.com/mcp", "headers": { "X-Api-Key": "YOUR_API_KEY" } } } } ``` **Claude Desktop** — add to Settings → Developer → MCP Servers. #### 3. Verify connection In Claude Code, run `/mcp` to see the server listed. Then try: > "List my companies on HackenProof" # Triage Workflow The recommended workflow for triaging reports: ``` 1. get_program_info → Check scopes, poc_required, focus_area 2. list_reports → Find new/pending reports 3. get_report_details → Read the full report 4. triage_report → Apply state + severity + comment + labels in one action ``` Or use natural language with Claude: > "Review report HACK-55 on company-name/program-name. Check if it's in scope, assess severity, and triage it." # Codebase Security Review with MCP Project teams can connect the HackenProof MCP to their development workflow — using bug bounty reports as a direct feedback loop into their codebase. Instead of manually reading reports and cross-referencing code, your team can let Claude analyze reports against your actual source code in real time. ### How it works 1. **Clone your project repo locally** and open it in Claude Code 2. **Connect the HackenProof MCP** via `.mcp.json` in your project root 3. **Ask Claude to review incoming reports** against your codebase Claude has simultaneous access to your source code (via the local project) and your bug bounty reports (via MCP), so it can: * **Validate reported vulnerabilities** — check if the described attack vector actually exists in your code * **Locate affected code paths** — find the exact files, functions, and lines related to a report * **Assess impact** — determine if the vulnerability is exploitable given your architecture and existing mitigations * **Suggest fixes** — propose code changes based on understanding both the vulnerability and your codebase * **Identify patterns** — spot similar vulnerabilities across your codebase that weren't reported ### Your review pipeline ``` Report submitted → Fetch via MCP → Validate against code → Fix → Tag & resolve ↑ ↓ └──── "Find similar patterns" ───────┘ ``` ### Why this scales Each bug bounty report teaches the AI a new attack pattern. When Claude validates a reentrancy finding in one contract, you can ask it to scan your entire codebase for the same pattern — across every file, every module, every chain. This gets especially powerful when you have: * **Large codebases** — hundreds of contracts or services that are impossible to manually cross-reference with every report * **Multiple implementations** — different versions, forks, or deployments of the same logic where the same bug might exist * **High report volume** — the more reports you receive, the more attack patterns Claude learns to look for. A 50-report audit contest becomes a 50-pattern codebase scan ### Example workflow Open your project in Claude Code with HackenProof MCP connected: > "Fetch all new reports for our-company/our-program and check each one against our codebase. For each report, tell me: is the vulnerability real, where is it in our code, and how should we fix it?" Claude will: 1. Pull new reports via `list_reports` and `get_report_details` 2. Read the vulnerability description and PoC steps 3. Search your local codebase for the affected code 4. Verify whether the issue exists 5. Provide a summary with file paths, risk assessment, and fix suggestions ### Practical examples **Validate a smart contract finding:** > "Report HACK-42 claims there's a reentrancy vulnerability in the withdraw function. Check our contracts and tell me if this is valid." Claude reads the report, finds the relevant contract in your repo, traces the call flow, and confirms whether the reentrancy guard is missing or if the reporter is wrong. **Cross-reference scope:** > "Check if the target mentioned in report HACK-55 matches any of our deployed contracts or endpoints in this repo." **Batch review after an audit contest:** > "We just finished an audit contest on our-program. Fetch all triaged reports and create a summary of confirmed issues grouped by contract file, with severity and recommended fixes." **Proactive vulnerability scanning:**
> "Report HACK-30 found an unchecked return value in TokenSwap.sol. Search our entire codebase for similar patterns — unchecked external calls or missing return value checks." ### Close the loop MCP isn't just for reading reports — your team can act directly from the IDE: * Confirm a finding is valid → change state to "Triaged" and set severity * Need more details from the researcher → post a comment asking for clarification * Found and fixed the issue → tag the report as `fix-deployed` and move to "Resolved" * Spotted duplicates while reviewing code → group them with `dup-` labels The entire lifecycle — from report to fix to resolution — happens without leaving your editor. ### Best practices for large programs * **Start with `get_report_sizes`** before fetching full reports — saves time on large reports with huge PoCs * **Use the `fields` parameter** on `get_report_details` to fetch only what you need (e.g., just `vulnerability_description`) * **Combine with git blame** — ask Claude to check who last modified the affected code and when * **Track fixes with labels** — use `add_labels` to tag reports as `fix-in-progress`, `fix-deployed`, etc. * **Batch review by severity** — use `list_reports` with `severity=["Critical", "High"]` to prioritize what matters first
# Available Tools Reading Data | Tool | Description | | --------------------------- | ---------------------------------------------------------------------- | | `list_companies` | Discover all companies you have access to | | `list_programs` | List all programs for a company | | `get_program_info` | Scopes, rewards, rules, poc\_required, dual\_defence flag | | `get_program_stats` | Report counts and SLA status | | `list_reports` | Search and filter reports with pagination | | `get_report_sizes` | Preview field sizes before fetching full content | | `get_report_details` | Full report content (truncated by default, use `fields` for full text) | | `get_reports_details_batch` | Fetch multiple reports in one call | | `get_comments` | Get comments on a report | | `list_comments_summary` | Comment metadata without text (author, role, date) | | `search_comments` | Search comment text across all reports in a program | | `get_attachments` | List report attachments | | `fetch_attachment` | Download attachment content | | `list_labels` | All available labels for a company | Writing Data #### | Tool | Description | | ------------------------- | ----------------------------------------------------------- | | `add_comment` | Post a markdown comment | | `comment_with_attachment` | Post a comment with file attachment(s) | | `screenshot_and_comment` | Take authenticated screenshot and post as attachment | | `update_comment` | Edit a comment (within 15 min) | | `delete_comment` | Delete a comment (within 15 min) | | `change_state` | Change report state (auto-handles intermediate transitions) | | `change_severity` | Set severity (Low, Medium, High, Critical) | | `add_labels` | Add labels (creates new ones if needed) | | `remove_labels` | Remove labels from a report | \
# Claude Code Skills (Plugins) HackenProof provides two Claude Code skills that automate triage workflows on top of the MCP server. Skills are high-level automation layers — they use the MCP tools under the hood but add structured workflows, policies, and decision-making logic. #### Installation 1. Open a new Claude Code session 2. Run `/plugin` 3. Go to **Marketplace** — HackenProof skills will be listed 4. Browse and install both plugins (under current user) 5. Enable **auto-updates** so new versions are fetched automatically Or add the marketplace manually — in your Claude Code settings, add `hackenproof-public/skills` as a marketplace source.

#### Skill 1: Triage (`hackenproof-triage`) An interactive triage assistant that follows HackenProof's triage policy for each report. It handles: * **Scope validation** — checks if the reported target and version are within program scope * **Duplicate detection** — identifies potential duplicates across existing reports * **PoC verification** — confirms whether a proof of concept is present when required * **Severity assessment** — maps findings to the correct severity using HackenProof classification standards * **Decision & comment** — applies the triage decision (state, severity, labels) and posts a policy-compliant comment Invoke it with `/hackenproof-triage-marketplace` or just describe a triage task: > "Triage report HACK-55 on company-name/program-name" The skill knows HackenProof's global triage policy, severity mapping guidelines, and comment templates — so triage comments are consistent and professional. #### Skill 2: Bulk Triage (`hackenproof-bulk-triage`) Scans all open reports across multiple programs simultaneously, produces summaries, and proposes closure actions for review. Useful for: * **Monitoring 10-20 bounty programs at once** — get a snapshot of all open tickets * **Automated triage pipelines** — bulk review and propose actions without manual report-by-report inspection * **Proactive SLA management** — catch reports before they breach SLA **Setup** Bulk triage requires a config file at `~/.claude/hackenproof-repos.yaml` that maps programs to local code repos and/or blockchain explorers: ```yaml programs: near-intents-smart-contracts: repo: ~/hackenproof/bb/near/intents branch: main some-defi-protocol: explorer: https://etherscan.io/address/0xABC123... multipli-smart-contracts: repo: ~/hackenproof/bb/multipli/Barebones-MultipliVault branch: v2 explorer: https://snowtrace.io/address/0xCF0Eb4... paused-program: repo: ~/hackenproof/bb/paused enabled: false ``` **Configuration fields:** | Field | Required | Description | | ---------- | -------- | -------------------------------------------------- | | `repo` | No | Path to local git clone for source code validation | | `branch` | No | Git branch to track (defaults to current branch) | | `explorer` | No | Blockchain explorer URL for contract verification | | `enabled` | No | Set `false` to skip a program (default: `true`) | Program slugs come from dashboard URLs: `https://dashboard.hackenproof.com/manager/companies/{company}/{program-slug}/...` Invoke with `/hackenproof-bulk-triage` — the skill discovers all open reports, analyzes each one, and outputs structured recommendations for human review. No changes are applied without your approval. Full setup guide: [github.com/hackenproof-public/skills/.../setup-guide.md](https://github.com/hackenproof-public/skills/blob/main/plugins/hackenproof-bulk-triage/skills/hackenproof-bulk-triage/references/setup-guide.md) # Audit process ### How it works * You will need to register your account (or the HackenProof team will register), and draft the program rules & rewards, and specify targets for hackers (or our team will lead this process as well) * As soon as everything is agreed with the HackenProof team, the audit comes alive. Then HackenProof will make social media announcements and another process around the promotion * Researchers (auditors) will start submitting vulnerability reports. **Please note:** Only [qualified auditors](https://app.gitbook.com/o/0Z3kxiFJ9cnGSNBuwZYP/s/aou7mxABOvrk0uZ81vUx/~/changes/74/crowdsourced-audit/qualified-auditors) can participate in HackenProof contests. * As soon as you get the report the HackenProof team will review it due to the specified program SLA * If the reviewed report is valid we will pay through the HackenProof platform to the researcher * Then HackenProof will create the final report ### Before the audit * Welcome to [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to get answers to the questions you might have * We'll ask you to share your smart contracts and answer questions due to our process * You will need to sign the agreement and NDA * Deposit to your HackenProof account ### During the audit * You will need to **freeze the code for the duration of the audit** or make fork of the repo ### After the audit * The HackenProof team will finish to review all incoming reports * Then we will pay researchers for valid reports * Provide you with the final report ### **Audit Cancellation:** We don't have a rescheduling fee, in case the new start day is less than 60 days away, otherwise, it goes under the cancellation rules * If you cancel more than 10 days before the start date → 95% deposit refund * If you cancel 5 - 10 days before the audit start date → 90% deposit refund * If you cancel less than 5 days before the audit start date → 80% deposit refund # How to start Audit Thanks for choosing HackenProof as your platform for getting vulnerability reports! Our ethical hackers' community will help you to avoid hacks. ### Quick start If you want to skip all steps below welcome to [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to get everything as soon as possible (we're available 24/7 for you) ### Steps to start a bug bounty Here are the steps that need to do to start working with HackenProof: * **Create an account** [**here**](https://dashboard.hackenproof.com/register?sign_up=company). Please use your company domain to register a company account * **Verify your email.** Follow the steps in the email to confirm your email address. * **Create a new program or edit available templates**. You can customize templates and specify your targets, range of bounty, logos, and rules. Here is how to create a well-readable bug bounty program * **Send your program for review by HackenProof.** As soon as you finish your program editing you need to press the PUBLISH button.

As a result, the HackenProof team will get an instant notification and will review the created draft. * **Sign legal docs:** [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to sign the NDA & Agreement * **Check your program**. As soon as your program is approved you can check the public program list to find yours: . * **Marketing**. As soon as you start we will prepare banners and blogs for social media advertising and to reach our hackers community. # Supported tech You can run contests (audits) for the following technologies on our platform: * Solidity * Rust * Move * Cairo * Vyper # Vulnerability classification {% embed url="" %} # Qualified Auditors How to become a qualified auditor guide Members of the HackenProof community can become qualified auditors if they meet at least one of the following requirements: * Submitted valid High/Critical issues on HackenProof * Pass HackenProof track ([read more](https://hackenproof.com/blog/for-hackers/hackthebox-hackenproof-blockchain-security-track)) * Complete the Smart Contract Hacking Course by JohnyTime (use the HackenProof [link](https://bit.ly/3RY8RD3) to get a 15% discount) * Be part of the [blockchain auditors](https://hackenproof.com/blockchain-auditors) team. # Judging / Triaging Judging & Triaging policy during the audit contest ### Submission Review The submission review starts right after your submission. If you forgot to add any information, it can be added in the comment box on the platform. The final decision about your ticket will be made during the contest timeline. ### How we work with Duplicates If your report was marked as "Duplicate" in the audit contest, you are still eligible to receive a bounty for it. For example: User 1 submitted a high-severity issue. User 2 submitted the same issue later and it was marked as a "Duplicate". There was only these two high-severity issue identified during the contest. In that case, each user will get: Budget for high severity issue / 2 (50% of budget each) ### If you disagree triage decision If you disagree with the decision of the triage team, you can request a mediation. To do that, left your thoughts in the comment box on the platform and submit a request ticket. # Targets How to read the scope targets in contests page ### In-Scope Targets All targets mentioned in the scope can be taken as a target during the audit. Please check the scope carefully, since if your submission is in the target which is not mentioned in the scope, your submission will be closed without a bounty. If the submission is not in the scope of work but has a high-critical severity, it will be reviewed and delivered to the team. They can make the decision about payment on their own. ### Out-Of-Scope targets If the target is mentioned in the "Out of scope" section, we highly recommend avoiding them. All submissions from the "Out of scope" section will be closed without review. If the submission is not in the scope of work but has a high-critical severity, it will be reviewed and delivered to the team. They can make the decision about payment on their own. # Team Who we are ### Intro At that moment, triaging and judging are the responsibilities of the HackenProof team. ### How to join a judging If you are interested in joining the triage or judging team during the audit contest, feel free to message us at # \[CA] Bounty Distribution Rules In HackenProof Audit Contests, rewards are distributed fairly across valid issues, based on **severity**, **uniqueness**, and **contribution quality**. This system prevents Sybil attacks and incentivizes meaningful, original submissions. ## 💰 Budget Allocation Each audit contest has a fixed reward pool, which is divided by issue severity: | Severity Category | % of Total Rewards | | ---------------------------------- | ------------------ | | Critical | 40% | | High | 30% | | Medium | 15% | | Gas Optimizations & Best Practices | 5% | Only valid, [in-scope submissions](/crowdsourced-audit/vulnerability-classification) will be eligible for rewards. ## 🔒 Fairness and Sybil Protection To prevent abuse (e.g., the same finding submitted from multiple accounts), we use a **Sybil-resistant formula** that rewards original, high-impact discoveries more than duplicated ones. ### 🧠 How it works: If multiple researchers report the same issue, the reward for that issue is shared using the following formula: ``` Issue Weight = 1 × (0.9 ^ (N - 1)) / N ``` Where: * `N` = number of researchers who submitted the same issue * The **fewer** the reporters, the **higher** the reward each person receives This ensures: * Original submitters earn more * Duplicate findings still get rewarded, but fairly * Submitting the same issue under multiple accounts does not result in more money ## 🧮 Real Example (Critical Issues) Imagine the Critical pool is **$40,000**, and we have: * **Issue A** reported by 1 researcher → gets full weight * **Issue B** reported by 2 → shared weight * **Issue C** reported by 3 → shared with further reduced weight Their weights: * A = 1.00 * B = 0.45 * C = \~0.27\ **Total weight = 1.72** Rewards: * Reporter of A: `(1 / 1.72) × $40,000 ≈ $23,255` * Each reporter of B: `(0.45 / 1.72 / 2) × $40,000 ≈ $5,233` * Each reporter of C: `(0.27 / 1.72 / 3) × $40,000 ≈ $2,093` You’ll get a **higher payout if you’re the first and only one to find a valid issue**. *** ### 📌 Summary * All issues which improve the security of the protocol are eligible. * **Originality is rewarded** — submitting duplicates means smaller payouts. * No rewards for **Low** or **Informational** issues. *** If you have any questions, feel free to reach out to our team in the HackenProof Discord or support channel. Happy hacking! 👾 # Fee & Payments ### **How Fee and Payment Works** * 10% HackenProof operational and judging fee (onboarding, maintenance, advisory, reports validation, final report) * Pay rewards in stablecoin, fiat, or your own token/coin * We'll also require a 100% refundable deposit to ensure that the company will pay for the audit. ### Payments for valid reports * 40% for critical issues * 30% for high issues * 15% for medium issues * 5% gas optimization issues, best practices #### Example for 1000 LOC and a $15 000 budget: * $6 000 for critical issues * $4 500 for high * $2 250 for medium * $750 for gas optimization issues, best practices * $1 500 for operational and judging fee ### **Audit Cancellation:** We don't have a rescheduling fee, in case the new start day is less than 60 days away, otherwise, it goes under the cancellation rules * If you cancel more than 10 days before the start date → 95% deposit refund * If you cancel 5 - 10 days before the audit start date → 90% deposit refund * If you cancel less than 5 days before the audit start date → 80% deposit refund # What is DualDefence Audit How DualDefence Audit organized and what for you need one. ## Official Code Audit+ Extra Crowdsourced Audit #### **New Approach to Blockchain Security** Our DualDefense is a service that combines the strengths of traditional audit provider services and HackenProof crowdsourced audits, ensured by the $HAI or other tokenized community. After an audit by professional auditors, HackenProof bug hunters review the code one more time. If critical bugs are found during the 30-day [Crowdsourced Audit](/crowdsourced-audit/audit-process) period, rewards are covered by the DualDefense FlashPool formed from the community stakes. HackenProof community of white hats, auditors, and $HAI/token community – all involved in protecting systems in the DualDefence Audit process.\ \ DualDefence Audit rewards are ensured by corresponding FlashPool value, staked by the community. \ In case no critical issues are found within the crowdsourced phase of the DualDefence Audit — FlashPool stalkers will get their stake and rewards, otherwise — only rewards. ## To start your DualDefence Audit The first step towards DualDefence Audit — get a base audit from a verified audit provider ([Hacken](https://hacken.io/) or any other professional auditing party). After completion of the audit, you can [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to get everything as soon as possible (we're available 24/7 for you). \ \ Or you can create your DualDefence Audit page yourself as shown in this section: [How to start a Bug Bounty program](/bug-bounty/how-to-start-bug-bounty). As soon as you finish creating your audit program and publish it, the HackenProof team will get an instant notification and will review the created draft.\ The next steps will lead to the start of your DualDefence Audit: * **Sign legal docs:** [book the call](https://calendly.com/eleonora_hackenproof/30min) or [write us in telegram](https://t.me/Eleonora_HackenProof) to sign the NDA & Agreement * **Create and announce your Flash Pool.** Every DualDefence Audit is backed by staked $HAI in Flash Pools that holds rewards for security researchers if a critical bug is found. * **Marketing**. As soon as you start we will prepare banners and posts for social media advertising and to reach our hackers community. * **Check your program**. As soon as your program is approved, you can check the public program list to find yours: . # General Guidelines * **Required Report Format:** All submissions must have at least the following sections: * **Overview:** Brief summary of the issue. * **Description:** Clear explanation of the vulnerability, including step-by-step reproduction steps and relevant code excerpts. * **POC:** Runnable Proof of Concept that demonstrates how the attack is performed and the resulting impact. * **Recommendation:** Suggested fix or mitigation strategy. * **POC Requirement:** All Dual Defence submissions must include a runnable Proof of Concept (POC) at the time of submission. POCs submitted later via comments will not be accepted. Submissions missing a valid POC will be closed and may result in a reputation point penalty. * **Extending The Issue Via Comments:** Only the original issue reported will be considered for evaluation. Additional findings, exploit paths, or issues derived from the same root cause introduced via comments will not be taken into account when assessing validity or severity. Repeated attempts to introduce new issues via comments may lead to reputation penalties. * **Multiple Issues Same Root Cause:** a hunter submitting multiple Reports for the same root cause issue (ex: missing access control) will have all the other reports closed and will incur reputation loss and can even have his valid report closed * **Accepted Issues:** Dual Defence reports are evaluated for Critical severity only. However, if a valid Medium or High severity issue is reported with the correct classification, the hunter may be rewarded with reputation points. * **Incorrect severity tagging may result in rejection:** * If you submit a Medium severity issue and label it as Critical, the issue may be closed without reward and reputation points may be deducted. * Valid Critical reports may be downgraded to High, but honest classification will still be rewarded accordingly. * **Low and Informational Issues:** These are not accepted in Dual Defence. Submissions classified by the hunter as anything above Low (e.g., Medium ..) but determined to be Low/Info by Judge will result in reputation loss. # How DualDefence Audit goes DualDefence Audit from start to finish ## How DualDefence Audit goes and all possible results As soon as DualDefence Audit starts — security researchers can start looking for bugs in the targets mentioned in the scope of the DualDefence Audit program, and submit their findings. While auditing team, the HackenProof team and the project team work together to triage all submissions by severity, to verify if there are any critical bugs reported.\ If a critical vulnerability is discovered — the reward will be cowered from the corresponding FlashPool stake. After all reports were assessed and the time for new submissions ended, there are two ending possible: No critical vulnerabilities were found:

DualDefence Audit without critical findings

The critical vulnerability was discovered:

DualDefence Audit with found critical vulnerability

# Contest Phases To ensure fairness, consistency, and clarity throughout Dual Defence contests, please adhere to the following rules, organized by contest phase: ### Submission phase: * All reports must be complete and self-contained at the time of submission. * No new technical information or arguments may be added in the comments after submission. Any additional details will be disregarded. * Once the judge sets an issue to "Review", it automatically enters the Preliminary Phase. ### Preliminary phase: During this phase, reports are under review by judges, who will provide an initial evaluation including validity, severity, and reasoning.\ The security researcher can then comment if he disagrees with the judge's decision. ✅ Allowed in Comments: * Constructive rebuttals responding directly to the judge’s feedback * New, relevant technical points that clarify or reinforce the original issue * Concise arguments focused on the vulnerability itself ❌ Not Allowed: * Repeating what's already in the report without adding anything new * Personal attacks or criticism of the judge or the judging process * Reposting the same point in multiple comments — submit one clear response, then wait for the judge to reply * Excessive or off-topic commentary — keep your message concise and technical #### Additional Guidelines: * Do not open Discord tickets about reports under review. If the issue is still in the "Review" state, the judge has seen your response and is re-evaluating. * Do not discuss your submissions publicly (e.g., in Discord or elsewhere) until results are officially announced. failure to comply with any of these may result in reputation point loss or closing of all your issues in the contests as invalid. ### End of judging: Once a report is moved to a terminal state (Triaged, Invalid, Spam, Out of Scope), the judgment is final.\ Final Phase Rules: * No appeal requests via Discord or tickets — they will be closed without further review. * Do not ask for a second opinion — borderline or critical issues are already reviewed by multiple auditors or triagers when needed. ### End Of Contest * When judging is fully complete, an admin will announce the end of the contest along with the results in the Discord #DD-\[contest-name] channel. * At this point, you are free to discuss your findings publicly. # Vulnerability classification [\[DD\] Smart Contracts](/dualdefense-audit/vulnerability-classification/dd-smart-contracts) # \[DD] Smart Contracts ## IN-SCOPE ISSUES (SMART CONTRACTS) We are looking for evidence and reasons for incorrect behavior of the smart contract, which could cause unintended functionality and are considered as "CRITICAL" severity issues: | **Severity** | **Example Vulnerabilities** | | --------------- | ----------------------------------------------------------------------------------------------------------------------------- | | 🔴 **Critical** |

Direct theft of funds or NFTs
Permanent freezing of funds or NFTs

| ## OUT OF SCOPE ISSUES (SMART CONTRACTS) Submissions falling under any of the categories below will be rejected as not eligible for a bounty {% hint style="warning" %} In DualDefense, only critical reports are in scope, this means that all other reports will be marked as: * Severity: None * State: Out of scope You will not lose reputation points in this case. {% endhint %} | **Severity** | **Example Vulnerabilities** | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 🟠 **High** |

Temporary freezing of funds or NFTs
Theft of unclaimed funds (e.g., yield, royalties)
Permanent freezing of unclaimed funds
Oracle Manipulation (High): Influencing on-chain price feeds or data sources.

| | 🟡 **Medium** |

Theft of gas (unbounded loops, expensive operations exploitable by attackers)
Gas limit / Out-of-Gas vulnerabilities
- Poor gas handling leading to transaction failure, loss of funds, or halted functionality
Denial of Service (DoS)
- Gas exhaustion, block stuffing, or malicious state manipulation that disrupts contract availability
No-profit attacks (Griefing)
- Attacks that damage the protocol or users without financial gain for the attacker

| | 🟢 **Low** |

Failure to deliver promised returns
(e.g., staking pool advertises fixed APY but underperforms due to bugs or flawed logic)
Uninitialized Storage Variables: Can lead to privilege escalation but often low-risk.

| | 🔵 **Info** |

Theoretical vulnerabilities: Issues that simply point out missing checks or lack of adherence to best practices (e.g., CEI pattern) without a concrete exploit scenario are out of scope.
Privileged roles acting maliciously: Issues that assume admin, owner, or other privileged roles will behave incorrectly or maliciously are out of scope, unless a realistic reason or scenario is provided to justify this behavior.
Oracle manipulation or failures: Submissions involving oracles (e.g., missing timestamp checks) are not accepted unless the report demonstrates a clear and practical attack scenario showing how oracle misbehavior leads to an exploit.
Weird Tokens: unless the protocol clearly specifies that it accepts weird tokens (low decimals, erc777) all issues regarding them are out of scope

| # \[DD] Bounty Distribution Rules How to participate in DualDefence Audit **Please always read the individual rules for each DualDefence Audit, as specific conditions may vary per project.** ## ✅ Accepted Reports Only **Critical** vulnerabilities are eligible for rewards in a DualDefence Audit. All valid reports must include: * A detailed description of the vulnerability. * A working Proof-of-Concept (PoC) for re-testing. * (Recommended) Screenshots or a screen recording demonstrating the exploit. All submissions will be reviewed by our Triage Team, then forwarded to the Auditor and Client teams for final validation. **This process can take up until the final days of the audit**, so please be patient. ## 💰 Bounty Distribution **Bounty Pool** – the total reward allocated for the audit\ **Allocated Bounty** – the portion of the bounty pool assigned to each *unique* valid vulnerability The **entire bounty pool is distributed across unique Critical issues**, and then shared among researchers **proportionally** based on the uniqueness of their findings. ### **🧠 Sybil-Resistance Formula** To discourage duplicate submissions under multiple accounts (Sybil attacks), we apply a **diminishing returns formula**: **Issue Weight = 1 × (0.9 ^ (N - 1)) / N** Where: * `N` = number of researchers who submitted the same issue * Issue Weight determines the bounty share assigned to each reporter This rewards original findings more heavily and reduces the reward for duplicated issues. The fewer researchers who submit a specific vulnerability, the larger the portion they receive. ## **🧮 Example** * **Issue A** reported by 1 researcher → Weight = 1.0 * **Issue B** reported by 2 researchers → Weight = 0.45 total (0.225 each) * **Issue C** reported by 3 researchers → Weight ≈ 0.27 total (0.09 each) If these are the only valid issues, the bounty pool is distributed in proportion to the total weights assigned to each researcher. ## ⚠️ Disclaimer Bounty rewards are denominated in **staked tokens in the FlashPool**. Due to market volatility, the final USD equivalent may vary from the initially announced prize.
## ✅ Recommended Before Submitting * Complete **KYC** * Create a wallet eligible to **claim FlashPool rewards** * Thoroughly research the audit scope and project infrastructure # Changelog Some public info about what we do for you ### July 2023 #### Hacker account * ⚙️ Fixed bug with accrual of funds after deleting payment request * ⚙️ Fixed bug Email disclosure after removing hackers' invite to a private program * ⚙️ Fixed code layout issue in report body+comments #### Company account * 🆕 Added GitHub integration * ✎ Don't show monthly payments for a yearly subscription * ⚙️ Fixed dashboard and website layout issues ### June 2023 #### Hacker account * ⚙️ Fixed bug with nickname letters displaying * ✎ Show KYC status and verified label in hacker profile * ✎ Added year to the date section in comments * ⚙️ Fixed bug with dashboard and website layout issues * 🆕 Added the ability to upload files with extensions to reports like .zip, .sol, .rs, .md, .ts #### Company account * 🆕 Added response templates for report comments by company users. * ✎ Added year to the date section in comments * 🆕 Added Zapier Integration to each company program * ⚙️ Fixed Email disclosure after removing user invite to the program * ⚙️ Fixed problems with reports counting ### May 2023 #### Hacker account * ⚙️ Fixed layout issues on some mobile extensions * ⚙️ Fixed dashboard layout issues #### Company account * ✎ Updated emails for SLA notifications * ⚙️ Fixed notification bug with the reports that go to the triaged state * 🆕 Added filter for open and closed reports * 🆕 Added KYC notification for company auditors ### April 2023 #### Hacker account * ✎ Added Report ID to a report #### Company account * ✎ Changed the appearance of the text in the editor according to the design * ✎ Added Report ID to report * ⚙️ Fixed the analytics page layout issue * 🆕 Added the ability to create duplicates from a draft program * 🆕 Added a custom currency symbol for external bounty rewards #### General * 🆕 Now, an auditor can create a Company auditor profile * 🆕 Added list of company auditors to WWW * ⚙️ Fixed JS in the contact form * ✎ Updated the design and code for transit pages ### March 2023 #### Hacker account * 🆕 New methodology for reputation points for hackers' profile * 🆕 New block for displaying hackers info filling progress * 🆕 Added the “Tweet” button to the bounties table * ✎ My activity notifications redesign #### Company account * ✎ My activity notifications redesign * 🆕 Added Slack Integration into the program section #### General * ✎ Changed the order of public bug bounty programs * ⚙️ Fixed the bug with unique passcode entering (2FA) ### February 2023 #### Hacker account * 🆕 New design for hacker profile pages #### Company account * ⚙️ Fixed a bug where the link to the original report was not displayed correctly for a duplicate * ⚙️ Fixed bug with severity column displaying * 🆕 Added notification page for company user profile ### January 2023 #### Hacker account * 🆕 from now a hacker can accept an invite to a private program not only from an email but also from his account's dashboard * 🆕 Added a convenient block from which you can copy a link to your public hacker profile * ✎ updated the block with the list of active reports sent by the hacker * ⚙️ Fixed a number of visual flaws in the hacker dashboard * 🆕 Several useful links have been added to the sidebar in the hacker dashboard, including a large prominent button to go to the list of public bounty programs * ⚙️ Fixed a bug in which the profile completion percentage was incorrectly calculated for some hackers #### Company account * ⚙️ Fixed a number of visual flaws in the company dashboard #### General * 🆕 Now, if a bug bounty program is already published but hasn't started yet, it will display the number of days it will take to launch #### Company account # Branding HackenProof white/black logo png {% file src="/files/bxoqZczTGWzJ00VJnmSc" %} {% file src="/files/1pnPPbQoik17nHY2BVsY" %} HackenProof white/black logo SVG {% file src="/files/zL5nzwF64cTJ2iVGme0f" %} {% file src="/files/bvN9cpPBt3DZ56HdT763" %} HackenProof icons white/black/color logo SVG {% file src="/files/SUiVT47EaL8VOnrk7N2n" %} {% file src="/files/u9CL28TfbDZfrn6GemUP" %} {% file src="/files/SLbaLrFgggo31o7JNlwu" %} HackenProof Brand Guideline {% file src="/files/tYvoW5op7DfGWeTexTIJ" %} # Vulnerability Disclosure Vulnerability disclosure guideline The vulnerability disclosure policy on the HackenProof is based on the mutual agreement by default. The bug hunter may request the disclosure of the vulnerability report as soon as the report status changes to the "Resolved", meaning the vulnerability was fixed. If the security team of the program and the bug hunter agree, the report's content will be disclosed in the discussed timeline. The program security team is allowed to disclose the report without the bug hunter's agreement in the following scenarios: 1\. The security team detected exploitation of the submitted vulnerability and disclose remediation steps, to secure users. 2\. The security team accepts the risk of the issue described in the report and will not fix it, making the users aware of this issue referring to the report. In both scenarios, the personal data of the submitter must be hidden.
# HackenProof Vanguard ### HackenProof Vanguard **What is HackenProof Vanguard?** HackenProof Vanguard is a community and recognition program for trusted security researchers who actively hunt on HackenProof, share practical knowledge, and contribute to the development of the wider security community. It brings together researchers who lead by example through their technical expertise, responsible conduct, and willingness to support others. The program is designed to: * recognize active and experienced security researchers; * make practical bug bounty knowledge more accessible; * support meaningful discussions about vulnerabilities and responsible disclosure; * help researchers better understand scopes, programs, and bug bounty opportunities; * create opportunities for researchers to share their work with a wider audience. ### Vanguard Membership HackenProof Vanguard membership is intended for active and trusted researchers who demonstrate technical expertise, responsible conduct, and a meaningful contribution to the security community. Membership is offered to selected researchers based on their HackenProof activity, reputation, public contributions, and alignment with the program’s principles. **Who can become a Vanguard member?** Potential Vanguard members are evaluated based on several factors, including: * active participation in HackenProof programs; * a history of valid vulnerability reports; * compliance with HackenProof platform and program rules; * responsible and professional communication; * contributions to security education or community discussions; * willingness to share practical knowledge and support other researchers. Meeting individual criteria does not automatically guarantee admission to the program. Membership is subject to HackenProof’s internal review and program capacity. **Member responsibilities** Vanguard members are expected to: * follow HackenProof platform and program rules; * respect confidentiality and responsible disclosure requirements; * communicate accurately and professionally; * avoid misleading, fabricated, or exaggerated claims; * clearly separate personal opinions from official HackenProof statements; * maintain respectful behavior toward clients, researchers, and community members. Participation does not require members to use scripted messages or publish promotional content they do not genuinely support. **Membership review** Membership may be reviewed based on: * activity within HackenProof and the Vanguard Program; * compliance with platform rules; * confidentiality or disclosure violations; * misleading or inappropriate public behavior; * actions that may harm researchers, clients, or the wider security community. HackenProof may suspend or end a membership when program standards are no longer met. **Voluntary participation** Participation in HackenProof Vanguard is voluntary. Members may choose whether to participate in individual content, community, interview, or educational opportunities. Membership does not create an employment, contractor, agency, partnership, or representative relationship with HackenProof. ### Member Opportunities & Benefits HackenProof Vanguard provides selected opportunities to recognize members, support their work, and increase the visibility of useful security research. Benefits may vary depending on member activity, platform rules, internal eligibility criteria, and the availability of specific opportunities. **Free submission credits** Vanguard members may receive access to selected free submission credits on HackenProof. Availability, quantity, and usage conditions may depend on: * active program requirements; * platform rules; * member eligibility; * participation in qualifying Vanguard activities. Submission credits are a program benefit and are not guaranteed compensation. **Vanguard profile badge** Members receive a visible HackenProof Vanguard achievement on their HackenProof profile. The badge recognizes their participation in the program and their contribution to the security community. **Visibility through HackenProof channels** HackenProof may amplify selected public contributions from Vanguard members through its official channels. Examples include: * technical posts; * educational threads; * research notes; * responsible vulnerability write-ups; * bug bounty insights; * community contributions. Amplification is selected individually and is not guaranteed for every publication. **HackenProof Blog contributions** Vanguard members may submit content for publication on the HackenProof Blog, including: * technical articles; * vulnerability research; * bug bounty write-ups; * educational guides; * research methodologies; * security community insights. All submissions are subject to editorial, confidentiality, and security review before publication. **Researcher features** Selected members may be featured through: * researcher spotlights; * interviews; * profile stories; * community pages; * educational campaigns; * other HackenProof publications. Features are based on relevance, availability, and editorial selection. **Community activities** Members may be invited to participate in: * AMAs; * X Spaces; * interviews; * community discussions; * educational initiatives; * researcher spotlights; * other HackenProof community activities. Participation in individual opportunities is optional. ### Community Contribution HackenProof Vanguard supports researchers who contribute to the growth, development, and education of the security community. Members are encouraged to share practical knowledge based on their real experience with bug bounty hunting, vulnerability research, reporting, and responsible disclosure. There is no single required content format. Contributions should reflect each member’s expertise, interests, and communication style. **Sharing practical experience** Vanguard members may share lessons and observations related to: * vulnerability discovery; * bug bounty methodologies; * report preparation; * proof-of-concept development; * program communication; * remediation and disclosure; * common mistakes and useful research practices. Content should be based on real experience and should not present speculation as confirmed fact. **Creating educational security content** Members may contribute through formats such as: * social media posts; * technical threads; * articles and write-ups; * videos; * research notes; * community discussions; * presentations or interviews. Educational content should provide useful context, practical knowledge, or a clear technical perspective. **Helping other researchers** Vanguard members may help researchers: * discover relevant bug bounty opportunities; * understand program scopes and rules; * improve vulnerability reports; * navigate disclosure requirements; * develop stronger research practices; * learn from practical examples. Members should provide guidance responsibly and avoid encouraging actions that violate program rules or create security risks. **Supporting meaningful discussions** Vanguard members can contribute to constructive discussions around: * vulnerability classes; * reporting quality; * severity and impact; * responsible disclosure; * security research methods; * the development of the bug bounty ecosystem. Discussions should remain professional, evidence-based, and respectful toward clients and other researchers. **Authenticity and independence** Vanguard is not based on scripted promotion. Members are encouraged to express honest opinions and share both positive experiences and constructive feedback. Participation in the program does not require members to endorse every HackenProof product, decision, or announcement. ### Content Guidelines Vanguard content should be based on genuine experience, technical knowledge, and responsible communication. These guidelines apply when members publish content connected to HackenProof, the Vanguard Program, HackenProof programs, or benefits received through the program. **Use real experience** Content should reflect the member’s own experience, knowledge, or clearly identified analysis. Members should not: * invent research results; * present unverified claims as facts; * exaggerate achievements or vulnerability impact; * imply access to information they do not have; * publish misleading comparisons or conclusions. **Communicate accurately** Technical information should be explained as accurately as possible. When information is incomplete or uncertain, members should make that clear. Corrections should be made when meaningful errors are identified. **Maintain professional communication** Members should communicate respectfully toward: * researchers; * HackenProof clients; * program teams; * triagers; * developers; * community members. Constructive criticism is welcome, but harassment, personal attacks, threats, or intentionally harmful behavior are not acceptable. **Distinguish personal opinions** Vanguard members share their own opinions and experiences. Unless explicitly authorized, members must not: * present personal statements as official HackenProof positions; * make commitments on behalf of HackenProof; * represent themselves as HackenProof employees or official spokespersons; * provide official interpretations of platform or program policies. **Disclose Vanguard participation** Members should clearly disclose their participation in the HackenProof Vanguard Program when content is connected to: * program benefits; * partnerships or coordinated activities; * visibility or amplification provided by HackenProof; * other material support received through the program. The disclosure should clearly explain the member’s relationship with the program. **Technical write-ups** Technical write-ups connected to HackenProof programs must follow all applicable disclosure and confidentiality requirements. Approval must be obtained before publishing program-related vulnerability information that has not already been authorized for public disclosure. **Responsibility for published content** Members remain responsible for content published through their personal accounts, websites, communities, or external platforms. Participation in HackenProof Vanguard does not transfer responsibility for a member’s claims, opinions, legal obligations, or third-party content to HackenProof. ### Confidentiality & Responsible Disclosure Vanguard membership does not change the confidentiality requirements of HackenProof programs. Members must continue to follow all program rules, non-disclosure requirements, disclosure timelines, and responsible research practices. **Undisclosed vulnerabilities** Members must never publish details of a vulnerability before disclosure has been authorized. This includes: * vulnerability descriptions; * technical exploitation details; * proof-of-concept code; * affected endpoints or contracts; * screenshots or report excerpts; * information that could allow others to reproduce the issue. **Private scopes and reports** Members must not share: * private or invite-only program scopes; * vulnerability reports; * private program instructions; * internal comments or communications; * unpublished remediation information; * confidential platform materials. Information must not be shared with third parties unless explicitly permitted. **Client-sensitive information** Members must protect information that could expose or create risk for a HackenProof client. This includes technical, operational, business, infrastructure, and user-related information obtained through participation in a program. **Approval before publication** Members must obtain approval before publishing a technical write-up connected to a HackenProof program or finding when disclosure has not already been authorized. Approval may include review of: * technical details; * disclosure timing; * screenshots and report excerpts; * client references; * remediation information; * affected assets and scope details. Submitting content for review does not guarantee approval for publication. **Responsible disclosure requirements** Members must: * report vulnerabilities through the approved HackenProof process; * avoid accessing unnecessary data; * stop testing when continued activity could create harm; * follow the rules of the relevant program; * allow the program sufficient time to investigate and remediate; * respect all disclosure decisions and timelines. **Security risks** Members must not publish content that could create an active security risk for: * a client; * a program; * a user; * an affected system; * the wider community. When uncertain whether information can be published, members should treat it as confidential until permission is provided. **Confidentiality violations** A confidentiality or responsible disclosure violation may result in: * removal of content; * suspension or termination of Vanguard membership; * restrictions on HackenProof account activity; * actions permitted under the applicable program rules or agreements. ### Program Terms HackenProof Vanguard is a voluntary recognition and community program operated by HackenProof. These terms describe the general nature of participation and the relationship between HackenProof and Vanguard members. **No employment or agency relationship** Participation in HackenProof Vanguard does not create an employment, contractor, partnership, agency, or representative relationship. Vanguard members are not authorized to: * act on behalf of HackenProof; * enter into agreements for HackenProof; * make official commitments; * issue official statements; * represent themselves as HackenProof employees or agents. **Independent participation** Members independently decide whether and how to participate in available activities. They remain responsible for: * their own public content; * their personal opinions and claims; * compliance with applicable laws; * tax obligations connected to any benefits or compensation they receive; * compliance with third-party platform rules. **Program benefits** Benefits are provided as recognition, access, or selected community opportunities. They are not guaranteed compensation and may: * depend on eligibility criteria; * be limited in quantity; * vary between members; * change over time; * be unavailable in some cases; * be discontinued without replacement. Membership itself does not guarantee payment, credits, publication, promotion, or participation in specific activities. **Public content and amplification** HackenProof may repost, reference, or feature public content created by Vanguard members. Where additional rights or approvals are required, they may be agreed upon separately. Amplification through HackenProof channels does not mean that HackenProof endorses every statement or opinion expressed by a member. **Program changes** HackenProof may update: * program requirements; * membership criteria; * available benefits; * participation guidelines; * community activities; * these program terms. HackenProof may also pause or discontinue the Vanguard Program when necessary. **Membership termination** HackenProof may suspend or terminate membership due to: * prolonged inactivity; * platform or program violations; * confidentiality breaches; * irresponsible disclosure; * misleading or harmful public claims; * abusive or inappropriate behavior; * actions that may damage researchers, clients, HackenProof, or the wider community. Members may also choose to leave the program. **Relationship with other HackenProof rules** Vanguard membership does not replace or override: * HackenProof Terms of Service; * individual bug bounty program rules; * confidentiality obligations; * disclosure requirements; * platform policies; * any separate agreement applicable to a member. Where requirements differ, the stricter confidentiality and security obligation should be followed. # National CTF This page is related to the National CTF of Ukraine and explains the level of difficulty for participants. ### **CTF Difficulty Levels (Ukrainian version)** #### Рівень 1: Криптографія, OSINT та Логіка **Мета:** Перевірити базові навички аналізу, дешифрування, збору відкритої інформації та логічного мислення. **Криптографія** * Caesar (зсув) — розшифрувати повідомлення з невідомим зсувом. * Ланцюжок Base-кодувань — повідомлення закодоване кількома шарами (наприклад Base32 → Base58 → Base64). Розпізнати та розкодувати кожен шар. * XOR-зашифрування — дешифрувати текст, XOR-ований одно-байтовим ключем. * RSA з спільними простими множниками — відновитиприватний ключ при наявності двох публічних ключів з одним спільним простим множником. * Підстановочна шифра (monoalphabetic) — аналіз частот для відновлення таблиці замін. **OSINT** * Знайти місцезнаходження автора — аналіз EXIF у зображенні. * Знайти корпоративний email — пошук через LinkedIn/WHOIS/Crunchbase. * Виявити endpoint для скидання пароля — аналіз відкритихдиректорій, robots.txt та sitemap. * Відстежити користувача за нікнеймом — знайти пов’язаніакаунти в соцмережах. **Логіка** * Логічні задачі на розпізнавання паттернів — завершитипослідовність символів/чисел. * Шифри-головоломки — поєднання підказок у тексті, щовказують на порядок операцій. * Код-серії — знайти правило перетворення рядка (перестановки, заміни, групування). * Задачі на дедукцію — кілька підказок, які ведуть до єдиногоправильного висновку (наприклад 'хто злодій' за набором фактів). #### Рівень 2: Середній — веб-пентестинг **Мета:** Виявлення та експлуатація середнього рівня вразливостей у веб-застосунках. * Path Traversal — доступ до захищених файлів через directory traversal. * Reflected XSS — ін’єкція JS для викрадення cookie або виконання дій від імені користувача. * CSRF — примусити жертву виконати небажану дію (наприклад, змінити пароль). * .env leak — витік ключів API або даних БД через неправильнуконфігурацію. * .git exposure — відновлення коду з відкритої .git директорії. * Слабкі паролі — брутфорс форми логіну за словником. * Відкритий FTP/SSH з дефолтними паролями — підключення до сервісів. * Небезпечний API endpoint — доступ без автентифікації абоавторизації. * Сканування сервісів (Nmap) — виявлення відкритих портів та сервісів. #### Рівень 3: Високий — просунутий веб-пентестинг **Мета:** Багатоступеневі експлойти, підвищення привілеїв та латеральний рух. * Експлуатація відомого CVE для обходу автентифікації. * Remote Code Execution (RCE) — виконати довільні команди та отримати reverse shell. * Обхід перевірки при завантаженні файлів — завантажити та виконати вебшелл. * Blind SQL Injection — ексфільтрація даних через time/boolean-based техніки. * Витік через ViteJS dev server / source maps — читання локальнихфайлів. * Зловживання віддаленими debugger endpoint’ами — отриматиконтроль через консоль devtools. * Підвищення привілеїв через IDOR / неправильні ACL — отримати доступ до ресурсів інших користувачів. * Комбінований експлойт / pivoting — ланцюжок уразливостейдля доступу до внутрішніх систем. ### **CTF Difficulty Levels (English version)** #### **Level 1: Cryptography, OSINT, and Logic** **Goal:** Evaluate baseline skills in analysis, decryption, open-source intelligence gathering, and logical reasoning. **Cryptography** * **Caesar cipher (shift):** Decrypt a message with an unknown shift value. * **Base-encoding chain:** The message is encoded in multiple layers (e.g. Base32 → Base58 → Base64). Identify and decode each layer. * **XOR encryption:** Decrypt text that was XOR-encrypted with a single-byte key. * **RSA with shared prime factors:** Recover the private key given two public keys that share one prime factor. * **Monoalphabetic substitution cipher:** Use frequency analysis to reconstruct the substitution table. **OSINT** * **Identify the author’s location:** Extract and analyze EXIF data from an image. * **Find a corporate email address:** Use sources like LinkedIn / WHOIS / Crunchbase. * **Discover the password reset endpoint:** Inspect open directories, `robots.txt`, and the sitemap. * **Track a user by nickname:** Correlate connected social media accounts. **Logic** * **Pattern recognition puzzles:** Complete a sequence of symbols or numbers. * **Cipher riddles:** Combine scattered hints in the text to determine the correct order of operations. * **String transformation rules:** Infer how an input string is transformed (reordering, substitution, grouping). * **Deduction problems:** Multiple clues lead to a single correct conclusion (for example, identifying “who is the thief” from a defined set of facts). #### **Level 2: Intermediate — Web Pentesting** **Goal:** Detect and exploit medium-severity vulnerabilities in web applications. * **Path Traversal:** Access restricted files via directory traversal. * **Reflected XSS:** Inject JavaScript to steal cookies or perform actions as the victim. * **CSRF:** Force a victim to execute an unwanted action (e.g. change their password). * **`.env` leak:** Extract API keys or database credentials due to misconfiguration. * **`.git` exposure:** Recover source code from an exposed `.git` directory. * **Weak passwords:** Dictionary brute-force against the login form. * **Open FTP/SSH with default credentials:** Log in to exposed services. * **Insecure API endpoint:** Access functionality with no proper authentication or authorization. * **Service scanning (Nmap):** Enumerate open ports and running services. #### **Level 3: Advanced — Offensive Web Operations** **Goal:** Multi-step exploitation, privilege escalation, and lateral movement. * **Exploiting a known CVE to bypass authentication.** * **Remote Code Execution (RCE):** Execute arbitrary system commands and obtain a reverse shell. * **Bypassing upload validation:** Upload and run a web shell. * **Blind SQL Injection:** Exfiltrate data using time-based or boolean-based techniques. * **Leaking internals via ViteJS dev server / source maps:** Read local files or reveal internal logic. * **Abusing exposed remote debugger endpoints:** Take control through devtools consoles. * **Privilege escalation via IDOR / misconfigured ACLs:** Gain access to other users’ resources. * **Chained exploit / pivoting:** Combine multiple vulnerabilities to move deeper into internal systems. # Courses **Solidity:** * [smartcontract.engineer](https://www.smartcontract.engineer/) * [Cryptozombies](https://cryptozombies.io/en/course/) * [JohnnyTime Smart Contract Auditing course](https://bit.ly/3RY8RD3) #### CTF Challenges: * [Ethernaut](https://ethernaut.openzeppelin.com/) * [Capture The Ether](https://capturetheether.com/) * [QuillCTF](https://www.quillaudits.com/academy/ctf) * [Curta CTF](https://www.curta.wtf/) * [Paradigm CTF](https://ctf.paradigm.xyz/) * [ciphershastra CTF](https://ciphershastra.com/index.html) * [Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/) * [unhackedctf](https://github.com/unhackedctf) \
# Tools **Research** **Tools:** * [Slither](https://github.com/crytic/slither) * [Mythril](https://github.com/ConsenSys/mythril) * [Mythx](https://mythx.io/) * [Echidna](https://github.com/crytic/echidna) * [Foundry FUZZ](https://book.getfoundry.sh/forge/fuzz-testing) * [Manticore](https://github.com/trailofbits/manticore) * [Surya](https://github.com/ConsenSys/surya) **VS Code Extensions:** * [Solidity Visual Developer](https://marketplace.visualstudio.com/items?itemName=tintinweb.solidity-visual-auditor) * [Solidity Metrics](https://marketplace.visualstudio.com/items?itemName=tintinweb.solidity-metrics) * [Slither VSC](https://marketplace.visualstudio.com/items?itemName=trailofbits.slither-vscode) * [EthOver](https://marketplace.visualstudio.com/items?itemName=tintinweb.vscode-ethover) # Useful sources * [solidity-patterns](https://github.com/fravoll/solidity-patterns) * [solcurity](https://github.com/transmissions11/solcurity) * [Smart Contract Security Verification Standard](https://github.com/securing/SCSVS) * [Consensys Smart-contract-best-practices](https://consensys.github.io/smart-contract-best-practices/) * [Security Pitfalls & Best Practices 101](https://secureum.substack.com/p/security-pitfalls-and-best-practices-101) * [Security Pitfalls & Best Practices 201](https://secureum.substack.com/p/security-pitfalls-and-best-practices-201) * [SWC Registry](https://swcregistry.io/) * [Kaden: Smart Contract Attack Vectors](https://github.com/KadenZipfel/smart-contract-attack-vectors) * [Solidity Attack Vectors](https://github.com/Quillhash/Solidity-Attack-Vectors) * [Common Vulnerabilities in Smart contracts MindMap](https://github.com/Anugrahsr/Awesome-web3-Security/blob/main/image/Vulnerabilities_in_Smart_contracts.png) * [VigilSeek bug bounty aggregator ](https://www.vigilseek.com/) * [VigilSeek telegram alerts channel](https://t.me/vigilseek)