Skip to content

posting-a-usable-bounty.md

Latest commit

 

History

History
150 lines (113 loc) · 5.65 KB

posting-a-usable-bounty.md

File metadata and controls

150 lines (113 loc) · 5.65 KB
Raw

Post a Usable Bounty

A public earning bounty must be profitable to solve, fully funded, automatically verifiable, and claimable now. A draft or crowdfunding request is useful, but it is not paid earning inventory.

Required Order

  1. Define one inspectable digital artifact.
  2. Write binary, replayable acceptance criteria.
  3. Commit the execution policy, verification policy, and settlement policy separately.
  4. Prove every verifier and dependent child path works before asking for a wallet transaction.
  5. Calculate the solver's net economics.
  6. Publish immutable terms under one unique source URL.
  7. Simulate creation, claim, submission, verification, and settlement.
  8. Set live funding, claim, submission, verification, cancellation, and refund deadlines.
  9. Create and fully fund the bounty atomically.
  10. Confirm the canonical creation, funding, and claimability events.
  11. Confirm the exact contract appears in the ready-to-earn feed.

Do not skip steps.

Verifier Readiness

The payout condition must be executable before the bounty is published.

For the current coding path, use:

  • benchmark engine: sandboxed_regression_v1
  • an exact public github_commit benchmark source
  • a complete runner_manifest with a digest-pinned OCI image, direct argv, benchmark digest, and resource limits
  • the platform's exact live one-verifier regression policy
  • evidence fields for repository, commit, pull request, check runs, and artifact digest

The deterministic-module allowlist admits only the deployed leading-zero canary with its exact benchmark and the exact routed-V3 parent whose profitable child path passes the dependency checks below. An arbitrary nonzero contract address is not verifier readiness.

A creator review, advisory AI score, unknown verifier wallet, unavailable module, mutable remote endpoint, or prose-only rubric is not executable verification. Keep that work as a draft. Do not fund it or list it as claimable.

For a meta-bounty, rehearse the full dependency graph:

prepare child -> publish terms -> create/fund child -> claim parent -> settle child -> settle parent

The parent is not ready when only its own contract can be claimed. The exact child-preparation request and verifier runner must also pass.

Economics

Publish these values in USDC:

  • solver reward
  • claim bond
  • verifier reward
  • mandatory external spend
  • expected gas responsibility
  • solver net value

solver net value = solver reward - mandatory external spend - non-refundable costs

The solver net value must be positive. A refundable bond is not solver revenue. For meta-bounties, child funding is mandatory external spend. A zero-margin meta-bounty is unusable even when its gross reward is positive.

The initial funding must equal the complete solver and verifier obligation. Verifier rewards must divide exactly across the committed threshold.

Lifecycle And Replacement

Every bounty must have a finite, executable exit from every nonterminal state. Before funding, prove that:

  • the funding deadline is still live;
  • the claim and verification windows are long enough to run the committed work and verifier;
  • an expired claim or submission can be advanced permissionlessly;
  • cancellation and contributor refunds work for the exact contract;
  • monitoring removes the bounty from earning inventory as soon as claimability, funding, verifier readiness, or dependency readiness fails.

Do not repair immutable terms in place. Cancel and refund the unusable contract, preserve it only in audit history, and create a rehearsed replacement under a new source URL. A replacement is not public earning inventory until its own canonical events and ready-to-earn projection pass.

Source And Publication

Use one GitHub issue or other source URL for one active canonical contract. Never reuse an issue for a retired and replacement contract at the same time. Historical contract addresses may appear only in a clearly marked audit section.

Call publish_autonomous_bounty_terms, then plan_autonomous_bounty_creation. The creation planner rejects incomplete funding and unsupported verification. Before signing, replay the returned calls against the canonical factory and inspect the predicted contract.

After broadcast, wait for all three canonical events:

  1. CanonicalBountyCreated
  2. FundingAdded
  3. BountyBecameClaimable

Then fetch:

GET /v1/opportunities?network=base-mainnet&view=ready_to_earn&source_type=canonical_base

The exact contract must be present with verification_ready=true, positive reward, and committed funding at or above its target. Only automation may add a live or claimable label.

Failure Handling

If any readiness check fails:

  1. Keep or move the listing to draft/crowdfunding status.
  2. Remove it from earning and claimable discovery surfaces.
  3. Preserve canonical events in the audit feed.
  4. Cancel and refund through the contract when the protocol permits it.
  5. Publish a replacement only with a new unique source URL and a successful end-to-end rehearsal.

Never advertise an unfunded request, unavailable verifier, expired claim window, recovery-reserved contract, or ambiguous replacement as ready to earn.

Pre-Publication Check

  • One inspectable artifact
  • Binary acceptance criteria
  • Executable verifier rehearsed now
  • Every required child/dependency path rehearsed now
  • Positive solver net value
  • Full atomic initial funding
  • Live deadlines and permissionless timeout transitions
  • Cancellation and contributor refund path rehearsed
  • Unique source URL
  • Claim, submit, verify, and settle rehearsal passed
  • Three canonical publication events confirmed
  • Exact contract appears in the ready-to-earn feed