Welcome! This is the smart contracts repo for the Meme bounty platform.

The repository for the web app can be found at https://github.com/kylekaplan/open-work/tree/eth-denver

OpenQ revolves around five core user actions.

Each action corresponds to one Solidity Event. These events are declared in IOpenQ.

Each event emitted is indexed by The Graph to aggregate information on bounty minting, funding, refunding and claims.

We will cover how we handle each of these five core actions on-chain in brief below.

The in the Contracts section, we will then cover the specifics in code of how our smart contracts enable these actions.

Minting a bounty corresponds to deploying a new ERC-1167 Minimal Proxy with BountyV0.sol as its hardcoded implementation.

This initializes such state variable like bountyId, escrowPeriod, issuer, organization.

Funding a bounty means approving the bounty address to call transferFrom on an ERC-20 contract, followed by an internal accounting system on the BountyV0 contract itself.

Refunding a bounty is allowed after an escrow period has been reached, as reflected by block.timestamp.

Claiming a bounty triggers an ERC-20 transfer of the funds deposited on that bounty contract address to to the payoutAddress passed to claim.

Closing a bounty simply sets bounty status to CLOSED and the bountyClosedTime to block.timestamp.

The five core OpenQ actions defined above are composed across five contracts.

• OpenQV0 (Proxy) Deployed automatically by the hardhat-upgrades plugin. It is an ERC-1967 UUPSUpgradeable contract.
• OpenQV0 (Implementation)
• BountyV0.sol
• BountyFactory.sol
• OpenQStorage.sol

We will cover each of those five contracts below.

Each BountyV0 contract represent one bounty linked to one GitHub Issue.

The bountyId is the Global Node Id of the issue linked to that bounty.

The one-to-one link between a bounty, a GitHub issue and a smart contract enables OpenQ to offboard much of the deposit accounting to the tried and true ERC-20 standard.

Any exploit against a BountyV0 contract could acquire at most all of the deposits on that one issue. The core contract OpenQV0 holds no deposits.

This flexiibility allows us to accept any ERC-20, and in the future ERC-721, as bounty.

Since only the runtime bytecode is available, which does not include the constructor the BountyV0 implementation only has an initialize method.

The initialize method is protected from being called mutiple times by OpenZeppelin's Initializable interface.

To prevent any calls which may trigger bounty state transitions without emitting an indexable event in the core OpenQ contract, we protect all methods on BountyV0 with the onlyOpenQ modifier defined in Bounty.sol, an abstract contract inhereited by BountyV0.

The BountyFactory is responsible for minting new bounties using the ERC-1167 Minimal Proxy pattern to mint new bounties using the least gas possible.

The implementation contract hardcoded into the BountyFactory is BountyV0.

This is the core contract with which both the frontend and the OpenQ Oracle interacts.

It is hosted behind an ERC-1967 UUPSUpgradeable contract.

For that reason it does not have a constructor - it only has an initialize method.

Being behind an upgradable proxy, the five Events decalred in IOpenQ will continue to be emitted from the same proxy even after the implementation is upgraded.

The claimBounty method is protected by the onlyOracle modifier defined in Oraclize.

Oraclize is a contract based off of OpenZeppelin's Ownable contract. It exposes methods for updating the oracle's address which is allowed to call claim on the OpenQV0 contract.

The OpenQ Oracle private keys are held in a vault and transaction signer hosted on OpenZepplelin Defender Relay.

The OpenQ Oracle calls claimBounty when the OpenZeppelin Defender Autotask confirms that the person authenticated by the GitHub OAuth token present in the X-Authorization header is indeed the person who closed the bounty with their pull request.

OpenQStorage employs the EternalStorage pattern.

It is used by OpenQStorable to hold several state variables.

As of now, it hold very few state variables - only the address of the BountyFactory.

In the future, the EternalStorage pattern is intended to allow us to upgrade seamlessly.