Skip to main content

​
Bounty lifecycle and settlement

A bounty is a workflow with economic consequences. Applications should model the lifecycle explicitly so users can distinguish a proposal, a funded task, a claim, a submission, an approval and an actual settlement.

​
Creation

bounty.create is a funded action for Author, Journalist or Editor roles with an active bond. Creation should establish a clear target, expected work product, funding amount, review path and expiration policy before the user authorizes the action. If the bounty concerns a Capsule, challenge or evidence gap, store that relationship directly instead of relying on a free-form description that a settlement process cannot verify.

​
Claim

bounty.claim is a micro-fee action for eligible Author, Journalist, Editor and Validator roles. A successful claim establishes the current assignee. Read current state immediately before authorization. Two users can view an open bounty at the same time, and one may claim it before the other transaction executes. Treat that as a normal race in shared state.

​
Submission

bounty.submit is limited to the current assignee and requires an active bond. The submission should reference a verifiable work product whenever possible. For evidence work, prefer a durable URI plus content hash. For review work, preserve the exact Capsule, claim or evidence item being reviewed. This gives the approval path something concrete to inspect.

​
Approval

Approval is available to Editor or Validator roles when the actor also satisfies the creator, designated reviewer or protocol authority relationship defined by active policy. Role alone is not universal approval power.

​
Settlement

Settlement is an authorized escrow or treasury operation. Before value moves, the settlement path should re-check:
  • bounty is in an approvable state
  • assignee is still the intended recipient
  • required role is still active
  • active bond requirement is still satisfied
  • treasury safety policy passes
  • the bounty was not already paid
  • the settlement identifier was not already processed
This protects the system from stale eligibility and duplicate payment.

​
Expiration and rejection

A robust application also represents terminal and recovery states such as expiration, rejected submission, returned-for-changes, funding cancellation where policy allows it and policy-blocked settlement. Do not collapse every non-success result into “failed.” Users need to know whether they can resubmit, whether the task expired or whether an administrator must resolve an operational problem.

​
Audit trail

Every transition should preserve actor, state, policy version and transaction or engine record where applicable.
The production schema may use different field names. Preserve these concepts so financial activity can be reconstructed later.

​
Settlement UX

Before approval or settlement, show the exact work product, claimant, funded amount and expected recipient. Economic interfaces should make value movement legible before a signature or privileged action occurs. That is especially important when automated bounty creation is involved. Automation can create work, but the final human and financial trail should remain understandable.