Skip to content

Instantly share code, notes, and snippets.

@frankchen07
Last active March 19, 2019 08:34
Show Gist options
  • Save frankchen07/1ade6a819e89962dfcda1cd61c5d0e96 to your computer and use it in GitHub Desktop.
Save frankchen07/1ade6a819e89962dfcda1cd61c5d0e96 to your computer and use it in GitHub Desktop.
Gitcoin Multi-Signature

Assumptions:

  1. Capabilities on Gitcoin to view organizations will also need to be built out alongside shared management and multi-signature capabilities (organization pages, less-hacky search by organization, organization pages).

  2. Risks include the technical and product resources we are putting into Bounties, which currently is less likely to net us revenue.

  3. It is a possibility that shared management and multi-sig are gated, premium items later in our subscriptions model testing.

  4. Requested feature from many of our funders, but potentially not revenue generating.

Problem:

For Gitcoin Bounties, users from the same organization who open bounties find it difficult to manage bounties within the team, as payout and funder actions are tied to a specific funder's account.

Hypotheses:

  1. Enabling shared management and multi-signature contract addresses for funding bounties will:

    • improve communication between an organization and bounty hunter
    • improve payment delays
    • decrease complaints related to bounty payment and dampened communication between funder and bounty hunter.

Shared management = allows organizations to fund bounties, not just one specific funder from that organization (think of it as more of a front-end presentation)

Multi-signature contract addresses = is the mechanism that allows this to happen; it provides one contract address to fund bounties with, and funders with "owner" access from that organization with EOAs have access to control this multi-signature contract address

Previous thoughts by Seagraves in a Grants context: "grant recipients who use a multisig doesn't add any extra effort to the engineering team. Grant recipients would just use something like the gnosis-safe or gnosis-multi-sig." <- sounds like we outsource the multi-sig contract capabilities

@danlipert
Copy link

There are multi-sig wallet contracts out there that have been well vetted and audited, and we should definitely rely on those (basically, a bring-your-own-wallet approach). Essentially, rather than using metamask to interact with the gitcoin system, they would use a multi-sig wallet like Gnosis to make contract calls and transfer Ethereum/tokens. We'd have to build our system in such a way that that multi-sig users can input the contract address of their multi-sig wallet, and then when they take actions on our platform, they approve the action once via metamask, and then this calls a function in their multi-sig wallet which then needs to be separately approved within the wallet software. See my video on the Gnosis multi-sig wallet for a demonstation: https://www.youtube.com/watch?v=pFa63FR8Mgk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment