# Proposal: A Product Design for Funding Profiles

## Overview

This document outlines a proposal for how certain "product" decisions should be made in the Drips V2 app related to allowing end users to create profiles for raising funds.

## Users: Individuals and Projects

Before jumping into the design, let's discuss the kinds of "users" want to enable to raise funds through Funding Profiles. When we look around the space of crowdfunding apps, we see that most of them have focused exclusively on individuals rather than projects (e.g. Github Sponsors, Patreon, Onlyfans, Twitch, etc.), while some others leave this open, or perhaps skew somewhat towards favoring projects (Juicebox, Kickstarter).

There may be many reasons for this, including legal/regulatory considerations as well as wanting to avoid the complexity of having to offer goverance solutions inside these apps.

With all of that as background... *I believe that Drips V2 should try to support both individuals and projects creating Funding Profiles, but we should assume that our solution may work better for individuals than projects, at least initially.*

## The Design

In contrst to prevoius designs, the design explores **allowing both Ethereum addresses and NFTs to act as Funding Profiles:**

* A "Funding Profile" is simply a set of metadata events emitted on the Drips contracts, related to a user ID.
* This leaves the door open in the future for any type of Drips user ID to act as a funding profile.
* In the initial Drips V2 release, *we will support both address-based users and NFT-based users "enabling", or "turning on" a funding profile on their account, by emitting some metadata events*.
* In the Drips Webapp, both address-based users and NFT-based users will have pages where the details of their accounts can be viewed as usual (showing inbound/outbound Drips, Splits, etc) and managed (if authorized).
* If a funding profile has been enabled for a user, that user's account page (either addresss-based or NFT-based) will gain a new "Funding" or "Crowdfunding" tab on the left.
* This "Funding" tab will correspond to a new URL in the app for that account, which can be shared with the user's prospective supporters as the main landing page to send them to to start donating.
* Any user can directly support other users with both Drips and Splits. There is no limitation that "project-based", or NFT users are not able to Drip, must split 100%, etc.

## User Experience Implications

The main goal of this design is to offer the best possible user experiences for both devs and supporters around the flows we care the most about. What does this look like in practice?

### Individual Dev Wishing to Raise

An individual dev with an ethereum address who wants to raise funds can get started by simply connecting an EOA-based wallet, visiting their page in the Drips app, and clicking a "raise funds" button, which will walk them through setting up their Funding Profile.

The dev can then link social identities directly to this address using Gitcoin Passport.

We can see that this design offers the most streamlined version of this flow -- which is likely to be the most common user type -- with the least possible steps. It's also a very intuitive UX since treating an Ethereum address as a user and having them connect with a wallet (like Metamask) to control their accoun by far the most common and straightforward user paradigm in web3.

Finally, we can see that this design will make much more sense to an individual user than creating their funding profile as a separate NFT, because:

1) Each user will likely only want to create one Funding Profile related to their individual work in web3 in any case.
2) Many other web3 users will likely already think about this user as *being* the Ethereum address, rather than being both an Ethereum address *and/or* an NFT, so the address-based user in Drips is where they will intuitively expect to go to support them.

### Project Wishing to Raise

A project wishing to raise is trickier for a number of reasons, but especially because it introduces questions related to governance. However, in addition to that, social linking (e.g. to repos or orgs) is also harder due to technical constraints. And also what a "project" is is fuzzier, because sometimes this means an Org and sometimes it means a repo and sometimes it means just a project as an idea that hasn't even been created yet.

*With all of this in mind, our design offers several configurations of addresses and NFTs for how projects can raise funds.* Given the complexity and our uncertainty about all the use cases, I think we will need to let the users try them out and see which one wins. It may even be that more than one configurations "wins", given all of the different types of projects and governance designs that exist.

The first thing we note is that the most common user representation of a "project" in web3 is a Gnosis Safe smart contract. This helps us orient ourselves, because at a minimum this tells us how the project team will connect their wallet and send transactions.

I think it's also likely that some projects will want to start with just an EOA address, perhaps because they have a single person who they trust to control the funds (e.g. an early stage project, or because of legal/reputational guarantees) and they want to move fast and have the best possible UX.

