clrfund / clrfund-deployer Goto Github PK

needed to deploy MACI

• Factory Types
• Form
• Hooks

User Story

As an Admin I would like to deploy MACI Factory contract so that I may deploy MACI instances for each new funding round

Tasks

User Story

As an admin I would like to start a new voting round so that I may collect money for my public goods.

Tasks

User Story

As an Admin I would like to deploy Funding Factory contracts so that I may deploy funding instances for each new funding round

Tasks

User Story

As an Admin I would like a way to request my tally.json from the coordinator so that I may finalize or cancel a funding round

Tasks

User Story

As an Admin I would like to deploy a valid instance of IUserRegistry so that I may onboard my users to each new funding round

Tasks

needed to deploy MACI Factory

• Factory Types
• Form
• Hooks

User Story

As an Admin I would like to Finalize a funding round so that I may distribute funds according to the vote tally provided by the coordinator

Tasks

needed to deploy MACI Factory

• Factory Types
• Form
• Hooks

User Story

As an admin I would like to use SimpleRecipientRegistry or Kleros TCR as a Recipient registration method that satisfy IRecipientRegistry, so that I may have easy deploy options

Tasks

User Story

As an admin I would like to connect to an arbitrary EVM network so that I may deploy contracts there

Tasks

Notes

Assuming we use a subgraph to fetch data to the application, the subgraph and dependencies will need to be deployed to any network we support.

User Story

As an admin I would like to Contact the clr.fund team for help being my coordinator or be the coordinator myself, so that I may have easy deploy options

Tasks

User Story

As an admin I would like to Set Signup and voting durations in Funding Factory Contract so that I may update the Signup and voting duration, in future funding rounds

Tasks

• Transaction hooks
• Documentation
• Hook up Wallet Provider
• Hook up Wallet Modal
• Form Component

User Story

As an admin I would like to transfer ownership of my MACI factory to my Funding Factory Contract so that I may update MACI factories in future funding rounds

Tasks

• Transaction hooks
• Documentation
• Hook up Wallet Provider
• Hook up Wallet Modal
• Form Component

User Story

As an Admin I would like to cancel a funding round so that I may distribute funds back to participants

Tasks

User Story

As an admin I would like to make changes to my UI so that I may keep it up to date or fix errors/issues

Tasks

User Story

As an Admin I would like to use/deploy a UI for my IUserRegistry so that I may manage users sign up on the Registry Contracts (Simple, BrightID, etc.)

Note

Split into two stories

User Story

As an admin I would like to update the Address of the IRecipientRegistry contract my Funding Factory Contract uses so that I may update/patch IRecipientRegistry in future funding rounds

Tasks

• Transaction hooks
• Documentation
• Hook up Wallet Provider
• Hook up Wallet Modal
• Form Component

User Story

As an admin I would like to set the coordinator in the Funding Round Factory Contract so that I may update coordinator keys used in future funding rounds

Tasks

• Transaction hooks
• Documentation
• Hook up Wallet Provider
• Hook up Wallet Modal
• Form Component

User Story

As an admin I would like to connect to xDai so that I may deploy contracts there

Tasks

User Story

As an Admin I would like to add theme customization to my clr.fund App instance so that I may incorporate my org's branding.

Tasks

User Story

As an admin I would like to verify that I am deploying the latest versions of the contracts

Tasks

Overview

A factory contract that deploys MACI and funding round factories, which are the two factory contracts that constitute an instance of clr.fund. While such a factory factory is not strictly necessary, it would
- facilitate a subgraph to support performant data fetching in clr.fund app instances
- make it easy to provide a web-based instance-deployment UI
- give admins confidence that they are deploying the correct version of the requisite factory contracts.

Considerations

Block size limits. With all code deployed in one contract, a factory factory may be too big to fit into a single block. However, we could get around this constraint with a few approaches:

1. By using a clone factory pattern such as EIP 1167 (or similar). That would have a secondary benefit of reducing the deployment costs for admins.
2. Another mitigation would be to create two factory factories, one for MACI Factory and one for the Funding Round Factory. That would require two subgraphs, but that might be ok, and we might really only need a subgraph for the Funding Round Factory anyways.
3. Deploy MACI and Funding Round factories for each instance, and then add a registration contract that ties them all together into a single subgraph.

User Story

As an admin I would like to deploy a valid instance of IRecipientRegistry so that I may onboard new recipients in each funding round

Tasks

User Story

As an admin I would like to use/deploy a UI for my funding round so that I may give users a way to easily donate to recipients

• includes self-hosting configuation

Tasks

• schema
• subgraphs x5

User Story

As an Admin I would like to use/deploy a UI for my IRecipientRegistry so that I may manage recipient sign up on the Registry Contracts (Kleros, website, etc.)

Note

Split user story

Overview

For longer rounds, contributions can in theory be converted to a yield-bearing asset to grow the total funding per round. clrfund can use any ERC20 for the round token -- including deposit tokens like cTokens, aTokens, or yearn vault tokens -- so user contributions made in "raw" stablecoins could be converted into the yield-bearing round token, potentially via a zap.

On the deployer side, an option for admins to select the desired yield-bearing asset as the round token and configure the zap.

Considerations:

• deposit/withdrawal gas costs eating up any yield earned
• different defi protocols on different networks

User Story

As an admin I would like to update the Address of the IUserRegistry contract my Funding Factory Contract uses so that I may update/patch IUserRegistry in future funding rounds

Tasks

• Transaction hooks
• Documentation
• Hook up Wallet Provider
• Hook up Wallet Modal
• Form Component

User Story

As an admin I would like to use SimpleUserRegistry, with options to define the owner address or
BrightID as a User registration method that satisfy IUserRegistry, so that I may have easy deploy options

Tasks

User Story

As an admin I would like to add and remove Funding Sources from the Funding Factory Contract so that I may update the funding sources used in future funding rounds

Tasks

User Story

As an admin I would like to Set token to accept donations in Funding Factory Contract so that I may update the token donations are denominated in, in future funding rounds

Tasks

• Transaction hooks
• Documentation
• Hook up Wallet Provider
• Hook up Wallet Modal
• Form Component

Related to #12 & #16

Once a CLR.fund instance is deployed, it'd be great to add some "management" features for admins. One in particular would be a screen to manage requests if using the OptimisticRecipientRegistry contract.

I'm envisioning a screen of "pending requests" that the registry owner can challenge/execute (via challengeRequest & executeRequest).

Another nice feature (dependent on clrfund/monorepo#344) would be the ability for owners to approve requests immediately (without having to wait for the challengePeriodDuration).