registry: decide on architecture for grant creation + flow of donation funds
mds1 opened this issue · comments
These are coupled, so putting them into the same issue
There are two ways donations can be handled:
- Donations are sent to a grant owner's address as part of the donation transaction
- Donations are sent to a
FundManager
type of contract, which is single contract that holds all funds and provides aclaim()
method for grant owners to claim their donations
There are three main ideas we currently have on what grant creation could look like. All can be combined with both donation flows above:
- An incrementing grant ID that maps to a struct containing a payout address (this is the current approach used by POC, and it has the downside of being very inefficient and costly, since you need a storage read for every payout address)
- Deploy a proxy wallet (see #54), where the proxy wallet address is the grant ID. This is nice because the grant ID is the payout address, but has the downside of making it costlier to enumerate all grants on-chain
- Deploy an NFT, where the holder is the grant owner
I currently lean towards the combination of donation flow 2 + grant creation 3, because:
- leveraging en existing NFT standard (TBD which, see #614) has benefits for composability, and even means your grant could automatically show up in your wallet
- having all funds sent to a singleton contract provides flexibility in account where we can optimize gas and behavior
However, a bit more research/thinking on the tradeoffs is needed before making a decision