WORKSHOP - As a Gitcoin funder, 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.

[frankchen07]

User Story

WORKSHOP - As a Gitcoin funder, colleagues from my organization cannot easily manage and payout bounties within the same organization, as payout and funder actions are tied to a specific funder's account.

Why Is this Needed

We've heard and received multiple pieces of funder feedback requesting an organizations / multi-signature functionality in order to overcome the single-specific funder's account management issue.

Description

The scope of this ticket is to specifically discuss the user flow and experience of a shared management / multi sig implementation, and come to a well-scoped out build solution.

old discussion and closed tickets:

#3993 - initial ticket discussion
https://gist.github.com/danlipert/7c976627c42e877678b0d3a447b547ab - dan's multi-sig write up
https://gist.github.com/frankchen07/1ade6a819e89962dfcda1cd61c5d0e96 - frank's multi-sig hypotheses
https://gist.github.com/thelostone-mc/494fd6ffc3395de6185f96a766d4c1ee - adityas write up on ux actions

current tickets:

#4000

sub-tickets

sprint 14: #4766 - ensure no issues with same address
sprint 14: #4767 - educational materials for same Pk

summary:

1. shared management is a peer-to-peer approval to help manage a bounty (think funder approves a gitcoin ambassador in the multi-signature contract wallet to help them manage and payout a bounty)

2. shared management in an organization sense (think one organization with multiple funders who post bounties using a multi-signature contract wallet, where there are rules for payout and/or each funder part of that organization can choose to pay out)

3. all cases above require the ability to integrate multi-signature contract wallets into the bounty workflow.

additional assumption: use case for multi-signature doesn't necessarily increase ease of use, it increases the complexity to increase security, while at the same time, allows additional grouping operations under bounties.

where we are now:

"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."

Things that need to be hashed out:

1. we need to support multi-sig contract addresses, or is there a lower lift way to do this? to me, it sounds like shared management and multi-sig come hand in hand
2. for shared management will the ux be defined within the multi-sig wallet (post-metamask confirmation?)
3. what are the user flows?

Current Behavior

No method to share management of a bounty.

Expected Behavior

A fluid plan of implementation and begin building the solution for shared management of a bounty to either a person within their organization.

Definition of Done

• research approaches/limitations
• agreed upon user flow
• decision points on consequences of UX changes
• scoped out build plans
• decision points on engineering tradeoffs
• provide recommended solution

[PixelantDesign]

** Part 1 - Shared Metamask - Set up user management** - pilot test

• ensure no issues for users with same address in database (5)
• educate and frame to user on how to set up metamask to have same private key. (3)

** Part 2 - Team Bounty management, team member**

• come up with flow for this experience (5)
• decide how funders approve candidates on abounty as a team (5)
• build out