For developers
List a program researchers want to work on.
A well-crafted listing attracts serious researchers, sets clear expectations, and reduces noise. Here's how to write scope, set payouts, and keep your program healthy.
What makes a good listing
- 1Clear, specific scopeSay exactly what is in scope — domains, subdomains, APIs, mobile apps, account types. Researchers skip programs with vague scope because they don't know what's fair game.
- 2Competitive, real payoutsPayouts don't need to be the highest on the platform, but they should reflect the value of the vulnerability. A P1 that pays £100 signals you don't take critical bugs seriously.
- 3A description that sells the productExplain what your product does, who uses it, and why it matters. Researchers want context — knowing your stack, user base, and architecture helps them find meaningful bugs.
- 4Active, responsive maintainerThe strongest signal of a healthy program is response time. Triage reports within 48 hours, reply to questions, and keep your payout tiers up to date.
Writing your description
What the product does
One or two sentences about what your product is and who uses it. Mention the tech stack if relevant — “React SPA with a Go API” tells researchers what to look for.
Developer background
The dev_info field is shown to researchers on your program page. Use it to explain anything unusual about your setup, acknowledge known limitations, or share conventions you follow. Being upfront builds trust.
Scope & rules
List what’s included and what’s explicitly out of scope. If you have a staging environment, say whether it’s testable. If certain account tiers are off-limits, call that out.
Keep it current
Update your listing when your product changes. A stale description with outdated scope frustrates researchers and leads to out-of-scope reports.
Setting payout tiers
Your payout tiers (P1–P5) are the first thing researchers check. They determine whether someone invests time in your program or moves on.
P1 — Critical
Remote code execution, authentication bypass, payment manipulation, full account takeover. This is your headline bounty — make it count.
P2 — High
SQL injection, SSRF with internal access, privilege escalation, stored XSS with meaningful impact. Should be a strong incentive.
P3 — Medium
IDOR with data access, stored XSS, CSRF with state change. The workhorse tier — most valid reports land here.
P4 — Low
Reflected XSS, low-impact info disclosure, open redirect. Small but non-zero — shows you value thoroughness.
P5 — Informational (can be £0)
Best-practice violations, missing headers, theoretical concerns. P5 is the only tier that can be set to £0. Consider a token amount to encourage diligence.
Researchers filter programs by bounty range. A program with a £500 P1 will attract more attention than one with a £50 P1, all else equal. Set the highest amounts your budget allows.
Verification and trust
- 1Verify your domainBefore your program goes public, VibeBounty verifies you control the listed domain. Upload the verification file to your site and click Verify in the dashboard. Programs with unverified domains cannot be listed publicly.
- 2Add the canary snippetThe canary token proves researchers actually visited your site. Add the JavaScript snippet to every page and enable Required canary proof in settings. This is the strongest defence against fabricated reports.
- 3Provide test credentialsIf your product requires authentication to reach the areas researchers should test, add test credentials in your product settings. The reproducer uses them to log in before verifying reports. Use a dedicated account — never share production credentials.
A program with no verified domain, no canary snippet, and no test credentials signals low effort. Researchers avoid these programs because they expect reports to get ignored.
Common mistakes
Scope too broad
“Everything on example.com” isn’t scope — it’s an invitation for noise. List specific assets, endpoints, and account types.
Unrealistic payouts
If your P1 payout is £50 and your P5 is £1, researchers will assume you don’t value security work. Even modest increases signal seriousness.
No response to reports
The fastest way to kill your program is to let reports sit unread. Auto-close kicks in after 14 days of inactivity — use it as a floor, not a target.
Hidden or missing scope
Scope buried in a PDF or external link means researchers won’t read it. Put the most important rules directly in your listing description.
Skipping canary tokens
Without canary proof, anyone can submit a report claiming they found a vulnerability on your site. Enabling required canary proof eliminates fabricated reports entirely.
Stale listings
If your product pivots or your scope changes, update your listing. An outdated listing generates out-of-scope reports and wastes everyone’s time.
A well-run program with clear scope, fair payouts, and quick response times builds a reputation that attracts the best researchers. The best programs on VibeBounty treat researchers as partners, not adversaries.