Bounties and Payouts
How to approve bounties, manage the disbursement pipeline, handle tax documents, and use the immutable financial ledger for SOC 2 evidence.
Why It Matters
Bounties and payouts require the VDP Add-on ($49/mo). They unlock the full disbursement pipeline, immutable financial ledger, and tax document management described on this page.
Getting payouts right is both a researcher-retention issue and a compliance obligation. Manual PayPal transfers without collecting W-8BEN (non-US) or W-9 (US) forms create direct IRS exposure for your company. Every payment to a researcher is a reportable taxable event, and the absence of tax documentation shifts the liability to you. Kit’s disbursement pipeline solves this by gating payouts behind a configurable readiness checklist that includes tax document verification.
The immutable financial ledger is the primary SOC 2 evidence artifact for your vulnerability disclosure program’s financial controls. Every bounty approval, every disbursement, and every tax document action is recorded with actor, timestamp, and amount. Auditors can verify the complete chain of custody from report resolution to payment confirmation in a single export.
Bounty Matrix
The bounty matrix maps CVSS severity tiers to dollar ranges. Configure it in VDP > Program Settings > Bounty Matrix. When a team member scores a report with a CVSS assessment, the suggested bounty range is automatically pulled from the matrix and pre-filled on the approval form.
Bounty ranges are displayed on your public disclosure policy page so researchers know what to expect before they submit. This transparency reduces disputes and sets clear expectations.
For recognition-only programs, leave all tiers at $0. Researchers will see “recognition only” on the policy page instead of dollar amounts.
See Configuring Your Program for full matrix configuration details.
Approving a Bounty
Admins can approve a bounty at any point before the report reaches Paid status. As a best practice, wait until the report is validated — ideally resolved — so the amount reflects a confirmed, assessed vulnerability.
To approve a bounty:
- Open the report detail page
- Click Approve Bounty
- Fill in the approval form
| Field | Required | Description |
|---|---|---|
| Amount | Yes | Bounty amount, pre-filled from the bounty matrix based on the report’s CVSS severity tier. |
| Currency | Yes | Defaults to USD. Must match your program’s configured currency. |
| Notes | No | Internal notes visible only to your team. Encrypted at rest. |
Approval requires explicit submission — no amount is committed until you save the form. On approval:
- A
bounty_approvedentry is appended to the immutable ledger - The researcher is notified via the
bounty_approvedemail template
Revoking a Bounty
Dismissing a report that has an approved bounty automatically revokes it. The dismissal modal warns you with the amount, approver, and approval date, and the submit button changes to Dismiss & revoke $X bounty. On revocation:
- A
bounty_revokedentry is appended to the immutable ledger as a debit — the ledger’s approved and pending totals subtract it. The entry’s metadata records the dismissal reason, the original approver and approval date, and the disbursement status at the time. - The researcher’s dismissal email states that the previously approved bounty has been withdrawn and will not be paid; the standard appeal flow is the recourse. Their portal shows a “withdrawn” note instead of the bounty card.
- The karma granted for the bounty is reversed with a “Bounty Revoked” karma event.
Two safeguards apply:
- A bounty whose disbursement is Completed can never be revoked — paid is paid.
- A payout in flight (disbursement Pending or Processing) blocks dismissal. Mark the disbursement as failed first, or let it complete.
Undoing a dismissal does not reinstate the bounty. Once the report is validated again, approve a new bounty manually — the staff UI shows a reminder.
Disbursement Pipeline
Navigate to VDP > Disbursements to see all pending payouts. Each row shows the researcher, linked report, approved amount, and payout readiness status.
Readiness Checklist
Before a disbursement can proceed, the researcher must satisfy a readiness checklist. All three items are configurable in your program’s payout settings:
- Payout info submitted — The researcher has entered their payment details (bank, PayPal, or other method) via The Researcher Portal
- Agreement accepted — The researcher has accepted your program’s participation agreement (if your program requires one)
- Tax document verified — The researcher’s W-8BEN or W-9 has been uploaded and verified by your team (if your program requires tax docs)
Items that are not enabled in your program settings are automatically marked as satisfied.
The checklist also gates on the report’s status, controlled by Require Verified Fix Before Payout in VDP > Program Settings > Payouts:
- On (default) — The bounty can only be disbursed after your team marks the report’s fix as verified. You never pay for an unresolved bug, but researchers may wait for the fix to ship.
- Off (pay on validation) — The payout unlocks as soon as the report reaches Validated, the industry norm on platforms like HackerOne and Bugcrowd. Researchers are paid faster, and payment is decoupled from closing the report: the report stays open after the money moves and closes as Paid automatically once it is resolved (or fix-verified). Paid reports can never be dismissed, and fix verification becomes an optional QA step — record it before the report resolves, or it won’t be tracked.
Processing a Payout
Kit does not execute wire transfers or payment API calls. Your team handles the actual money movement outside Kit (bank transfer, PayPal, crypto, etc.). Kit tracks the lifecycle:
- When all readiness items are satisfied, click Initiate to move the disbursement to Processing
- Execute the transfer through your payment provider
- Return to Kit and click Mark as Paid — enter the transaction reference (e.g., PayPal transaction ID, wire confirmation number)
- The disbursement moves to Completed and the report transitions to Paid (on pay-on-validation programs, a report paid before it is resolved stays open and closes as Paid automatically once it gets there)
Finance Team Confirmation
In most companies the person who schedules the payment sits in finance, not security — they watch an inbox like [email protected] and have no Kit account. The finance handoff closes that gap: Kit emails your finance team everything they need to schedule the payment, and they confirm it themselves through a secure link.
Enable it by setting Finance Email in VDP > Program Settings > Payouts. Leave the field blank to keep recording payments manually in Kit.
With a finance email configured, clicking Initiate also sends a payment request to that address containing:
- The payee (researcher), amount, and payment method — PayPal addresses are shown in full; bank account numbers are masked to the last four digits, with full details available only behind the confirmation link
- The disbursement reference to include in the payment memo, so reconciliation works both ways
- Approval provenance: who approved the bounty and when, and who initiated the payout
- A one-time confirmation link, valid for 90 days
The finance person opens the link, sees the full payment details, makes the payment through your payment provider, then enters the transaction reference and their name to confirm. Confirming completes the disbursement exactly like an internal Mark as Paid: the ledger entry is written, the report transitions to Paid, and the researcher is notified automatically. The confirmation records who confirmed (name and email), when, and from where (IP address) — visible on the disbursement row as Confirmed by finance.
A few details worth knowing:
- Replies reach a human. The email’s reply-to is the team member who initiated the payout, so finance questions land with someone who has context.
- Resend anytime. The disbursement row shows when and where the request was sent, with a resend button that issues a fresh link.
- The internal flow stays available. If finance replies “done, ref #123” by email instead of clicking, your team can still mark the disbursement paid manually — the link then shows an “already recorded” receipt.
- The link dies with the disbursement. Once completed or failed, the link can no longer confirm anything; it only shows the current state.
- Cancellations are announced. If a payment request was sent and the disbursement is later marked failed, Kit emails finance a “payment cancelled — do not pay” notice from the same branded sender — so nobody wires money for a payout you’ve called off.
Disbursement Statuses
| Status | Meaning |
|---|---|
| Pending | Bounty approved; waiting for the researcher to satisfy the readiness checklist |
| Processing | Your team has initiated the transfer outside Kit |
| Completed | Funds confirmed received; transaction reference recorded — the report closes as Paid as soon as its lifecycle allows |
| Failed | Transfer failed; resolve manually and retry or contact the researcher |
If a disbursement fails, the failure reason is logged in the ledger — and if finance had been sent a payment request, they automatically receive a cancellation email telling them not to pay. You can re-initiate the disbursement after resolving the issue.
Tax Documents
Researchers upload tax documents through their portal. US-based researchers submit a W-9; non-US researchers submit a W-8BEN. Documents are stored with encryption at rest.
Your team reviews uploaded documents in VDP > Tax Documents:
| Status | Action |
|---|---|
| Pending | Document uploaded, awaiting your review |
| Verified | You have confirmed the document is valid — the readiness item is satisfied |
| Rejected | You have rejected the document — the researcher is notified and can re-upload |
Both verification and rejection are recorded in the ledger for audit purposes. Tax document events are linked to the researcher’s most recent bounty-awarded report for ledger context.
The Ledger
Navigate to VDP > Ledger to view the immutable financial audit trail. The ledger is append-only: entries cannot be edited, modified, or deleted.
Each entry records:
- Entry type — What happened
- Amount — Dollar amount in cents and currency
- Actor — The team member or system that performed the action
- Timestamp — When the entry was created
- Report reference — The linked vulnerability report
Each entry records one of the following types:
| Entry Type | When It’s Created |
|---|---|
bounty_approved |
A team member approves a bounty amount for a report |
bounty_adjusted |
A team member corrects the bounty amount before payment is sent |
bounty_revoked |
A report with an approved bounty is dismissed; the revocation counts as a debit against ledger totals |
disbursement_initiated |
A team member moves the disbursement to Processing |
disbursement_completed |
A team member marks the disbursement as Paid with a transaction reference |
disbursement_failed |
A disbursement is marked as failed with a reason |
tax_document_submitted |
A researcher uploads a W-8BEN or W-9 document |
tax_document_verified |
A team member verifies a tax document as valid |
tax_document_rejected |
A team member rejects a tax document; the researcher is notified and can re-upload |
Filter the ledger by report ID, entry type, or date range to narrow down results. Use the ledger export in Metrics and Exports to generate SOC 2 evidence packages.
Ledger Integrity
A daily integrity check runs automatically to verify ledger consistency. It walks every entry in chronological order and tracks a running balance — credits (bounty_approved, bounty_adjusted) add, debits (disbursement_completed, bounty_revoked) subtract. If the running balance ever goes negative, the offending entry is flagged as a violation.
Any violation is reported to Kit’s error-monitoring system (APM) for the engineering team to investigate — it is not emailed to account admins. Contact support if you suspect a ledger discrepancy — do not attempt to resolve it manually.
Quick Checklist
- Configure bounty matrix tiers with appropriate min/max ranges for your risk tolerance
- Set payout readiness requirements (tax docs, agreement) in your program’s payout settings
- Set a finance email so payment requests reach the team that actually schedules payments
- Communicate bounty ranges on your disclosure policy page before researchers submit
- Check the Disbursements queue weekly for pending payouts
- Review and verify uploaded tax documents promptly to unblock researcher payments
- Export the ledger quarterly as SOC 2 evidence via Metrics and Exports
Next Steps
- Metrics and Exports — dashboard KPIs, SOC 2 evidence exports, and researcher karma
- The Researcher Portal — how researchers submit payout info and tax documents