Launching a bug bounty program
From sign-up to a live, versioned rulebook that researchers can trust.
1. Create your organization
Register as a project. You become the organization's owner. Project accounts must enable two-factor authentication before publishing anything or acting on a case, because you'll be receiving unreleased critical vulnerabilities.
2. Create the program
In onboarding, choose Bug bounty program. Give it a name, a one-line description, a category, a language, and its ecosystems. Then pick a starting rulebook:
- Smart contracts / DeFi: funds-at-risk impacts, with Critical rewards set as a percentage of funds at risk.
- Web / app / API: account-takeover and data-access impacts, with fixed rewards.
3. Write the rulebook
The builder forces explicit answers, because ambiguous prose is where disputes start.
| Section | Tips |
|---|---|
| Assets | Every in-scope contract, URL or repository. Researchers can only pick from this list. |
| Impacts & severity | Write objective conditions for each impact. Severity follows from them. |
| Rewards | Fixed amounts, or a percentage of funds at risk with a minimum and maximum. |
| PoC requirements | IDs like POC-1. "Not demonstrated" closures must cite one. |
| Exclusions | IDs like EXCL-3. "Out of scope" closures must cite one. |
| Testing restrictions | What's prohibited (mainnet testing, social engineering, DoS). |
| SLAs | Acknowledge (hours), triage (hours), payout (days). Compliance is public. |
| Policies | Duplicates, known issues, disclosure (embargo), mediation window, payment terms. |
4. Publish version 1
Publishing creates an immutable version with a SHA-256 fingerprint, and the program goes live. Every report is bound to the version that was live when it was submitted.
5. Changing the rules later
Edit in the builder and publish a new version with a changelog. The version history shows which sections changed and how many reports are locked to each version. Older reports are never re-governed by new rules.
6. Make the reserve provable (recommended)
Link a ProoflineVault so researchers see a live on-chain reserve rather than a promise. See Payout vaults.
Your public track record
Program pages show metrics computed from Proofline events: median acknowledgement and triage times, SLA compliance, median payout time, overdue payouts, mediation rate and reversal rate, remediation, and Won't Fix counts. Researchers use these to decide where to spend days auditing.