Skip to main content

​
Bounties

Bounties turn unresolved verification work into explicit, funded tasks. Instead of leaving an important gap in a newsroom queue or private message thread, a PressChain workflow can record why work is needed, who is eligible to perform it, what result is expected and how settlement will be authorized. The bounty engine is intentionally separate from the public application layer. It owns policy evaluation, duplicate prevention, budget controls, eligibility checks, lifecycle decisions and auditable settlement logic. Public clients can explain those results without duplicating sensitive anti-abuse rules.

​
Economic model

bounty.create is a funded action. Under current V3 policy, an Author, Journalist or Editor with an active bond can create a bounty when the required value is supplied. Claim, submit, approve and settle are separate lifecycle steps with their own authorization checks. That separation matters. Funding a task does not make it complete, and approving a submission does not mean funds moved until the settlement path executes successfully.

​
Typical lifecycle

Applications should preserve each state instead of compressing the entire process into open and paid.

​
Eligibility

Current V3 policy allows Author, Journalist, Editor and Validator roles to claim bounties, subject to active bond requirements and any bounty-specific restrictions. bounty.submit is limited to the current assignee. Approval requires Editor or Validator role plus the required creator, designated reviewer or protocol authority relationship. Eligibility must be checked again at settlement. A bounty can stay open long enough for a role, bond or permission relationship to change.

​
Budget controls

Automatic and manual bounty paths must respect treasury floors, per-bounty limits, automatic-bounty budget limits and maximum active bounty counts. Those constraints are protocol safety controls, not client suggestions. A UI should report a policy rejection accurately. If treasury policy prevents funding, say so. Retrying around a deliberate safety rule is not a valid recovery strategy.

​
Deterministic identity

The bounty engine is designed around deterministic idempotency. The same triggering condition should not create two equivalent payouts simply because an event was replayed or a worker restarted. A conceptual application key might include network, Capsule, trigger class and policy version:
Use the actual engine identity scheme in production. The important property is stable identity for one logical proposal.

​
Example: missing primary evidence

A Capsule is published and remains without the expected evidence profile after the applicable observation period. The engine evaluates the condition, checks for an equivalent active bounty, applies treasury policy and creates or stores a proposal. A qualified Journalist claims the task and attaches the requested source record. An eligible reviewer approves the work. Settlement then revalidates role, bond and treasury state before value moves. That workflow turns “someone should verify this” into a traceable state machine.

​
Public state versus private policy

The bounty engine contains operational and anti-abuse logic that should not all be reconstructed in a browser. Public documentation can describe lifecycle, eligibility and published trigger classes without exposing private thresholds or evasion-sensitive controls. Clients should consume the engine result, preserve the relevant policy version and link the result back to the Capsule or protocol state that caused the work to exist.