All of this sets up 4 main options for how projects can raise within our design:

1) **Funding Profile on the Multisig Address** - this is probably the simplest for most projects. Many web3 projects already have a multisig, so similar to the individual design it means that the flow for setting up funding will be the simplest, because the multisig alread exists, and nothing elese needs to be created. And also the most intuitive to both the project and to its supporters, similar to the invidiual dev case discussed above. In this case, social links can be added to the multisig profile using the delegated EOA approach.

2) **Multisig Addresss Holding NFT Funding Profile(s)** - where the above falls short is projects that are more like "orgs" who want to manage multiple funding profiles (perhaps for multiple repos). In this case, a design where the team's multisig holds one or more NFTs, which each has a Funding Profile is more suitable. Although this requires more setup, it offers a nice separation of concerns. Social linking can be done on both the multisig and the NFT Funding Profiles, as required, via EOA-delegation (and as makes sense depending on the social identity being linked).

3) **Individual Address Holding NFT Funding Profile(s)** - this may make sense where there is a single individual on a team who is fully trusted to be a super admin and where the team just wants the best wallet UX, and also the flexibility to manage multiple funding profiles. This is actually similar to how Github Organizations are governed, if you think about it, so many orgs may want this. Social linking is done similar to (2)

4) **EOA Ethereum Address** -- this probably makes the least sense for projects, but some small projects may choose to do this if they have a small team (which makes them more like an individual dev), have an individual on the team who they fully trust, and/or if they know they will never need to manage multiple funding profiles. This approach does offer the most streamlined UX for setting up a new project Funding Profile and the simplest social linking, but at the cost of being the least flexible in the long run.

Finally, note that at an extreme these can even be mixed and matched for an org with multiple projects, so that for instance Radicle might be a multisig, which could have a Funding Profile on its address, but also hold NFT users for Heartwood and Drips, which could each have individual Funding Profiles of their own. It is unlikely that most projects would start this way, but for large crypto-native web3 orgs like Radicle, I could actually see something like this making sense if Drips gains adoption in the long-run.

### Individual Wishing to Support

We expect that an individual wishing to support either individuals or projects will do so from their EOA address/wallet-based user account.

If a user is raising funds as an individual dev, any support they are also sending in the form of Drips or Splits will appear on this same EOA account profile page in the app. This is what all users would intuitively expect (e.g. versus seing that support as being configured on some separate NFT owned by the individual dev).

### Project Wishing to Support

Projects wishing to support either individual devs or other projects have essentially the same options as described in the "Projects Wishing to Raise" section above, with similar considerations for each option.

Some "projects" may be more like orgs and some may be more like repos. Some may have a fully-trusted team member and others may rely heavily on a multisig for governance. They may value being able to move quickly and have a nice wallet UX differently.

How they think abotu these things will push them to set up as one of options (1-4) outlined in the "Projects Wishing to Raise Section".

However one thing that's worth noting is that *we expect that projects that are both raising and supporting will support any individuals and projects they wish to support directly from their Funding Profiles (whether NFT-based or address-based)*.

This is in contrast to other proposed desings where a project that wants to Drip to another project would first have to withdraw funds from the Funding Profile user account to a separate user account that would then Drip to an individual or project they wish to support from there.

## Conclusion

This design attempts to offer the most streamlined and intuitive UX to users for the use cases and flows that we believe will be the most common and which we understand the best (i.e. individual devs and supporters), while also offering very flexibile and reasonably usable configuration options for use cases and flows which we both don't understand as well and which may not be as easily satisfied by a single configuration/design (i.e. projects).

The design is also technically elegant in building up Funding Profiles from Drips metadata events tied to user IDs, which leaves the door open to more types of Funding Profiles in the future as new Drips user types are added. It is also conceptually very simple -- **any Drips user can directly set up a Funding Profile on their account**.

The design also intentionally avoids any one-off constraints around what certain types of Funding Profiles users can do or not do (e.g. cannot Drip, must split 100%), which may limit composability and flexibility of accoutn use in the future.