GitHidra is a web3 based platform that allows teams, organizations and individuals to monitor GitHub activity and assign rewards on the blockchain.
GitHidra leverages Gelato Network Web 3 Functions (W3F) to connect a Github App with an Instant Distribution of Rewards Agreement (IDRA) contract powered by the Superfluid ecosystem.
GitHidra main features:
GitHidra should make life easier for organizations like DAOs, teams and individuals looking for automate payments to their GitHub contributors.
GitHidra aims to solve this in a democratic and fair way to suit the needs of DAOs. This is achieved by voting to merge PRs and implementing various mechanisms to ensure the fairness of the ecosystem.
A Gelato W3F is at the hearth of our little ecosystem. This W3F manages the communication between git activity (web2) and any evm compatible blockchain (web3).
To be precise, it is in charge of monitoring a GitHub App that is integrated in the desired repos and assigning rewards accordingly on the blockchain by increasing the IDRA distribution units owned by the GitHub contributor sending the pull request.
<aside> 📌 To make PRs fit our requirements, it is necessary to have full control over the merged PRs. More on this later.
</aside>
GitHidra is able to monitor several repos keeping track of each pull request. To do this GitHidra leverages the GitHub API and a Github App with read permission for the repos being tracked. Although it is possible to set up your own Github App, GitHidra has its own integration that allows you to skip this step and delegate it to our GitHidra Gelato W3F GitHub app.
Additionally, the contributor sending the pull request must hardcode her/his address in the last “word” of the repo reference slug. In this way, W3F knows which address to reward.
It is worth noting that the pull request merging mechanism should be under the control of the same organization, team or person rewarding the contributions. It could be done, in the case of DAOs, by setting a minimum number of approved pull request reviews to merge it. Or in the case of an individual by simply controlling which PRs will be merged. It is even possible to automate the PRs review process, thanks to the help of this amazing GitHub bot powered by AI created by the FailFast team.
Once the hearth of our ecosystem is operative, it will be checking for old (you can set the start date) and new merged pull requests into the selected repos and assigning rewards to the contributors by calling the gainShares function on the selected IDRA contract and chain.
GitHidra offers 2 different ways to do this, one by leveraging the blockchain to keep track of the rewarded PRs and another by doing this verification offchain by checking transaction logs looking for the hash of rewarded pull requests. Both are secured by the chain but the first one requires more onchain computation.
The GitHidra W3F is pretty close to a standard. It is multichain, multirepo and can be configured with any GitHub App integration that has the right permissions. Also, the IDRA contract gives enough freedom to devs allowing the implementation of several use cases.
The Instant Distribution of Rewards Agreement is just a basic Superfluid IDA with some minor modifications that allows the IDRA contract to assign distribution units as rewards and keep track of rewarded PRs.
It features 2 variants to fit W3F variants. The offchain just emits an event after every reward assignation including the hash used for verification. The onchain variant implements a mapping to store these hashes onchain and emits the event, too.
Both allow contributors to receive an automatic payment via any Superfluid supertoken after successfully merging a pull request.
But IDRA also presents a complex paradox, the IDRA flow allows the distribute function to be called at any time by anyone If the funds are sent before any contribution, the first one contributor has the possibility to call distribute and receive all the funds. In the other hand the owner may never send the funds. Here, more decentralization appears in the form of a problematic paradox:
<aside> 🤔 +decentralizaton == centralization+
</aside>
This could be solved giving the owner authority to manage the funds (centralized) but GitHidra solves it by implementing the allowDistribution function. This function allow developers to configure any kind of constraint to manage the distribute function while preserves decentralization. It acts as an abstract modifier that devs can implement with enough freedom for their use cases.
GitHidra (on & off) shows the basic example, just allowing anyone at anytime to call the distribute function for testing purposes but in a production environment the deadline and the minimum PRs constraints in combination should be the way to go. (There are many other options, some of which are included as comments in the allowDistribution function).
This could be done like in seasons with X funds allocated to every season. This is what GitHidra - onchain - Seasons example does just by adding some minor modifications to the allowDistribution function of the IDRAon contract and leveraging the gitIDRAon w3f previously deployed (GitHidra components are designed to be composable). Observe the following flow:
startNewSeason. Setting a deadline of 1 month and a minimum of 5 PRs.distribute function and everyone gets paid, ending the season 1.In this way, the funds are in the IDRA contract since the very beginning of the season but the Gelato team has full control over PRs and no one is able to distribute before reach the deadline.
GitHidra variants and features.