## Why It Matters

Approving a bounty is irreversible. It emails the researcher, writes a permanent ledger entry, and sets an expectation you cannot quietly walk back. Yet on most programs the number itself is decided in the two seconds before someone clicks the button — and whatever discussion happened lives in a Slack thread that nobody will find in six months.

A **bounty proposal** is that number written down *before* it is money. Colleagues weigh in, disagreements are recorded with an alternative attached, and the amount stays amendable and reversible right up until an admin approves it. What you get afterwards is not just a payout — it is a record of who proposed what, who agreed, who objected, and at what number.

Bounty proposals require the **VDP Add-on**, like the rest of the bounty workflow.

## The Researcher Never Sees a Proposal

This is the promise the whole feature rests on, so it is worth stating plainly: **a proposal is internal, and nothing about it ever reaches the researcher.**

Proposing an amount, voting on it, objecting with a lower number, amending it, or withdrawing it entirely:

- Sends **no email** to the researcher
- Creates **no entry** in the researcher portal — no bounty card, no status change, no payout prompt
- Writes **no ledger entry** and moves **no money**
- Grants **no karma**
- Does **not** change the report's status

The researcher's view changes only when a bounty is *approved*. Until then you can argue about the number in the open, in front of your own team, without setting an expectation you might have to take back.

Proposals are also excluded from anything you share outside the team. A [report shared with a peer](/docs/sharing-reports-with-peers) carries no bounty information at all.

## Where Proposals Live

**The Bounty tab** on the report page is the deliberation surface. It appears only once the report carries a proposal or an approved bounty — teams that never propose see exactly the tab strip they see today. When people still owe a vote, the tab carries a count.

**Step 4 Bounty** in the right-hand guided rail carries a short summary: the proposed amount, an **Awaiting decision** badge, and a **Review & decide** link into the tab. The approve button is deliberately not in the rail — the decision belongs next to the evidence.

## Proposing an Amount

Any CSIRT member who can open the report can propose. This is not an admin action: putting a number on the table is exactly as routine as recording an assessment or sending a message.

From the rail's Bounty step, choose **Propose to the team first**, then enter:

| Field | Required | Description |
|-------|----------|-------------|
| Amount | Yes | What you think the bounty should be. Must fall within the report's bounty ceiling. |
| Rationale | No, but do it | Why this number. This is what colleagues read before voting, and what the record keeps afterwards. Cite the severity, the impact, the matrix band. |

Two constraints are worth knowing before you start:

