Identity and Quadratic Funding: standards to help fund projects and commons

Is anyone interested in organizing standards for quadratic funding?

At nearly Magicians’ gathering there is a group of people coming together to discuss the issue of funding in the community. @anettrolikova and I even had a discussion at Devcon in Osaka, a session with the EF Grants Team and Cat Herders to discuss the funding of Magicians’ work.

Many prominent efforts have emerged as alternatives to “grants from whales”: Moloch DAO, MetaCartel DAO, all of the options that Gitcoin offers, and the innovations of Vitalik Buterin / Zoë Hitzig / Glen Weyl. It might be helpful to to have an open tool set for funding based on the ideas of “Liberal Radicalism” (CLR), perhaps this would lead to wider adoption and new things build on top of the approach.

But I wonder: isn’t it too early to standardize? Shouldn’t it be roughly tested more with the community first with efforts like Gitcoin CLR Matching? Update: in a comment Vitalik points out that for quadratic funding standards, work is needed right now in identity systems.

Please respond here if you are interested, and reach out to those in the community already discussing CLR and identity. This includes Kevin Owocki, Alex Masmej, Mark Beylin. If a Ring forms, I will create a category here in the Forum to encourage discussions.

Also, for more deep diving and explorations, check out Vitalik’s latest ball of lightning: Quadratic Payments: A Primer


Not sure if “standardization” is the right frame for this sort of thing. What I was thinking is to keep supporting the Gitcoin and the MACI teams on their own paths (and in parallel keep working on better identity systems), and at some point one should integrate the other and we can have a standardized package for running QV / QF instances.

The one place where we could use more standardization work right now is identity systems.

1 Like

Agreed, a better frame might be coordinated experimentation. And the requirement for quadratic voting/funding/etc to work in decentralized smart contract systems is standard identity.

Those prototyping on these ideas could simply get into communications to compare notes and find common points to work on together, attract more to the scene. This has been happening in the DAO zone.

IMO premature standardization can be premature optimization in the coordination sense. But the communications / organziing makes identifying needs and creating shared resources a lot easier.

I didn’t even know there were MACI teams!

Responses from @owocki on Twitter (to my original post here):

Imho we need two standards - one for grants, the second for administration of CLR

Personally I think standardization is valueable, but the real killer app would be a whitelabel Grant/CLR platform (that doesn’t have the assumptions gitcoin does around GitHub login/open source focus )…

This way @glenweyl & co can administer CLR in many diff verticals

1 Like

Agreed that it’s too early for a standard, but I am interested in working on some coordinated CLR experimentation (and I would be happy to work as a dev on building an open platform for CLR pilots).

Gitcoin in particular does all of their CLR logic off-chain (which I think makes a lot of sense for their purposes given speed to market, their current architecture, etc.), so I wonder if the standard would make sense as an EIP unless more of it is onchain? There could be non-EIP standards though, of course.

Gitcoin will be presenting at the next Chicago Ethereum Meetup in part about quadratic voting / CLR, and we may have our members do a mini CLR to decide how to prioritize which dapp pilots we want to run at upcoming meetups with a small matching pool.

I’ll note that whenever a standard emerges, different architectures would make sense for small numbers of M contributors and N recipients than for large numbers. For instance, if the numbers are small enough, the approved M and N addresses could live directly in a contract so that the distribution at the end could happen via a contract function call.


@pcowgill, excellent to hear that there is a Meetup focusing on this topic!

@vbuterin, regarding identity, I took a look at the state of standardization / development / adoption. There are highly developed standards and initiatives for this, and for Ethereum smart contracts in particular. There are usable implementations and some adoption. I will list some out here.

It seems as if the momentum in this area is very good; are there concerns about the current work?

The key Ethereum-related standards

ERC-1056 - DID-compliant lightweight identity

Jolocom DID Method

ERC-725 v2

Identity resources and readings

Different Approaches to Ethereum Identity Standards

List of Ethereum Identity Specs, EIPs, implementations - DIDecentral

Significant implementations

uPort - implements DID

Jolocom - implements DID

Bloom - full DID compatibility proposed in BLIP-6



DIF / Digital Identity Foundation

Rebooting Web-of-Trust

ERC 725 Alliance

1 Like

The problem with most “identity standards” today is that they solve the account administration and persistent-username problems, and don’t solve the unique human problem. I’d be interested in a taxonomy of solutions to the unique-human problem specifically.


To expand on @vbuterin’s point about the human uniqueness challenge in self-sovreign identity systems, this is to prevent manipulation of systems which depend on users being actual people e.g. Sybil attacks.

Identity systems can use verifiable claims, enabling other users or algorithms to determine human uniqueness of an identity based on the credibility of the claims.

Identity systems can use video stream or other analog proof and a human or algorithmic verifier, without depending on third-party central authorities (but then these system themselves become central authorities).

Identity systems can use the peer-to-peer approach, allowing a chain of human uniqueness proofs to emerge by repeating a social behavior pattern.


POAP - The Proof of Attendance Protocol

Here is the Gitcoin Grants page for an open CLR / quadratic funding platform as described by @owocki in the Twitter thread that @jpitts linked to above!

1 Like

(CRL -> CLR typo fixed on the Gitcoin Grants page, but it may continue to show the old version as a preview here.)

@jpitts wrote an article on how Ops ring works " The Operations Behind The Magic" :sparkles:

We put up Gitcoin Grant any support is highly appreciated and will be used for the sake of the community and in-persons meetings :money_mouth_face:
(it’s still in reviewing process but it’s live, sadly I’m not sure if it will make it into CLR matching :confused: )

I started BrightID a couple of years ago to specifically target the unique human problem.


I love the narrow scope that brightID is committed to. Solely for providing “Proof of Uniqueness” It would be a great addition to CLR… I don’t know if it works well in the gitcoin implementation… as they have github for identity. But maybe it could be built into @pcowgill’s Open Funding

1 Like

Yep, for sure! I’m going to be hacking with the BrightID folks at ETHDenver as well.


Kleros has a related project: Proof of Humanity.

A common problem on the internet is the lack of sybil-resistant identity systems. Users can generally create multiple accounts using different pseudonyms (or address in the case of crypto-networks) to receive rewards multiple times, bias votes, write multiple fake reviews, etc.

We introduce Proof of Humanity, a system combining social verification with video submission in order to create a Sybil proof list of humans.

According to the Kleros Development Update: April 2020, smart contracts have been developed for the Proof of Humanity project.

1 Like

Working plan for grants round 6 is to do SMS (or some zero knowledge version of it) for anti Sybil verification

1 Like

Here is a comprehensive overview of proof of personhood protocols.

Who Watches the Watchmen? A Review of Subjective Approaches for Sybil-resistance in Proof of Personhood Protocols [PDF]

In this article, we will outline the approaches of these new and natively digital sources of authentication - their attributes, methodologies strengths, and weaknesses - and sketch out possible directions for future developments