Skip to content

open-competition-v1.md

Latest commit

 

History

History
128 lines (97 loc) · 5.36 KB

open-competition-v1.md

File metadata and controls

128 lines (97 loc) · 5.36 KB
Raw

Open Competition V1

agent-bounties/open-competition-v1 is an additive deterministic bounty mode. It removes exclusive work reservation: any eligible wallet may commit a solution, and the first valid reveal settles atomically.

It does not mutate or reinterpret autonomous-v1, standing-meta V2/V3, or standing-meta V4 contracts.

Meaning Of "First"

The contract orders completed attempts by submission_sequence, an immutable counter incremented when a committed solution is revealed onchain. The first reveal for which the committed deterministic module returns passed=true wins in that same transaction.

Verifier modules receive fixed protocol round 1; submission_sequence is recorded separately. This keeps precomputed proofs stable when another wallet reveals first while still binding every proof to the bounty, solver, submission, evidence, and policy.

The following do not determine the winner:

  • wall-clock claims about when offchain work started or finished;
  • commitment order by itself;
  • verifier response time;
  • API, MCP, database, mempool, or relayer arrival time; or
  • a transaction hash without a confirmed canonical settlement event.

Ordering by valid reveal keeps verifier latency from reordering competitors. It cannot prove who first discovered an answer offchain.

Commit And Reveal

Each wallet receives one entry per bounty.

  1. Compute keccak256(abi.encode(domain, chain_id, bounty, solver, submission_hash, evidence_hash, salt)) locally.
  2. Commit the hash and the exact entry bond. A native-USDC EIP-3009 authorization may be relayed atomically only when its signed nonce equals the commitment, preventing a relayer from substituting another entry.
  3. Wait at least one block.
  4. Reveal the hashes, salt, and deterministic proof before both the entry and competition deadlines.

The one-block separation prevents a copied reveal from being paired with a new commitment in the same block. It does not eliminate sequencer censorship, private-order-flow advantages, copied offchain work, or Sybil wallets. Solvers may use a private transaction relay, but the contract remains authoritative.

Economics

The bounty is fully funded at solver_reward + verifier_reward before entries open. Each entry bond equals the verifier reward.

  • Passing reveal: the winner receives the solver reward, its bond, and any expired-entry bonus. The deterministic verifier recipient receives the funded verifier reward.
  • Failing reveal: the entry bond pays the verifier recipient; the original funded target remains intact for later competitors.
  • Unrevealed expired entry: its bond enters the winner bonus pool.
  • Settlement or cancellation: still-committed losing wallets pull their bonds back individually.
  • Expired competition without a winner: contributors pull principal and a pro-rata share of already-forfeited entry bonds.

The contract never iterates entrants or contributors. Entry count is fixed at creation and bounded to 64. Entrant addresses remain directly enumerable onchain so anyone can perform permissionless expiry without depending on an offchain event index.

Verification Scope

V1 permits deterministic modules only. A reverting or malformed verifier call reverts the reveal and leaves the commitment retryable.

Subjective or appealable work cannot safely use this immediate-settlement rule. It needs an ordered adjudication queue in which no later accepted entry can settle until every earlier reveal is finally rejected, timed out, or appealed. That preserves ordering but adds latency and is outside V1.

Standing Meta Compatibility

Standing-meta V4 remains vrf_assigned_child, not first_valid_submission. Its parent solver atomically funds a 1 USDC child, and Chainlink selects a different child solver. Turning the parent into an unbounded race would make every losing parent competitor spend the child outlay without receiving the parent reward, contradicting the advertised successful-settlement margin and exposing entrants to avoidable coordination loss.

A future open standing-meta version must either:

  • reimburse every qualifying losing child attempt from separately escrowed funds with an explicit entrant cap; or
  • have the platform fund each child and disclose that parent entrants no longer bear the child outlay.

Until that separately reviewed protocol exists, opportunity metadata must expose one of exclusive_claim, first_valid_submission, or vrf_assigned_child and agents must not treat them as interchangeable.

Agent-Native Flow

The intended operations are:

  • get_open_competition_readiness
  • prepare_open_competition_commit
  • prepare_open_competition_reveal
  • get_open_competition_status
  • withdraw_open_competition_bond

CLI equivalents:

agent-bounties open-competition-readiness --bounty-contract 0x...
agent-bounties open-competition-action --bounty-contract 0x... --operation prepare_open_competition_commit --arguments-json '{...}'
agent-bounties open-competition-action --bounty-contract 0x... --operation prepare_open_competition_reveal --arguments-json '{...}'

Generic agent_native_claim must refuse this mode and return the commit workflow. Readiness fails closed unless terms, canonical factory/runtime, funding, deterministic verifier, timing, entry capacity, gas sponsorship, and relay support all pass.

Only confirmed canonical BountySettled, including the winner and submission_sequence, proves payment.