# Address- or NFT-based funding profiles

As is probably no surprise to anyone, I still believe that NFT-based funding profiles (& *only* NFT-based funding profiles) are the best way forward for Drips Crowdfunding, at least short-term. First, I'll present a short-term MVP version of the long-term onboarding vision Ele & I presented initially. Then, I'm collecting a few arguments directly *for* NFT-based funding profiles, also including points *against* a hybrid approach (both address & NFT-driver profiles), and lastly discuss a few parallel alternative proposals (e.g. key rotation on AddressDriver, Proxy Contracts).

## MVP Onboarding UX with purely NFT-based funding profiles

I propose the following, simple funding profile creation flow for our MVP.


The user is simply guided through configuring all funding profile metadata, and eventually sends a single transaction that mints the NFT and publishes all required metadata. The funding profile immediately appears within discovery features and can be supported by others (or the creator itself).

## Why I believe exclusively NFT-based funding profiles are the right choice

### 📩 Transferrable by default

I believe that transferability of funding profiles is a must-have. We have discussed many reasons for this previously. There is no question that funding profiles for multi-delegate projects or organizations will be created - and in my opinion, making those transferable is key. A user may create a funding profile for their open-source project initially, but then a team may form around it, at which point the user will want to transfer ownership over the funding profile to a multi-sig, or simply to another person in the org tasked with fundraising. Especially when coming from web2, developers will simply *expect* ownership transferability upfront, given its ubiquity in web2 SaaS.

To solve this cleanly, I believe that any proposed transferability solution must:

- Enable *redirection* of existing supporter streams while preserving real-time analytics (such as total raised) across the transfer.
- Not require existing supporters to do anything (like updating their existing supporter streams).
- Enable full ownership over and editing of metadata for the new account owner.
- Transparently retain & expose a full history of prior owners and their actions for a funding profile.

NFT-based funding profiles fulfill all the above out-of-the-box.

### 🧳 Simple multi-ownership

I believe that multi-ownership will play an important role in the Drips ecosystem going forward. With ideas such as dependency funding and linking particular repositories directly to a project project, it's important that creating a distinct funding profile for a single software project is possible. A single org or individual may have many such projects that people will want to fund separately - and these distinct projects may have dependencies with zero overlaps. Especially with the idea of dependency funding, it's vital that a single, distinct software package & its dependencies can be split to in the future.

NFTs are inherently in a 1:many ownership relationship with their holder. Owning multiple funding profiles is simple, both conceptually and technically.

Of course, people could create new addresses for distinct software projects, and own multiple simply by holding the keys to different addresses. Assuming we don't have any new building blocks such as ownership proxy contracts (will discuss this later), this comes with a few problems:

- Organizations handling funds with a multi-sig would have to deploy a new multi-sig for each of their potentially plentiful projects.
- Ownership is less transparent. If a single address (e.g. an organization) can just hold multiple funding profile NFTs, showing a profile view not unlike GitHub's organization view, with all their funding profiles neatly grouped, is trivial.
- We can pretty easily have verified credentials on the token holder level inherited by each of the funding profiles held by that address. Since verified credentials the way we are talking about them today would be address-based, this will not be possible if every funding profile owned by the same org has its own address. Links would need to be established separately for each.

### 🙅 No upfront decisions necessary

With only a single option (NFT-based), users don't need to face a decision of whether to use their AddressDriver profile or mint a new NFT project (or deploy some kind of proxy contract) when setting up crowdfunding. I believe that this is actually a pretty complicated decision to make, and we would need to ensure that every user is fully aware of the implications of either, such as the lack of transferability for EOA address-based accounts.

### 1️⃣ One transaction for creating a funding profile is required either way

Whether or not you can use an AddressDriver profile for crowdfunding, we require a single transaction, because something needs to explicitly mark a given user ID as a funding profile. Whether this transaction only publishes some metadata or also mints an NFT doesn't really make much of a difference, especially if we make it a gasless meta TX at some point.

### 🧺 Clearer separation of concerns & functionality

In the interest of building a simple and straightforward UX within the app, in my opinion, having funding profiles be separate sub-accounts is key. People may engage in any kind of personal activity with their personal AddressDriver accounts, which is challenging to reconcile if the same account is also used for fundraising (potentially even for an open-source project with multiple maintainers).

In these situations, users may expect to be able to separate fundraising activity from other, personal activity (such as receiving or sending vesting or salary streams) in analytics and history views. Without a clear separation of fundraising streams as a subaccount, this is very challenging (potentially impossible).

On top of this, any user that mixes just one personal, arbitrary stream with fundraising activity on an AddressDriver account will no longer trivially be able to transfer ownership over *only* fundraising activity to others, through any of the transferability solutions proposed thus far.

Keeping funding profiles as separate accounts also always keeps the user's personal AddressDriver account cleared up for supporting other, different projects by themselves - and even funding their own projects transparently, which is important for the "funding your own dependencies" use-case we discussed earlier.

The user will have to manage only a single set of outgoing token balances for their personal AddressDriver account, and all they ever need to do with their funding profile(s) is to collect raised funds, at which point some of those funds will be transferred to their personal account.

If AddressDriver accounts can also be used for fundraising, we will need to handle & display incoming supporter funds, outgoing supporter funds, as well as any incoming & outgoing non-fundraising related streams when viewing a *funding profile*. In my opinion, non-fundraising-related activity just doesn't belong on such an account.

### 🏗️ Simplest to build, without any new on-chain building blocks

