Octobay - Chainlink Hackathon 2021

The first quarter of 2021 saw the completion of another Chainlink Hackathon. This one seemed a lot more successful than the previous one, for both me and Chainlink itself. For me - I got to work on a really great project (which won prizes!), for Chainlink - they had over 150 submissions, which seemed like one of the biggest in the Blockchain Hackathon space.

Before the commencement of the Hackathon I was in discussions with a few potential teams to join, there were a lot of great ideas going around from NFTs for D&D characters to finance and staking projects. I ended up joining a project called Octobay.

Oh also, I blatantly stole the banner for this post from The Graph’s site, please don’t sue me Graph Foundation. Your hoverboarding astronaut was just way too appealing.

TLDR; Gimme the links!

Overview

The existing project

The Octobay project itself existed, in prototype, before the Hackathon - it’s a site where open source projects can list outstanding issues that need to be worked on and offer bounties for developers to work on them. When a developer submits a PR (pull request, i.e. the code to fix/implement it) for the issue and the maintainers accept the change, the developer can then claim the bounty, which is paid out in ether. This is all handled with smart contracts running on Ethereum (testnet only for now) along with Chainlink Oracle requests which check things like whether the issue has been closed and what Github user worked on it. It also makes use of The Graph - a service which allows you to essentially index events that occur on the Ethereum network into a graphql store, which the frontend can then query for information about what’s happening with your smart contracts.

There is already a very well known site that already does something similar - Gitcoin. Octobay is attempting to differentiate itself by having a more focused and simple UI, making it easier to see what issues are available to be worked on.

The plan for the Hackathon

Given that the essence of Octobay already existed, we needed to look at something new for the Hackathon. After some discussions with Marcus (the creator of the project) and Rick (a consultant working in blockchain), it seemed like a good addition to Octobay would be a governance layer.

I’ll try to summarize the plan here, but feel free to follow along with the documentation:

When developers complete bounties they are awarded governance tokens (ERC20) for that project, proportional to the dollar amount of the bounty. From a project’s discussion tab in Github, new proposals can be created which are then voted on by the holders of governance tokens. These proposals, if they pass, can then be made into issues with bounties themselves.

A lot of existing projects also do governance via the token holders for that project. However, as these tokens are usually tradeable on the open market, it means that those with more financial means can then buy their way into a project. The key with Octobay’s governance would be that the governance token for each project is not transferable, i.e. the voices of the developers would not be drowned out by those with money.

I worked on most of the smart contract implementation, Marcus connected all of that to the new governance site in the frontend and Rick helped out with hosting and created the presentation for the demo.

The Hackathon

Creating a governance token

The governance token would be at it’s heart a simple ERC20 token, essentially the same as all other non-unique tradeable tokens on Ethereum, like LINK, DAI, e.t.c.

A few things that make our governance token a little different though:

We needed to disable transfers.
We needed to be able to snapshot the distribution of a token at the point that proposals are created, so voting power doesn’t change over a proposals lifetime.

/// @notice Explicitly disabling transfers by individual owners 
function transfer(address, uint256) public override returns (bool) {
    require(false, "Transfers are only allowed by the Octobay contract");
}

/// @param _account Address for whose balance we're asking
/// @param _snapshotId Snapshot ID for the block at whose balance we'd like to check
/// @return The balance of the given account as a percentage of total supply (0 - 10000) 
function balanceOfAsPercentAt(address _account, uint256 _snapshotId) public view returns (uint16) {
    if (totalSupplyAt(_snapshotId) > 0) {
        return uint16((balanceOfAt(_account, _snapshotId) / totalSupplyAt(_snapshotId)) * 10000);
    }
    return 0;
}

We used Giveth’s Minime token as our inspiration, which does something very similar to the above. In fact, when looking through the OpenZeppelin templates for ERC20 implementations to use, I found the ERC20Snapshot specifically references the Minime implementation in comments :D

A governance layer

Creating the token itself then wasn’t hard, but we needed to do something with those tokens to make them useful by adding a governance layer. I took LibertyPie’s implementation for inspiration here, which enabled the creation of proposals and for users to vote on them given their token share. When creating the token, you also needed to set a few values like, minimum share required to create proposals.

User’s could vote up to their share (but not necessarily all), with either a positive amount (FOR) or negative amount (AGAINST) a proposal. A quorum is set at proposal creation, the amount over which the total vote needs to be in order to consider a proposal as PASSED.

Creating an NFT with special rights

When we discussed the plan for the Hackathon, the idea of having an NFT which would give users of the governance system special rights came up. At the time, because of the NFT craze going on at the moment, it seemed a little gimmicky, but I started to warm to the idea. Giving users special rights was easy enough to implement without tokens, but given that tokens and NFTs were becoming so standard they were becoming supported by other tools, I saw the appeal of seeing your fancy NFT displaying in a wallet like Metamask.

The idea was that the creator of the governance token would receive the ‘owner NFT’, which would give them rights like the ability to create proposals without needing to own a certain governance token share. Each NFT would then have a map of permissions that could be enabled or disabled:

enum Permission {
    MINT, // Can mint new NFTs for the associated project
    TRANSFER, // Can transfer this NFT to another address
    SET_ISSUE_GOVTOKEN, // Can set the governance token associated with an issue (bounty)
    CREATE_PROPOSAL // Can create new proposals for this project
    // e.t.c.
}

mapping (uint256 => mapping (uint => bool) ) public permissionsByTokenID;

Connecting this to the frontend

The frontend was created by Marcus using a Vue framework called Nuxtjs. I fully intended to help out with connecting the site to the smart contracts, but after 2 days of looking at Nuxt and Vue tutorials I realised I was only going to slow down progress.

That was fine, because it turned out there were still a few weird bugs in the contracts we hadn’t spotted that only appeared once we started testing everything from the site itself. For instance, we froze any transfers by default in the NFT contract, apparently minting is considered a transfer. Also we found out there’s apparently a hard limit on the size of the compiled bytecode for contracts - it’s 24KB!

The wrapup

I was really impressed with the demo Rick and Marcus put together:

I think it’s a good mix of explaining the concept behind the project as well as giving people a demo of it in action. The 5 minute cap meant we didn’t have time to even tell people about the cool permission NFT though.

And it looks like the judges found it interesting too! We were awarded two prizes:

Runner Up Prizes - $500
The Graph - The Best Governance Subgraph - $1,000

I’ve really enjoyed working on the project so far and there’s plenty of work left for Octobay so I’ll continue to help out on it for the time being.

Twitter Facebook Reddit