A bounty is not a hackathon
A hackathon rewards new builds. A bug bounty rewards finding and documenting a weakness in something that already exists.
The work is more forensic. You need a reproducible report, a clear impact statement and respect for the program scope.
Scope decides everything
Every bounty defines what systems, domains, contracts or apps are eligible. Testing outside scope can get your report rejected and can create legal risk.
Read exclusions before doing anything technical. Duplicate reports, low-impact findings and social engineering are often unpaid even when they look interesting.
Good reports are boring and precise
A useful report explains the target, steps to reproduce, expected behavior, actual behavior, impact and a suggested fix or mitigation.
Screenshots help, but clarity matters more. The triager should be able to reproduce the issue without guessing what you meant.
Choose bounties by payout quality
A high maximum payout means little if the program rarely pays or treats most findings as informational. Look for published ranges, responsive triage and recent valid reports.
For builders, bounties can be a useful way to learn security while earning, but they are slower and less predictable than grants or hackathons.
< read by a human · updated as things change >
browse hackathons