Discuss: Use a grant's payee address as it's ID

[mds1]

Problem

As described in #40, every contribution requires, at a minimum:

1. A call to the GrantRegistry (2600 gas the first time, 100 gas subsequent times)
2. A read of the payee address fo the specified grant ID (2100 gas each time)

This adds up quite a bit, and is very inefficient. To contribute to 100 grants at once, you're looking at (2600 + 100 * 99) + (2100 * 100) = 222,500 gas, or about $16 at current prices just to read all payee addresses. This is not counting token transfers, swaps, and other contract calls made as part of the donation transaction, and checkouts will likely become prohibitively expensive for many users.

I'd like to propose an alternate approach, which instead use the the payee address itself as the grant's ID. There's two initial problems with this idea:

1. A user cannot use the same payee address for multiple grants
2. A malicious user can create a dummy grant with your address as payee to block you from creating a grant

Solution

The solution proposed here is as follows:

• When a user creates a new grant, deploy a contract wallet for them
• Save the address of that contract as the grant's id
• All contributions to that grant are sent to the contract wallet
• The contract wallet has an owner, and only the owner of that contract can withdraw the funds (the owner can be anything, e.g. an EOA, a multisig, a timelock, a DAO, etc.)
• When donating, we no longer need to verify the ID and read the payee address, which saves gas

This makes creating grants more expensive for grant owners, but makes contributions cheaper for donors

Implementation Ideas

Maker's DSProxy and Gnosis Safe have both been around for a long time and are sufficiently battle-tested that they can be used as a drop-in solution for the contract wallets we need to deploy. This gives us 3 options for using the grant's payee address as it's ID (using current gas prices for dollar amounts):

1. Use Gnosis Safes, which deploy minimal proxies at a cost of ~280k gas ($20) when created with a single owner. The gnosis safe interface can be used by grant owners until we decide to create our own interface for grant owners (assuming we decided to do that for better, application specific UX). No audit needed here
2. Use DSProxy and the DSProxy Factory, which by default deploys full contracts at a cost of `~600k gas ($42). There is no interface, so we'd have to build one upfront for grant owners to access their funds. No audit needed here
3. Use DSProxy but modify the factory to deploy minimal proxies. I'd estimate this would cost 100k-200k gas (~$7-$14 to $200). There is no interface, so we'd have to build one upfront for grant owners to access their funds. Audit preferable since we'd be changing the contract code

We don't need to pick one of those 3 options in this issue—this issue is focused on whether or not we should make this change—and if so we can finalize implementation as part of a separate issue

Tradeoffs

Here are the pros/cons of the two approaches that I can currently think of:

Using an explicit ID and payee address as we currently do:

• ✅ Cheaper to create new grants (on a one-time basis, per grant)
• ❌ Makes contributions more expensive (on a recurring basis)
• ✅ Familiar interface to access your grants funds (i.e. however you normally access wallet funds is how you access received donations)

Using a contract wallet as the grantId, where the wallet's owner can be whatever the user wants:

• ❌ Grants are more expensive to create (rough estimates on cost above)
• ✅ Contributions are cheaper (by ~2225 gas per contribution if everyone donates to 100 grants at once, more info below)
• ❌ New interface needed to access your grant's funds (new for the user)

"Worst case" estimated cost savings of contract wallet:

• Assume everyone donates to 100 grants at a time. This means current approach adds an average of 222,5000 / 100 = 2,225 gas per contribution
• Assume worst case contract wallet of DSProxy costs 600k gas to create
• This means that in terms of total gas spent on grants, contract wallets as IDs become cheaper after 600,000 / 2,225 = 270 contributions

Even though the proposed idea has two X's and the current approach has 1, I think that:

1. A new interface for grant owners to get their funds is ok, as they are incentivized to figure it out and redeem their funds anyway
2. The costs saved by users will outweigh the increased grant creation cost, resulting in a net cost savings in the long run.
3. A goal of Grants IMO is maximum inclusivity of who can participate, which means making it as accessible as possible, and since there will be more contributors than grant owners, minimizing costs for contributors at the expense of grant owners seems like a reasonable tradeoff, especially since contract wallet deployment costs are not unreasonable