We already have an NFT Driver. This driver is right now capable of supporting NFT-based funding profiles without any further on-chain development required. The above-proposed solution requires only front-end development.

Having only a single type of funding profile initially will definitely allow us to build an MVP version of the crowdfunding app faster, especially given what I outlined in the previous section. We would need to handle far fewer edge cases.

### 👐 Leaves the door open for different approaches in the future

Going with NFTs only now doesn't in any way shut the door on opening up other types of accounts for fundraising in the future, were we to decide to do so. Even some of the proposed "fundraise without an explicit funding profile" solutions will be possible, because those can simply be handled by a new, different contract. Perhaps this new contract could even employ some of those ideas we had of address-derived NFT IDs, which could also enable some ideas like fundraising by simply adding an address to a funding.yml file.

### ⬆️ Easier to update in the future

By separating NFT-subaccounts from the base AddressDriver accounts, we can very easily ship additional, new on-chain functionality (such as perhaps memberships, enhanced access control, token gating, etc.) without needing to make any of our current contracts upgradeable. In this situation, we can deploy a new NFT-based driver, and simply start minting new funding profiles from this one. We could probably even find a way to allow users to upgrade an existing funding profile to a new version with more functionality.

### 🤓 NFTs are a familiar concept even to many non-crypto folks

NFTs are probably the most well-known crypto concept in the general population. A ton of potential users come with upfront knowledge of their properties - the fact that you can own multiple, and that they're transferrable. The value of this shouldn't be underestimated, especially in contrast to some other possible transferability solutions (AddressDriver key rotation, proxy contracts).

Of course, the concept of an *address* is probably even simpler, but I don't believe that we could find any solution that enables (IMO must-have) transferability-by-default that is conceptually simpler than just using NFTs.

### 🤝 Standardized & compatible with third-party products

Having funding profiles show up in NFT explorers is actually a pretty nice benefit, IMO, and opens up further avenues for discovering people's crowdfunding efforts. Ownership over funding profiles may also be used by third-party platforms for completely other use-cases easily if they're NFTs, given the plentiful amount of developer tooling around the NFT standard.

### Addressing previously-shared concerns

#### Multi-network fundraising is easier with addresses

There's an argument that address-based funding profiles could very easily enable multi-chain fundraising on other EVM chains. This is a good point of course, but there are other problems with this.

If our solution for multi-chain fundraising is to simply have people stream to a mainnet funding profile's address on L2s, someone *will* at some point stream to a non-EOA address (e.g. Gnosis Safe) on an L2 where such a contract is not deployed. This may lead to unrecoverable funds.

Regardless, we would need to implement a mechanism for choosing L2s that a user even *wants* to fundraise from, which could for example be part of the metadata.

Fetching a list of fundable projects for discovery on an L2 would also be more complicated. Assuming the thing that marks a particular address as a funding profile is a piece of metadata published by the particular account, we would probably need to fetch funding profiles from mainnet even from L2s, but then also consider any funding profiles that *only* exist on the L2. This leads to other potential UX friction:

- While browsing the app connected to an L2, does it allow creating a new funding profile direcly on that L2, or is that restricted to mainnet?
- While connected to an L2, does the explore page list only funding profiles from mainnet with metadata indicating a will to fundraise on the particular L2? Does it list projects whose funding profile metadata has only been published on the particular L2? If it lists projects from all networks, how would we handle search ranking & filtering across multiple subgraphs?

With NFT-based funding profiles, it would probably be necessary to mint a new funding profile NFT per network that you want to fundraise on. However, this gets around all of the above, and can still be greatly optimized in the future. We could allow very simple "cloning" of an L1 funding profile by minting a new NFT and publishing something that indicates to the app that it should fetch project metadata from a mainnet project. We could even make this gasless through meta TXs.

## Alternative proposals

### Adding key rotation to AddressDriver

The way I understand this is that it would be possible for a user with address `0xA` to essentially transfer ownership over the user ID derived from their address within AddressDriver to another address, say `0xB`. This other address may of course be another user, or perhaps a multisig.

The problem I see with this is that it breaks the simple, fully deterministic link of 1 address to 1 user ID within AddressDriver. In my opinion, this link is / should be the whole point of AddressDriver as a building block in the Drips ecosystem.

Once a derived user ID is transferred to someone else, the original owner can effectively never receive streams or be split to again, unless the original owner creates an entirely new address, and transfers ownership over *its* derived user ID over to their original address `0xA`.

At the same time, users may set up streams and splits to `0xA`'s original user ID, without being aware at all that ownership over that account now longer sits with the address that its user ID is derived from.

Lastly, this can lead to situations where a single user owns more than one AddressDriver user ID, forcing us to essentially build full sub-account functionality within the app. Unfortunately, we still couldn't really dress it up as a feature, because there wouldn't be a straightforward way to create a new subaccount without creating an entirely new address.

### Ownership of funding profiles through Proxy Contracts

This is a really interesting idea, but it doesn't fully solve the transferability problem.

- If the user can still choose to use an AddressDriver account as a funding profile (without deploying a proxy contract with its own address), the user can never transfer ownership over that funding profile to anyone, including a proxy contract. In short, this wouldn't make funding profiles transferable by default.
- If the user MUST deploy a proxy contract when setting up a funding profile, the entire point of being address-based is diminished, given that the new contract's address can not definitely be determined pre-deployment (the user may deploy other contracts in the meantime and increment their nonce). Consequently, funding a project pre-onboarding wouldn't be enabled.