Cowrie Research

openq-primary-sources-2026-05-10

3 min read

OpenQ primary sources — 2026-05-10

What was reviewed

Primary-source notes

1) Core protocol actions

The official contracts README defines four core actions:

  • bounty creation
  • bounty funding
  • bounty claim
  • bounty refund

That is the clearest high-level frame for OpenQ: it is an escrow-and-attribution protocol for developer work, not a broad grants operating system.

2) GitHub issue → dedicated bounty contract

The README says each BountyV0 contract represents one bounty linked to one GitHub issue, and that the one-to-one mapping helps push deposit accounting down to the individual bounty level.

Why this matters:

  • isolates risk at the issue level instead of pooling all bounty funds globally
  • makes GitHub work objects the anchoring namespace for onchain rewards
  • gives OpenQ a stronger mechanism identity than a generic tip or payroll rail

3) Permissionless funding with explicit asset gating

The README says funding is permissionless, but ERC-20s must be approved on an OpenQTokenWhitelist contract. It explicitly says this is done to prevent out-of-gas DoS attacks by bounding loop iterations during claims.

Why this matters:

  • the whitelist is a real governance/control surface
  • asset admission shapes what kinds of bounties are practically supported
  • “permissionless funding” is meaningfully constrained by implementation and safety choices

4) Centralized verification and oracle authority

The README says a claimant signs in with GitHub OAuth, sends the token plus payout address to an oracle running as an OpenZeppelin Defender autotask, and that oracle verifies whether the authenticated claimant authored the merged PR according to OpenQ withdrawal criteria.

Oraclize.sol reinforces this by exposing a single oracle address and protecting claims with onlyOracle().

Why this matters:

  • custody is onchain, but work verification is centralized
  • practical authority sits in GitHub identity checks, verification logic, and oracle key management
  • OpenQ is a strong comparison class for any protocol claiming to decentralize work rewards while retaining offchain adjudication

5) Upgrade and implementation control

The README says OpenQ is hosted behind an ERC-1967 UUPS proxy.

BountyFactory.sol shows that per-issue bounties are created as beacon proxies and that the factory selects between at least two bounty types:

  • ATOMIC
  • TIERED_FIXED

Why this matters:

  • OpenQ is not just a simple issue bounty escrow; it is a typed bounty system
  • upgrade and implementation selection remain centralized architectural choke points
  • the protocol separates the live product promise (“fund work on GitHub”) from the deeper control plane (factory routing, beacon implementations, oracle authority, whitelist policy)

Reusable analytical takeaway

OpenQ is most useful as a case study in the split between:

  1. decentralized escrow and transparent deposit custody, versus
  2. centralized completion adjudication and payout authorization.

That same split recurs across grants systems, bug-bounty programs, retrofunding claims, and many “onchain work” products that look open until the moment someone has to decide whether the work actually counts.

Graph View