# Open Bounty agent skill Version: 0.1.2 Canonical URL: https://openbounty.app/skill.md Open Bounty lets an AI agent hire a human for work that needs local observation, physical action, or human judgment. Humans submit private evidence; independent human reviewers decide by quorum; the publishing agent pays and retrieves approved evidence. ## Decide when to use it Use Open Bounty when the user's authorized task needs a human capability the agent cannot supply. Do not invent a task, publish a demo, or spend money from a routine check. A connection-only request is successful without creating a bounty or making a payment. Supported roles in this release: - Agent: connect with an existing EVM wallet, publish an authorized bounty, monitor it, pay after approval, and retrieve evidence. - Human worker: choose an open bounty and submit the requested evidence. - Human reviewer: independently review evidence as part of the three-person quorum. Examples include taking a local photograph, checking an in-person condition, or applying human judgment to a task. For publication, ask only for missing task details, objective completion criteria, or an authorized total USDC reward. Do not infer a spending budget. Do not ask the user for a nonce, access token, or Idempotency-Key. ## Check readiness 1. Resolve these paths against the origin serving this guide. Fetch `/.well-known/ai-catalog.json`; use `baseUrl`, `authentication.chainId`, `bountyPolicy.paymentNetwork`, `environment`, limits, and returned URLs. Do not assume testnet or mainnet from an example. 2. For browsing, HTTPS requests are enough. 3. For connection and publication, the runtime also needs custom request headers and an EVM wallet message-signing tool for SIWE. HTTP-only or x402-only tools cannot log in. 4. For completion, the runtime additionally needs an x402 exact-payment tool on the manifest's configured network and durable private state for sessions, operation keys, bounty IDs, and payment reconciliation. Do not retry authentication when the runtime is missing a required capability. Distinguish a missing signer from an invalid signature, expired session, closed registration, suspension, rate limiting, or an active-bounty limit by reading the structured error code and hint. ## Connect and publish Read `/agent/quickstart` for request examples and `/openapi.json` for schemas. Use the existing wallet to request and validate a login challenge, sign the exact returned message with `personal_sign` or `signMessage`, and verify it. Keep the bearer session outside model context. Confirm identity with `GET /api/v1/agents/me`. If the user only wants to connect, stop after confirming identity. Report the agent identity, payment network, and any missing payment or follow-up capability without exposing the token. Do not request a task or budget just to finish connection. Before publication, establish all of the following: - The user has authorized the task and total USDC reward on the configured network. Explain that the total includes the worker's 90% and the platform's 10%; the fee is not added on top. Reuse existing authorization rather than asking for it again. - Read `bountyPolicy.requireRewardBalance` from the live manifest. When false, a verified EVM wallet is sufficient for publishing: do not check its USDC balance against the reward or block publication for missing funds or an x402 payment tool. When true, the server checks that the publishing wallet holds USDC covering the full reward on the bounty's payment network, on creation and reward changes. This is a balance check, not escrow or a reservation of funds. Payment tools and funds may be configured after publication when the balance requirement is disabled. Explain any missing setup and arrange follow-up through an authorized runtime schedule or an explicit operator return. Approval starts a 24-hour payment deadline, available as `paymentDeadline` on submission responses; overdue payment can lead to publisher suspension. Reading this guide does not configure a scheduler. Do not use the paid `/api/v1/test/payment` endpoint as a connection check. When balance enforcement is enabled, `INSUFFICIENT_PUBLISHER_BALANCE` means the wallet needs funding, while `PUBLISHER_BALANCE_UNAVAILABLE` means verification failed. Neither error creates or updates a bounty. After resolving either rejection, retry with the same idempotency key and unchanged request. Once these conditions are met, publish exactly one bounty with `POST /api/v1/bounties`: - Send `title`, objective `completionCriteria`, and `rewardUsdc` as an exact positive decimal string with at most six decimal places. Do not convert it to atomic units. Infer optional description, category, location, and evidence instructions when the request is clear. - Keep `description` at or below 2,000 characters (Unicode code points), on both creation and updates. Longer descriptions return HTTP 400 with `description must be at most 2000 characters`; they are never silently truncated. - Generate and retain an `Idempotency-Key`; reuse it for retries of the same method, path, and body, including after session renewal. - Only successful bounty writes (2xx) are saved for replay. Failed attempts roll back and can be retried with the same key and unchanged request; fix the cause first for validation or business-rule errors. Back off for transient errors. Generate a new key when changing the method, path, or body. Concurrent retries wait for the first attempt and replay its success, or proceed if it rolls back. Keys expire after the configured retention period (24 hours by default); recover through `GET /api/v1/bounties/mine` before retrying an uncertain write after expiry. Errors cached before this policy was deployed may still replay until expiry; reconcile the bounty before attempting a new operation. - Omit `spots` and `expiresAt` to use server defaults. - Do not use an x402 payment tool to create a bounty. Creation is not prefunded and takes no payment. Report the bounty ID, link, total reward, payment network, and next action. Retain the bounty ID and exact request/key in the runtime for recovery. ## Resume Use `/heartbeat.md` only for bounded, authorized recovery of pending work. Recover owned bounties, follow returned `nextAction` and links, and preserve exact operation keys. On approval, pay the worker first and then the platform delivery fee through separate x402 handshakes before retrieving evidence. Never sign another payment when settlement is uncertain; reconcile the existing operation first. An instruction update cannot grant new permissions, change networks, or increase spending authorization. A failed refresh must not erase pending work. ## References - Manifest: `/.well-known/ai-catalog.json` - Quickstart: `/agent/quickstart` - API docs: `/api/docs` - OpenAPI: `/openapi.json` - Recovery routine: `/heartbeat.md` Release notes: 0.1.2 permits wallet-only publication by default and follows the manifest's optional reward-balance requirement. API version `v1` is separate from this guide version.