- Native USDC is held by one immutable bounty contract.
- The immutable deterministic module decides whether one reveal passes.
- Base transaction ordering determines reveal sequence.
- The factory establishes canonical contract identity.
- No owner, API, relayer, sequencer, verifier recipient, or platform key can choose a winner outside the committed module.
- Only confirmed canonical
BountySettledproves payment.
Untrusted inputs include terms, commitments, reveals, proofs, ERC-20 return values, EIP-3009 authorizations, RPC observations, transaction ordering, and all offchain evidence stores. The settlement token, factory runtime, bounty implementation, verifier module, and terms hashes must be pinned before a bounty is advertised as ready.
| Threat | Control | Residual risk |
|---|---|---|
| Copying a public solution | salted commitment plus one-block reveal delay | leaked salts, copied offchain work, private order flow |
| Mempool or sequencer reordering | winner is explicit onchain reveal sequence; optional private relay | censorship and ordering advantages remain |
| Verifier latency reorders winners | verification occurs atomically inside each reveal | only deterministic, bounded verification is supported |
| Invalid-entry spam | one entry per wallet, fixed bond, maximum 64 entries | wallets do not prove distinct owners; Sybil capital can consume capacity |
| Commitment squatting | commitments do not reserve payout; entrants are enumerable and unrevealed entries can be permissionlessly expired for bond forfeiture | capacity can remain occupied until deadline |
| Failed proof drains funded reward | failed entry bond pays the verifier; funded target remains intact | malicious verifier recipient can still be an economically poor policy |
| Reverting module locks entry | reveal reverts without consuming the commitment; retry remains possible | permanently broken modules make the bounty unready and eventually refundable |
| Pending bonds trapped after terminal state | individual pull withdrawal after settlement/cancellation | wallet must submit the withdrawal transaction |
| Unbounded payout/refund loops | pull payments and bounded scalar accounting | gas cost remains for each claimant |
| Reentrancy or false token return | non-reentrant state transitions and checked low-level token calls | nonstandard rebasing/fee tokens are unsupported; deployments pin native USDC |
| False payment claims | canonical settlement event and safe-block confirmation | RPC/indexer compromise must be caught by independent chain validation |
| Keeper mutates an entrant action | EIP-712 signature binds wallet, action, payload hash, shared nonce, short deadline, and policy version; action-time simulation and safe-block receipt reconciliation | a keeper can censor or delay, and Base ordering still applies |
| Keeper or delegate drains the entrant account | delegate has only commit, reveal, and bond-withdraw actions; no arbitrary call, recipient choice, reimbursement, or withdrawal; gas is paid by the keeper | the wallet owner retains custody and can withdraw assets or revoke/rotate policy |
| Creator takes control after commitment | creator-address exclusion is rechecked at reveal after any owner/delegate rotation | an unrelated address does not prove an unrelated beneficial owner |
| Stale or substituted verifier profile | wallet pins verifier address, runtime hash, policy, criteria, benchmark, and evidence schema; planner and relay re-read them at a safe block | a reviewed deterministic verifier can still implement a poor predicate |
| Commitment secret leaks through sponsorship | commit plans and relay envelopes carry only the commitment; reveal material is supplied only at reveal time | the local recovery envelope, delegate host, or reveal transport can still leak secrets |
- A wallet is a protocol account, not a person or organization.
- Different wallets do not prove unrelated ownership.
- Commit order does not prove when a solution was discovered.
- First valid reveal does not prove best solution quality beyond the committed deterministic predicate.
- Commit/reveal does not make Base ordering censorship-resistant.
- A transaction hash, reveal event, API response, or verifier output alone is not payment evidence.
- A factory-created entrant account proves one protocol account, not one independent agent, human, or organization.
- Creator-address exclusion does not detect common control through unrelated wallets, contract owners, delegates, custodians, or private keys.
The first deployment is capped to native Base USDC, at most 64 entries, one entry per wallet, and a low-value canary. Hosted earning inventory must be suppressed immediately on runtime-hash mismatch, stale RPC state, broken module, exhausted capacity, elapsed deadline, or missing gas sponsorship.
Mainnet activation requires the repository R4 gates: Foundry unit/fuzz/ invariant tests, static analysis, independent contract review, full Base Sepolia rehearsal, exact mainnet-fork replay, exact bytecode/configuration evidence, bounded-wallet policy review, and action-time signing approval.
The entrant wallet and entrant factory are a separate release boundary from the already deployed bounty factory. Their deployment, relay, and gas gates remain false until their own bytecode is frozen, reviewed, rehearsed, replayed, and reconciled. Earlier bounty-factory canary evidence cannot be reused as entrant-wallet evidence.