clrfund / monorepo Goto Github PK
View Code? Open in Web Editor NEWclr.fund dapp
Home Page: https://clr.fund/
License: GNU General Public License v3.0
clr.fund dapp
Home Page: https://clr.fund/
License: GNU General Public License v3.0
Users need a way to store their MACI message-signing keys
3box? Ceramic?
Owner can set recipients (up to 16 for the MVP)
Use metadata (#57) to display recipient info
For Round 0, recipients will be added to the round along with their metadata. The address will be stored in the contract and the metadata will be emitted with an event.
Votes in MACI are cast for an index, rather than a specific address. So we need an array of addresses that corresponds to the vote options in MACI.
Here is an example of how we might build such an array, along with a mapping for convenient two-way lookup.
https://github.com/clrfund/registry/blob/master/contracts/Registry.sol
FundingRoundVoiceCreditProxy
contract must verify the amount by calling the FundingRound
contract. If possible, calling contribute()
must be the only way to sign up for MACI voting.
Add removeRecipient()
method to remove invalid entries or duplicates. It should emit an event to allow filtering on the frontend.
What to do with reserved indexes: still undecided, but I think we can simply invalidate MACI slots (see #19 (comment)).
If coordinator is changed by owner during the funding round, the round must be cancelled.
All funds from the pool must be transferred to the new round:
monorepo/contracts/contracts/FundingRoundFactory.sol
Lines 160 to 161 in 3273baf
As a temporary measure to reduce risk in the short term, we should add a hard cap on the matching pool.
Smooth out the matching fund amounts per round.
This is important for (at least) the following reasons:
Potential implementations:
For the first rounds we decided to use a curated registry of contributors instead of allowing open registration with BrightID (#26).
The registry contract should have methods for adding and removing addresses which only owner can call, and must conform to Gatekeeper interface.
For more details, see the discussion on project milestones: https://forum.clr.fund/t/reward-milestones-for-our-colony/25/
Make it possible to receive funds to addresses that might not be able to authenticate into a dapp (DAO's and multisigs, for example).
The current contribute()
function in FundingRound.sol allows a user to add to their total contribution for the round; it also allows them to add messages for MACI (prepared commands for directing votes and changing the signing key).
A user may want to do these separately.
Create a buidler script that will do the following:
https://github.com/Web3Modal/web3modal
Refer to work done in #68.
(added retroactively)
Create MACI factory contract.
The goal is to run the funding round on testnet using command-line tools (our scripts and MACI CLI).
deployMaci()
every time. A separate setter is preferred.Can likely hard-code into the UI (as opposed to pulling from distributed storage or from on-chain)
Curation and discovery tools for recipients
The need for this is mitigated by the current MACI-imposed limit of 16 recipients, but if/as that constraint is relaxed and the recipient list proliferates, credibly neutral ways of surfacing recipients that a given contributor may be interested in will be come increasingly important. Otherwise, curation may instead occur on social media and devolve to a popularity contest.
Clr.fund is building a permissionless and credibly neutral quadratic funding protocol and application that is built with zk-snark magic, courtesy of the Minimal Anti-collusion Infrastructure MACI.
The clr.fund contracts are at a point where the interface should remain relatively stable, so we would like to make it easier on developers wanting to build tools and extensions to our protocol by providing a subgraph.
To earn this bounty, you should build a subgraph that indexes all of the events in the clr.fund contracts.
A valid submission should include a demonstration and source code of a working subgraph that indexes the following entities and fields for the clr.fund contracts:
Clr.fund
Round
Contribution
Claim
Contributor
Recipient
This bounty will be awarded to the participant who submits the best subgraph as decided by the clr.fund contributors.
Shortly after the event.
500 DAI
Clr.fund is building a permissionless and credibly neutral quadratic funding protocol and application that is built with zk-snark magic, courtesy of the Minimal Anticollusion Infrastructure MACI.
A critical property of quadratic funding is the assurance that each contributor is in fact a unique individual. We would like to use BrightID to ensure this.
To earn this bounty, you should implement a VerifiedUserRegistry contract that ensures only BrightID verified users can sign as contributors to each round of clr.fund.
A valid submission should include a demonstration and source code of working contract that Verified User Registry contract that allows only BrightID verified users to sign up as contributors to each clr.fund round.
To add BrightID support we need to create a contract which will conform to the VerifiedUserRegistry interface:
pragma solidity ^0.5.8;
pragma experimental ABIEncoderV2;
/**
* @dev Interface of the registry of verified users.
*/
interface IVerifiedUserRegistry {
function isVerifiedUser(address _user) external view returns (bool);
}
This bounty will be awarded to the participant who submits the best version of this contract as judged by the clr.fund contributors.
Shortly after the event.
Unit tests:
We may also want to turn buidler scripts (#81) into integration test suite.
Some kind of interface allowing the coordinator to...
But also:
To improve contributor's experience, we need a method for batch submission of messages. I think it should be implemented in FundingRound
contract because the size of MACI contract is already approaching limits.
function submitMessageBatch(Message[] memory _messages, PubKey[] memory _encPubKeys)
It seems that we also need to ensure that the first message is a key-change command.
https://github.com/appliedzkp/maci/blob/master/specs/01_introduction.md#high-level-process
A later version of MACI will have to mitigate a vote-buying attack where a user may be bribed immediately when the voting period starts, such that their very first message is influenced by a briber. One solution to this is to have the contract to mandate that the first message that each participant sends is to change their key (see below).
Contributor can see their previous contributions within a round
View can see recipient contribution totals from previous rounds
If owner finalizes the round and the coordinator doesn't publish the vote tally, or publishes incorrect data, the funds will be locked in the funding round contract because the recipients will not be able to provide necessary data to claimFunds()
(though they can probably brute-force the results if there are only few voters).
This means that owner should wait until coordinator publishes the data and finalize the round only when there's enough evidence that the tally data is correct. To prevent owner from accidentally finalizing the round, we need to require that verifyTotals()
is called before finalizing the round.
Add method for setting recipient registry proxy:
function setRecipientRegistryProxy(address _registryProxy)
A registry proxy must implement the following interface (to be discussed):
contract RecipientRegistryProxy {
function isValidRecipient(address _recipient)
}
Then in our contracts we can use it like that:
function addRecipient(address _recipient) {
require(recipientRegistryProxy.isValidRecipient(_recipient));
}
Testnet round checklist:
Visitors and contributors can view funding results from previous rounds
Related: funding analytics
Allow contributors to revise (increase or decrease) their contributions in the current round
Anybody can claim funds on behalf of a given recipient
Allow non-owners to submit recipients for funding rounds
Set Coordinator, Witness, and Owner roles
Recipient projects may belong to categories with distinct characteristics that would be best funded by distinct clr.fund instances. For example:
So we should just have separate funds, right?
We probably should. But doing so comes with some decentralization and credible neutrality challenges. Once categories are defined, filtering recipients into categories isn't a problem: recipients can self-select into categories, and contributors can police that self-selection with their contribution choices (e.g. "don't fund a media project in the tech category"). The bigger issue is with deciding what the categories should be.
Who gets to make that decision? And who decides how matching funds get allocated to each category? Gitcoin Grants, for example, decided a few rounds ago to separate Media and Tech projects into their own categories. This was probably the right decision given how much of a fundraising / shilling advantage the top media projects have over everything else (see example 1 above), but should we be ok with one or two people unilaterally making that decision? If we're trying to build a credibly neutral fundraising platform, the answer is No.
So what can we do?
Instead of a few people making the decision, we can let the community decide what the categories should be and how much funding they get. We already have a great mechanism to do this: clr.fund itself!
The idea is to nest instances of clr.fund within other instances, creating a multi-level hierarchy of instances:
Sum of contributions made to all recipients in the round
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.