1. Why bounties beat “who wants to help?”
Volunteer calls get one-time responses. A member helps once, feels good, and goes back to lurking — because there was no record, no reward, no follow-up. A bounty turns the same request into a public, priced, stateful contract: title, reward, owner, status, and history that anyone in the server can see.
The pricing is the point. A 20-euro bounty on a documentation task signals that the work has real value. Members who would never volunteer respond to priced work, because priced work removes the ambiguity about whether their effort will be acknowledged.
2. The lifecycle: four commands, five states
Sovereign implements bounties as a strict state machine: OPEN → IN_PROGRESS → REVIEW → PAID, with an explicit CLOSED path for abandoned posts. Anyone with a linked identity can create a bounty with /bounty create <Title> | <Amount> (minimum 5 EUR, stored in cents), browse open ones with /bounty list, take one with /bounty claim <ID>, and submit finished work with /bounty done <ID>.
The state machine does the moderation work for you. A bounty cannot be claimed twice, the creator cannot claim their own post, and only the assigned worker can submit. Each transition notifies the right person: the creator is DM’d when their bounty is claimed and again when work is submitted, and the submission lands in the Dashboard Exchange for approval.
Funds are released only after explicit approval in the Dashboard. That keeps the loop human where it matters — trust — and automated everywhere else.
// Command routing and the guard clauses that make the state machine safe
switch (action) {
case 'create': return await createBounty(tenantId, member.id, args); // -> OPEN
case 'list': return { reply: await listBounties(tenantId) }; // 5 latest OPEN
case 'claim': return await claimBounty(tenantId, member.id, args); // OPEN -> IN_PROGRESS
case 'done': return await completeBounty(tenantId, member.id, args); // IN_PROGRESS -> REVIEW
}
// Guards enforced inside the transition functions:
// - status must match the expected state or the command is rejected
// - creatorId !== workerId (no self-claims)
// - only the assigned workerId may call /bounty done
// Funds are released after owner approval: Dashboard > Exchange (REVIEW -> PAID)3. Tuning bounties so they build retention, not just output
Bounties that work are small, specific, and winnable in one evening. A community that posts three or more fresh bounties a week gives members a constant reason to check the server: open work is a regularly refreshed reason to come back, which is exactly the behavior retention engineers are trying to manufacture.
The compounding play is to post bounties for things that make the community better to run: onboarding scripts, documentation, clip-making, moderation coverage, event logistics. Each completed bounty is a permanent asset, not a one-off deliverable.
The minimum filters out noise. A bounty under 5 EUR is not worth the state-machine overhead or the attention it steals from real work. The price floor, like the REVIEW gate, is fraud and spam control dressed up as a product rule.