- **A report holds one open proposal at a time.** Proposing again replaces the current one (see [Amending](#amending-and-adopting-a-counter-amount) below).
- **On a program running a bounty matrix, the report must be assessed first.** The proposal is capped by the matrix band for the report's severity tier, and an unassessed report has no resolvable ceiling. Kit refuses the proposal rather than letting you put up a number that could never be approved.

You cannot open a proposal on a report that is dismissed, already paid, or already carries an approved bounty.

## Voting Is Advisory

> [!IMPORTANT]
> **Agreement is not a gate.** There is no quorum, no threshold, and no vote count that unlocks anything. A CSIRT admin can approve the proposal with zero votes cast, with every vote against it, or with half the team still pending. Nothing about the tally blocks or authorizes the approval.

This is deliberate, and it is the opposite of how most approval workflows read. Voting exists to inform the person who has to decide and to leave a record of what the team thought — not to gather signatures. If you are waiting for the votes to "go green" before paying, you are waiting for something that will never happen.

The panel says as much to anyone who can approve: *Approval is never blocked by the vote — there is no quorum and no threshold.*

## Agreeing and Objecting

Two buttons: **Agree** and **Object**.

Agreeing takes no explanation. **Objecting requires a counter-amount** — you must say what you think the bounty should be, not merely that the proposal is wrong. You may add an optional reason as well.

That friction is the point. "Too high" ends a conversation and leaves the decider with nothing new; "$500, because the exploit needs an authenticated session" gives them a second number to weigh. It also makes the disagreement usable as data: Kit shows the counter-amounts on the distribution plot and computes their median, so a decider can see at a glance whether the room is clustered just below the proposal or scattered across the whole band.

Counter-amounts are held to the same ceiling as the proposal itself. You cannot object with a number that could never be approved.

Each person holds one vote. Voting again replaces your earlier position rather than adding a second one, and **Retract my vote** removes it entirely.

## Blind and Live Tallies

Kit ships **blind voting by default**. Which mode a program runs changes what you can see before you commit to a position.

| | Blind (default) | Live |
|---|---|---|
| Before you vote | Amount, proposer, rationale, the assessment's suggested range, and how many responses are sealed and how many people are still pending. **No stances, no names, no counter-amounts.** | Everything — the full tally, every voter's stance, and every counter-amount. |
| After you vote | Everything. | Everything. |

Blind is the default because it is the reversible direction. A team that finds it fussy flips one setting; a team that was quietly anchored by the first counter-amount on screen never finds out it happened. When someone senior objects at $500 and the number is visible, the next four votes are not independent opinions — they are echoes.

A few details that matter in practice:

- **Submitting an objection reveals the tally.** The objection form says so before you submit. Agreeing reveals it too.
- **Retracting your vote re-seals it.** You cannot peek and then withdraw to a position of ignorance while keeping the information, but you do go back to a sealed panel.
- **Program admins are exempt once anyone has voted.** Someone who can approve the bounty is reading the room to decide, not casting a vote that could be anchored — so they see the tally without voting. They are *not* exempt on an empty tally, so "nobody has voted yet" cannot be inferred from an admin's screen showing zeros.
- **The seal never hides how many people are pending.** The tab count and the panel both show how many colleagues still owe a vote, in either mode. That is a nudge, not a leak.
- **The seal holds everywhere.** The rail summary, the report timeline, the AI agent's responses and the exported PDF dossier all follow the same rule — a sealed tally is not readable by taking a different route to it.

### Changing the Mode

Vote visibility is a program-wide setting, not a per-proposal one. It lives on **Settings → Bounty Matrix**, below the severity tiers — the same screen where you set the amounts the votes are about. Pick **Blind** or **Live**, save the tab, and the choice sticks; later tier edits do not disturb it.

You can also change it by asking a connected AI assistant to reconfigure the program — *"set my VDP program's bounty vote visibility to live"* — which goes through the configuration tool described in [AI Integration](/docs/ai-integration-vdp).

The mode is read live, so it applies to proposals that are already open. Switching to live opens every current tally immediately, including proposals opened while the program was blind. Switching back to blind re-seals them for anyone who has not voted yet — though it obviously cannot unsee what somebody already read.

## Amending and Adopting a Counter-Amount

Anyone who can propose can **Amend** the open proposal to a different number. Kit does not open a second proposal and does not throw away what the team already said.

Instead, every vote cast against the old amount is marked **needs re-vote**. Those votes stay on the panel, showing what the person said and at which number — *"Agreed at $500 · now $1,500 · needs re-vote"*. Nothing is deleted. The people whose votes went stale are added back to the pending list so the panel asks them again.

When the tally is visible, each objection carries an **Adopt** button that amends the proposal straight to that counter-amount. Adopting makes you the proposer — the number on the table is now yours to defend. It stales every earlier vote, exactly as any other amendment does, and Kit confirms before it does so.

Two other endings:

- **Withdraw** closes the proposal without an award. The recorded votes are kept; the deliberation simply ends.
- **Proposing a fresh amount** while one is open marks the old one *superseded* rather than deleting it, and stales its votes.

Closed proposals stay on the Bounty tab with their outcome and their proposer, and each one appears in the report's timeline.

## Approving

Approving the proposal is the money action, so it carries the same admin gate as any other bounty approval — the same people who could always approve a bounty, and nobody new.

The button names the amount it will pay (**Approve $1,500**), and Kit confirms before it runs: *this emails the researcher, credits the ledger, and cannot be undone.* From there it is an ordinary [bounty approval](/docs/bounties-and-payouts) — ledger entry, researcher notification, karma, and the disbursement pipeline.

If someone amends the proposal between your loading the page and your clicking approve, Kit refuses the stale approval and tells you what the number is now, rather than paying an amount you never saw.

### The Direct Path Still Exists

> [!CAUTION]
> **Approving a bounty directly bypasses the deliberation entirely.** The **Approve Bounty** button on the report's bounty card and on the triage banner is unchanged by this feature, and it stays available while a proposal is open. Using it approves the amount you type — not the amount on the table — and silently marks the open proposal superseded, votes and all.

Nothing prevents this, and for a clear-cut $100 low-severity report, skipping the deliberation is the right call. But it does mean **proposals are a convention your team keeps, not a control Kit enforces.** If you want every bounty to go through the team, that has to be a rule people follow, not a setting you switch on. The same is true of your AI assistant: the direct approval tool remains available to it and does not consult proposals.

## Using an AI Assistant

Two tools cover the deliberation, and both are member-level — any CSIRT member's assistant can use them.

| Tool | What it does |
|------|--------------|
| `csirt_propose_bounty` | Puts an amount on the table with a rationale. Approves and pays nothing. |
| `csirt_vote_bounty_proposal` | Records the user's own agreement or objection. An objection must carry a counter-amount. |

Both respect the blind-mode seal. The response returns the proposal only as the acting user is allowed to see it, so an assistant working on a blind program before its user has voted cannot report how colleagues voted — it does not have that information.

**There is deliberately no tool for accepting a proposal.** Accepting one *is* approving a bounty, and that already has an agent-reachable door in `csirt_approve_bounty` — admin-gated and flagged as irreversible. A second one would add risk and no capability. Acceptance happens on the report's Bounty tab, by a person.

See the [MCP Tools Reference](/docs/mcp-tools-reference) for parameters.

## Quick Checklist

- [ ] Decide whether your program uses proposals routinely, for amounts above a threshold, or only for contested reports — Kit will not enforce it for you
- [ ] Assess the report before proposing, so the matrix ceiling can be resolved
- [ ] Write a real rationale — it is what colleagues vote on and what the record keeps
- [ ] Object with a number, not a complaint; the counter-amount is what makes the objection usable
- [ ] Leave blind voting on unless you have a specific reason to anchor the room deliberately
- [ ] Set the mode once, on Settings → Bounty Matrix — it is program-wide and applies to proposals that are already open
- [ ] Do not wait for the votes to reach agreement — nothing unlocks, and an admin still has to approve
- [ ] Re-check the panel after an amendment: stale votes mean the team has not weighed in on the current number

## Next Steps

- [Bounties and Payouts](/docs/bounties-and-payouts) — approval, the disbursement pipeline, tax documents, and the financial ledger
- [Triaging Reports](/docs/triaging-reports) — the board, SLA indicators, and severity assessment
- [Configuring Your Program](/docs/configuring-your-program) — bounty matrix tiers and the rest of the program settings