Summary: OpenQ is best understood not as a generic freelance marketplace, but as a protocol for binding a GitHub issue to a dedicated onchain bounty contract, then letting third parties permissionlessly fund that work while an offchain oracle decides when a merged pull request satisfies payout conditions. Its reusable mechanism is the split between transparent onchain deposit custody and a much more centralized claim-verification layer built around GitHub OAuth, withdrawal-eligibility logic, and an authorized oracle key. That makes it a useful comparison class for grants systems, bounty markets, and developer-incentive tools where the hard problem is not escrow itself but who gets to attest that work was actually completed.
What it does:
Lets users create bounties tied to specific GitHub issues
Deploys a separate bounty contract per issue rather than pooling all deposits in one global contract
Allows permissionless funding of bounties with native tokens, approved ERC-20s, and NFTs
Uses timelocked deposits that can later be refunded by the original funder after expiration
Routes claims through an oracle flow that checks GitHub-authenticated pull-request completion before releasing funds
Supports multiple bounty shapes through factory-routed beacon proxies, including atomic and tiered-fixed bounty variants
Key claims:
The contracts README frames OpenQ around four core actions — bounty creation, funding, claim, and refund — which is a clean indication that the protocol’s real primitive is escrowed work attribution rather than general DAO grants administration
OpenQ’s strongest mechanism choice is the one-to-one link between a GitHub issue and a dedicated bounty contract, because it isolates risk per issue and turns offchain developer work objects into first-class onchain escrow containers
Funding is permissionless, but not fully open-ended: the contracts README says ERC-20s must be approved on a token-whitelist contract, explicitly to bound claim-loop iterations and prevent out-of-gas DoS attacks. That means asset admission is a genuine control surface, not a minor implementation detail
Claiming is intentionally centralized relative to funding. The README says users authenticate with GitHub OAuth, send a signed token to an OpenZeppelin Defender autotask, and only the authorized oracle can call claimBounty; the separate Oraclize.sol contract confirms this with an onlyOracle gate
The README also says OpenQ keeps the main contract behind an ERC-1967 UUPS proxy while the factory deploys bounty contracts as beacon proxies, which means upgrade and implementation selection sit above individual bounty instances even though deposits are distributed across them
BountyFactory.sol is especially useful because it shows OpenQ is not only “one bounty = one contract”; it is also a typed bounty system whose factory chooses between ATOMIC and TIERED_FIXED beacon implementations, revealing a deeper protocol ambition than a simple issue-tip jar
The public product surface currently appears dormant: openq.dev returned a paused deployment during this pass, so the lasting analytical value is mainly the protocol design itself and its escrow-versus-verification split, not the current live app status
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official contracts repository, raw contract sources, and the currently paused official site; see ../whitepapers/openq-primary-sources-2026-05-10.md.