OpenQ

• Name: OpenQ
• URL: https://openq.dev/
• Category: GitHub-linked bounty escrow / developer work-verification middleware / onchain payout rail
• Tags: ethereum-ecosystem
• Summary: OpenQ is issue-level bounty escrow with offchain adjudication attached. The useful split is simple: deposits sit in per-issue contracts, but payout authority sits with GitHub OAuth checks, token-whitelist policy, oracle logic, and upgrade keys. That makes it a decent note for “pay work onchain, judge it offchain,” not a category anchor for grants tooling.
• What it does:
  • Binds a GitHub issue to its own bounty contract instead of pooling deposits in one global vault
  • Lets third parties fund bounties with native assets, approved ERC-20s, and NFTs
  • Uses timelocked deposits that can be refunded by the original funder after expiry
  • Routes claims through a GitHub-authenticated oracle flow before funds are released
  • Supports multiple bounty types through factory-selected beacon implementations, including ATOMIC and TIERED_FIXED
• Key claims:
  • The contracts README reduces OpenQ to four actions — create, fund, claim, refund — which is the right frame: this is escrowed work attribution, not a full grants operating system
  • The one-issue / one-contract design is the main architectural choice because it isolates risk per task and makes GitHub work objects the namespace for onchain rewards
  • Funding is only partly permissionless: ERC-20 admission runs through a whitelist contract, so asset policy is a real control surface rather than backend housekeeping
  • Completion adjudication is centralized. GitHub OAuth plus an authorized oracle decide whether a merged PR counts, and Oraclize.sol makes that power explicit with an onlyOracle gate
  • OpenQ keeps meaningful control above the per-issue contracts: the main system sits behind an ERC-1967 UUPS proxy, while the factory chooses beacon-backed bounty implementations
  • The live site was paused during the source pass, so the enduring value of the note is the custody-versus-adjudication split, not current product traction
• 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.
• Sources:
  • https://openq.dev/
  • https://github.com/OpenQDev/OpenQ-Contracts
  • https://raw.githubusercontent.com/OpenQDev/OpenQ-Contracts/production/README.md
  • https://raw.githubusercontent.com/OpenQDev/OpenQ-Contracts/production/contracts/Oracle/Oraclize.sol
  • https://raw.githubusercontent.com/OpenQDev/OpenQ-Contracts/production/contracts/BountyFactory/BountyFactory.sol

Internal linkages

• Best upward reads: gitcoin-grants-stack for thicker operator workflow, dework for hosted contributor intake, and questbook for review-heavy grant operations.

Control surface

• Practical authority sits in oracle-key custody, GitHub-auth criteria, token-whitelist admission, and proxy / beacon implementation control.

• Treat OpenQ as a narrow escrow-plus-adjudication tool, not a full grants operating system.

• Last reviewed: 2026-06-12 UTC