SourceCred and DAOs: A Sketch

Some quick notes on how I see SourceCred relating to the future of DAOs. All feedback/comments appreciated!

The classic mode for organizing human activity right now is centralized, top-down institutions, like corporations. There’s someone on top who has control of the capital, and they pay people to do things that serve the organization’s goals. This is pretty effective, corps get a lot done, but it’s also more corruptible and has all the downsides of centralization of power. Also, it’s permissioned, everyone participating in the system does so on the whims of those in power, and can get fired, etc. Also, corps are only good at optimizing profits and return on capital, and we live in a world that is literally getting ruined by this drive. So: we need something better! Something new!

We’re starting to experiment with new ways of organization, like DAOs. Systems that are permissionless, everyone can participate; if groups have a difference of opinion, they’re free to fork it and set out in their own direction. Doesn’t have the kind of corrupting centralization of power that corps do. We can see open-source projects as the most successful/widespread adopters of this model. Super decentralized, people coming together out of shared interest or enthusiasm, and they build great things. However, they struggle with incentivization. This means it can be hard to get people to do unglamorous but important work – look at how many OS projects have bad documentation, for example. They also struggle with things like UI design, possibly because UI designers aren’t bought into the implicit “cred” of open-source contribution, and open-source projects don’t have a good explicit way to reward them.

As the crypto experiment unfolds, we’re now starting to explore new models for incentives and rewards in decentralized organizations. Aragorn, Colony, Gitcoin all experimenting in this field. However, the “crypto-payment” paradigm has a weakness: how do you decide who to reward, and for what? So far, the approaches tend to be really high friction, like you need to scope the work perfectly to create a bounty (only a small %-age of work can be scoped so clearly, and doing the scoping is itself hard work).

SourceCred’s goal is to create a decentralized protocol for assessing the value of people’s contributions. In contrast to the classic corporate model, it’s much less centralized: rather than there being a CEO that determines everyone’s pay, everyone participates in flowing the cred around. Human judgement isn’t removed in SourceCred, but it’s channeled, combined with data and sophisticated algorithms, so that the subjectivity is applied in a principled and transparent way. The result is better than either data or judgment would produce on their own.

Also, unlike the corporate/capitalist model, SourceCred doesn’t assume that profits are the ultimate goal. Cred can be harnessed towards any goal that produces clear success metrics. (Money has the advantage that it’s a success metric that’s hard to fake; we’ll need to do a lot of research into building robust metrics that can be applied for other values, like ecological conservation.)

As SourceCred’s protocol matures, we will combine it with Grain to leverage the incredible incentive-aligning power of tokens. Then, everyone who contributes to a cred-and-grain enabled project will get clear feedback on how valuable their contributions have been, and will be rewarded with a long-term stake in the project itself.



First, this is awesome. I love SourceCred and often joke (not joke) with Colin and Juan that I think SourceCred could be the best protocol to come out of Protocol Labs.

For me, the missing keystone to DAOs and decentralized coordination generally, is reputation-weighted peer-review. We aren’t going anywhere if we can’t filter and evolve our DAO teams based on performance. The importance of this can’t be overstated

I agree that we can do better than the top down corporate structure with binary participation (your in or your out). However, if a group of people want to get something serious and challenging done, it can’t necessarily be open to all and rewards/recognition as well as credibility can’t be totally egalitarian. For example, Ray Dalio talks a lot about “believability factor” for taking in people’s opinions for making a group decision.

So we MUST get reputation-weighted peer-review right in order to get decentralized coordination right. Otherwise DAOs will be limited in what they can achieve and we hope they can actually be a means of teams achieving amazing results (which requires coordination, not merely top-down direction). The ability to have recognition and subsequent credibility be based on meritocratic algorithms is sooo incredibly powerful. It also allows for pseudo-anonymous participation because people can build reputation without tying it to their ‘brand’ to the work since it is strictly based on results from that account.

Generally, I’m very excited for the possibility that DAOs transcend the binary nature of corporations today - where it’s either strictly for-profit or strictly a charity. DAOs may seek sustainability in its cash flow and capital base, but be entirely mission drive beyond that and I am optimistic we will see very passionate teams self-organize towards goals larger than themselves and their pocketbook, but not require patronage or external favours to survive and continue to deliver on the mission.

Finally Grain is incredibly important and thoughtful piece of the puzzle. Where other decentralized coordination platforms have driven towards a common currency, Grain allows you to be paid in the currency relevant to the given individual project. If I’m working every day in Project X, I want the Xcoin, not some other platform’s asset.

We’re very excited to dive deep into integrating SourceCred into the DA0.


Sounds like you’re describing Colony. Last time I read their whitepaper they had Colonies separated out so that contributors could earn reputation in various “departments” (like design or development) and then when a decision is needed in that department those with reputation in it could make that decision. This way your designers aren’t choosing what language to write your contracts in and your devs aren’t deciding on the font for the website.

  • upside: believability weighted voting is possible
  • downside: not everything can be neatly organized into separate departments
  • potential improvement: use an app like Karma-cap voting to weigh multiple tokens in a single vote. The way it works is that you can create a vote with multiple tokens, but then set a cap on the % of voting weight from multiple tokens. This way you could have a dual token model: a generic org token that everyone gets for contributing and a department specific token based on the type of contribution. Then you set a vote so that the larger community can vote and weigh in on a decision, but the majority of the voting weight is with those in a specific department. Could be 80/20, 50/50, etc…

Also, you could achieve something similar (reputation weight in a distributed system) with Trustlines (original Ripple idea), if you just replace the word “currency” with the word “reputation.” This would create an organic network of reputation that is organically self managed. This way contributors/members of an org could organically extend their trust/reputation into other members, who could then do the same.

  • upside: organic, permissionless, automatic - makes it easier to grow a decentralized community with minimal effort
  • downside: no built in mechanism to differentiate between reputation gained because you’re friends with someone powerful vs if you earned it
  • potential improvement: have various “Trustline” networks within a DAO, but each within a certain department. that way designers could extend trust/reputation to other designers they work with to get their feedback on things or to thank them for doing work. Same for the devs. These pools could be separate to maintain the weight in certain areas over others.

YES! That’s the whole point with this burrrata experiment! :slight_smile:

This is literally the mission statement of 1hive, but we say in in slightly more idealistic terms lol

Ohhhh that makes a lot of sense. I didn’t put that together until just now. Thanks for helping to clarify that :slight_smile:

SourceCred and Colony are similar in that they both are (or contain) reputation systems. Colony is very opinionated about how reputation works, though: there are Tasks, which are advance-scoped, individual pieces of work. Someone signs up to do the task, someone else manages the task, and then both parties’ reputation is modified based on the outcome. This is a really high-friction approach to building reputation–contrast it to the regular world, where your reputation is continually and implicitly changing based on all your interactions with others, not just formalized tasks in a particular framework.

SourceCred is a lot more like the regular world in that respect; wherever there are interactions and contributions that can be meaningfully encoded in the graph abstraction, your reputation can go there too. A good example is the fact that (as soon as I finish the Discourse plugin), every post on this Discourse will earn the poster some amount of cred in SourceCred itself. It doesn’t make sense to encode each post as a “Task” that is going to get a one-off evaluation; also, the friction of doing so on chain would overwhelm the value from such a system.

Realistically, most of the complex work that DAOs will want to do can’t be broken up into atomic tasks with clear accept/reject/reward criteria. A lot of value is created in situations with ambiguity, where you can’t really tell how much something helped until much later, and you need flexible abstractions and lots of data to work through them. That’s where SourceCred comes in.


Liking the high-level framing. Captures the “zeitgeist” around DAOs, why people are excited about them.

So we MUST get reputation-weighted peer-review right in order to get decentralized coordination right.

@rzurrer agreeing with your thoughts on the needs/restrictions of DAOs and reputation systems. Just put up a post exploring the challenges reputation systems face generally, in coordination, governance and rewarding participants, that you might find interesting: DAO Reputation System Challenges.

I’m also talking with @burrrata about how reputation-based peer review works in the Decred DAO (where I work as a technical writer and submit peer-reviewed invoices each month): SourceCred for documentation

@burrrata, fascinating stuff about colony, voting schemes! As for peer “departments”, while they’re useful, one thing that’s nice about SourceCred I’ve noticed is that domains are there if you look for them (e.g. the Design repo nodes will be related to design), but that cred can cross domains organically. E.g. if I submit an Issue to Design that actually gets commented on and generates a PR that references it, I’d get some “design cred”, even if I’m not a designer. Don’t know the algorithm well enough to generalize about that, but I imagine there are many ways to meaningfully measure reputation across domains.

1 Like

Yeah I agree totally. The process of breaking everything down into measurable chunks requires every org to have a manager, which might be appropriate for some use cases, but for open source collaboration on the commons it would be quite tenuous. Really looking forward to seeing SourceCred like in some DAOs! :slight_smile:

This is really interesting. Does this feature already exists, or is it on the roadmap?

Having “domain-specific” cred is on the roadmap (the implicit roadmap in my head). Mathematically, @mzargham and I have chatted about it a bit, as a sort of multi-dimensional generalization of PageRank – rather than flowing a single scalar on the graph, you are flowing a vector of different kinds of cred. It fits in well with our plan for there being “reward nodes” which are sources of cred that flow into the graph; reward nodes can be colored with different kinds of cred, which propagate out from there. So, for example, a successful OKR focused on feature work will be a reward node that flows implementation cred. On the other hand, the goal to write a lot of great documentation would flow docs cred.

This is still a bit handwavey. Realistically, I don’t want to take on the added challenge and complexity of making multi-dimensional cred until I am confident that the single-dimensional version is working robustly. :slight_smile:

1 Like

Awesome. This is very exciting.

Speaking of roadmaps, is there any plan to create a SourceCred explorer/visualizer so that people can more intuitively see, explore, and understand the protocol in relation to their project?

Funny you should ask. I assume when you say an explorer/visualizer you mean a graph visualization approach. Our team at the Odyssey Hackathon back in april explored this, and came up with an interesting prototype, which you can play with here:

Here’s a clean little proof-of-concept graphic I created using the same renderer:

However, I never wound up merging these experiments into SourceCred mainline. The issue is that graph visualizers are gorgeous for small numbers of nodes, but break down once the number of nodes gets very high. SourceCred graphs often have tens or hundreds of thousands of nodes, which is totally infeasible for visualization. Also, graph visualizers are a lot of work to write+maintain.

I think that graph visualizers will have a valuable role to play in SourceCred’s future. What we need is good algorithms to “collapse” the graph into a smaller number of nodes. A simple example is collapsing all of the posts in a Discourse thread into a single node, which still has the right cred flows as the set of posts did. If we had a general purpose way of doing this, we could make an interactive graph explorer that starts at a very high level, and then allows the user to explore the finer structure. An interesting highest-level place to start would be to collapse down until we just have the user nodes, and we can see how users flow cred to each other. This would also make it a lot easier to find when people are gaming cred, e.g. forming into cred cliques.

IMO, this will be a very interesting area of research to dive into, once we get around to it. But it’s not anywhere near the top of my priorities.

1 Like

This is so cool. I like how “emotional labor” is one of the cred nodes lol

Would be very very awesome to have a hackathon or open bounty for a SourceCred viz tool once the main product is up and running :slight_smile:

EDIT: as I’m playing around with the viz tool more, I think it would also be really good to help the community/team understand the work that’s being done and recognize contributions. Often times one or two teams (dev and management) get all the glory, but people don’t really see all the work that goes into making the entire project/community work. Being able to see this would provide validation and recognition for those who work hard, but are traditionally out of the limelight

1 Like

Although, if by explorer/visualizer you mean a more general tool for exploring cred distributions: that exists already.

There’s the timeline explorer which shows the high level details of cred and how it evolved over time. However, it doesn’t (yet) support diving into the relationships that generated cred.

This is what the old (legacy) system was best at. It allows recursively diving into how a user attained their cred, as in this example: image

We don’t yet have node-level cred decomposition in the Timeline app, because it was a little complicated to re-implement it for timeline cred. But, it’s a priority for me to put that into timeline. Besides wanting to deprecate legacy mode, I don’t think SourceCred is fully functional unless you can see why someone has the scores that they have.

1 Like

Yep, one of SourceCred’s priorities is to recognize and reward all the different kinds of labor that are vital to successful projects. Not just the most visible / flashy ones.

1 Like

4 posts were split to a new topic: Website Feedback

SourceCred and Colony are similar in that they both are (or contain) reputation systems. Colony is very opinionated about how reputation works, though: there are Tasks, which are advance-scoped, individual pieces of work. Someone signs up to do the task, someone else manages the task, and then both parties’ reputation is modified based on the outcome. This is a really high-friction approach to building reputation–contrast it to the regular world, where your reputation is continually and implicitly changing based on all your interactions with others, not just formalized tasks in a particular framework.

You’re right that Colony’s reputation is task-driven, but I do think there are benefits to gating reputation behind a needs-driven, semi-adversarial peer-review process. Since reputation is driven by tasks, and tasks are driven by the needs of the org, reputation becomes a (hopefully) tight proxy for the value someone contributes to the organization. As an analogy, prices capture information because of the adversarial (“PvP”) nature of their setting. So here I would hope that reputation captures information in a somewhat similar way. We frequently discuss ways to reduce the friction of the task flow, and are on the lookout for ways to incorporate automated or implicit “tasks” – but to play the devils advocate I would say that some friction in the measurement may help keep the signal strong. After all, Elo ratings are highly trusted because they are the outcome of high-friction, adversarial processes.

I think the risk of “PvE” approaches to reputation (i.e. deriving rep from activity on discourse) is that that are more vulnerable to Goodhart-style failures, where people’s behavior will re-orient around the metrics that drive reputation, “putting pressure” on the phenomena and adding noise to the signal. Undoubtedly PageRank-style graphical algorithms are more robust to these types of manipulation, and incorporating adversarial inputs like pull requests (which must be approved) will make them even more robust. But I think that inevitably the broader the base of inputs the wider the attack surface, especially when the inputs are non-adversarial or non-resource-constrained. Is it really progress if more people are posting on forums simply to increase their post count?


I think it depends on on the contribution model. If you’re in a waterfall model where first the org identifies they have a need, then someone spec’s that need into a task, and then someone does the task–then the model you describe could generate reputation that is a good proxy for value contributed (by the leaf contributors, but maybe not the need-identifiers and task-authors). But if you have more of a classic open source model that consists of people semi-randomly showing up and hacking on the things they care about, it’s not clear the task model will be able to model it. Maybe you would define a task ex-post-facto for each contribution to price it?

“PvE” vs “PvP” approaches

I really like this framing. (See: I want SourceCred to be the world’s most popular MMORPG.) My intent with SourceCred is for the system to be flexible enough to transition between PvE and PvP as appropriate, where “PvE” === you get rewards from the system alone, whereas “PvP” === you get rewards based on explicit feedback from humans.

Take the Discourse for instance. Right now, I have it configured with a nonzero cred weight on posts and topics, which means that a priori you make score for writing posts, even if no one engages. That’s an OK policy for right now because no-one is trying to game it. So we’re in “PvE mode” as a server.

However, since Discourse is comparatively very easy to game, I expect before long we’ll switch out of Discourse PvE. In that case, the default cred of a new post and topic will be zero; they will earn cred if they get likes from other players that have high cred. Also, we could have something like a weekly roundup of the best topics/posts, as curated by trusted community members, and every roundup would mint (say) 500 cred that flows out to those posts (and, transitively, to their authors and, transitively, to posts the authors liked).

I imagine before long we’ll configure GitHub similarly, where the base cred of a new pull request is very low, but the OKRs and feature priorities and such mint cred, which flows to any pull requests that contribute to those priorities. Of course, if someone makes an unexpected pull request that is very valuable, we can bless it with explicit cred, or it can get :+1: reactions, or we can define a new feature that it is connected to.


I think that gating reputation behind needs-driven tasks could be the first workable approach. This model is proven in centralized systems such as Upwork or Uber. A framework like Colony could decentralize in the sense of having reputation systems per company/org, with more flexibility in scoping tasks, perhaps a more permissionless/fair way to “move up” (get more permissions, higher pay, etc.). I think this might work better for constrained, predictable tasks such as chess (elo ratings are effective, and an interesting example to think about). However, it also does not reward participants for their own creative solutions (which may solve existing needs in a new way), or for identifying needs the org is not aware of (or it is aware of but it’s not worth the cost to scope/manage). If the solution space is too constrained, it may be successful in certain contexts (and better than PvE), but will likely not attract as much the OSS crowd. Or put another way, the ones that want work to be more of a collaborative game.

:clap: So much this.

In a former life I used to make ludicrously expensive frivolities for people who had so much money they had to really go out of their way to find more expensive stuff to buy. I say this not to lampoon the vacuous, egocentric, ultra-consumerism which accompanies idle wealth, but to disclose that the mindset of unadulterated capitalism is one to which I formerly subscribed. I embarked on that career for no other reason than to get that money.

At some point however, I realised that capitalism’s myopic focus on shareholder returns is the root of a huge proportion of the challenges the world faces. From consumerism driven ecological destruction to human downgrading at the hands of the attention economy, the frenetic, escalating, zero sum competition which drives our economies appears to me a marshmallow test failure on a planetary scale.

It seems like a really hard problem to solve though. In an increasingly globalised economy, regulations introduced to restrict free market competition in any given jurisdiction simply create competitive advantage for other less principled economies. Technology moves too fast to be responded to effectively by supranational governance, were a meaningful version of such even to prove possible.

My hope is that projects like SourceCred and Colony can prove a real alternative to shareholder capitalism, that competes with it on its own terms: rational self interest. Except this time, everyone gets to participate—not only financiers optimising for profit at any cost. Maybe that will help contribute, even in a small way, to organisations and companies adopting more holistic and utilitarian economic modalities.

Sounds interesting. Is there a technical writeup somewhere?


Domains are what you’re thinking of. They can be departments, or teams, projects—whatever you like really. It’s just a structure for moving funds around within an organisation. When you earn reputation you earn it for both the domain in which the work was done and the skills/tags associated with the work. In concert, we feel like that in most contexts we’ve been able to think of at least, that covers both expertise being demonstrated and the context (e.g. #solidity, #dev, and #ethereum tags on some work in a clientProject domain)

That’s fair comment based on the way we wrote the white paper. However, it’s not actually accurate. We really made a rod for our own backs with some of the terminology we used and the specific use cases we outlined. :man_facepalming:

We were concerned about writing the white paper to be so general as to seem nebulous, so opted for a more specific approach. However, we really intended it to capture an explanation of one kind of maximally trustless colony you could build with Colony rather than a very rigid and opinionated structure. Nothing could be further from the truth.

“Tasks” specifically has been a real cause for confusion. We really only thought of those as the mechanism by which funds would exit a colony, rather than meaning some work fully defined up front as the term is commonly understood.

We wrote a blogpost a year or so discussing this:

Bounties are not the Future of Work

Since then, the protocol has generalised further, as will be elucidated in an updated white paper we’re currently working on. TL;DR though is, yeah of course people aren’t going to meticulously detail everything they do up front. That would really suck. As it stands in “the real world” there are all sorts of ways people get compensated, and our goal with Colony is to make it easy for organisations to support whatever compensation / payment structures they need. Getting the whole possibility space will take time of course, but gotta start somewhere!

We’re not doing any of the fancy computational approaches to valuing contributions that SourceCred appear to be exploring, but if that’s something that can control an Ethereum address, if you so desired, you could easily make that the mechanism which controls payment creation and issuance in a colony. That would be really cool to see. :grin:

This is really interesting. I’d love to hear more about this: especially with regard to how the data provision, computation, and analysis/valuation of complex contribution patterns over time are provided such that DAO members don’t need to trust those providing those data. Are you using an off-chain mechanism a la Truebit?

Also interpreting how much something helped much later seems really difficult. How do you plan to identify the extent to which any particular contribution contributed to value creation ex post facto? I feel like most outcomes are a result of multivariate inputs and a healthy dose of randomness. This is one of my concerns about Futarchy as a governance mechanism—I find it tough to see how one can make good prospective decisions by rewarding correlation with positive outcomes without clear evidence of causation.

We looked into PageRank style approaches quite a bit in the early days of our thinking about Colony’s reputation system. However, we found ourselves mired in sybil vulnerabilities which seemed intractable in the economically incentivised and computationally constrained context of smart contracts. How have you thwarted sybil?

1 Like

:wave: @Jack! Great to have you here!

Funnily enough, the same was true for me. At one point I just wanted to be an uber-rich financier and planned to be a hedge fund manager. While misguided in retrospect, this period left me with a lot of knowledge of finance and economics, which I appreciate.

The Star Wars mythology is all about people being corrupted from the light side to the dark side. But it seems to me that for ambitious young people, getting corrupted to the dark side is a default state, but some people later switch to the light.

I believe that these systems will outcompete capitalism. I think open-source will be a big leverage point: I think it’s a fundamentally more productive economic paradigm in the digital age, and the existing shareholder-corporate economic model doesn’t know how to metabolize it. To continue my Star Wars metaphor, open-source is like this untouchable hideout for the Rebel Alliance that the capitalist death star can’t instantaneously co-opt and corrupt. In contrast to proprietary projects like WhatsApp, which may start out idealist, but can be taken over by the capitalist system with a single shot from FaceBook’s death ray.

To use a more historical metaphor: I see capitalism versus open-source-post-capitalism as kind of like feudal aristocracy vs the democratic-capitalist state. The aristocracy had all the power and all holdings that previously mattered (land), but the democratic-capitalists were much better at deploying the new resources and technology, so they won. (To our benefit; for all the faults of capitalism, I prefer it to a feudal aristocracy.)

There’s a few different resources, at varying degrees of stale-ness. :slight_smile: I would recommend A Gentle Introduction to Cred. The cred for this forum is also an interesting test case to dive into. I have a formal writeup of the algorithm but it’s a few iterations out of date.

Most of the resources linked describe “legacy mode” cred, which didn’t split up scores based on time. You can read a description of how timeline cred works here.

I hope to see that too. :slight_smile: @rzurrer and team have been doing work on integrating SourceCred into smart contracts, you can read a summary here.

My sense is that getting a decentralized reputation/incentive metric is a really hard problem, and to make meaningful progress, we need a group that is focused entirely on this one issue in particular. If we succeed, we’ll have a protocol that we can then plug-in to all of the exciting projects building things like on-chain governance systems and smart contract infrastructure, both of which are out of SourceCred’s wheel-house. :slight_smile:

Getting everything 100% trustless on-chain is not a current goal for SourceCred. Rather, SourceCred has a trust-but-verify model; anyone in the community can compute the cred scores, and validate that they’re getting recorded on chain accurately.

In the future, when on-chain scalability is improved by many orders of magnitude, and activity currently on centralized platforms (GitHub) has moved onto trustless decentralized platforms (Radicle?/Truebit?/IPFS?), it may make sense to create a trustless SourceCred. But it’s not needed to make progress on the core problem we’re tackling.

A great question. SourceCred has a framework for this: if a new contribution is created today, we can find all the past contributions that enabled it, and create edges from the new contribution to those past contributions. Then the value associated with any new contributions (which are relatively easier to explicitly value, e.g. through “boosting”) will pay out to all the past work, “discovering” its value.

A key question is how effectively we will find these edges. My intention is to make a sort of “curation/assessment” game within SourceCred, where individuals can use their “mana” to propose new edges in the graph, and are rewarded with cred if that edge is accepted. So the game has at least two kinds of players: contributors who do valuable work, and curators who upkeep the cred graph to ensure contributors are rewarded fairly.

I’m still working out the rules and mechanics for this game. You can read the intro here and I’d love your thoughts and contributions!

This goes back to SourceCred not being trustless. Every community will have moderators (e.g. community leaders) who are empowered to protect the integrity of cred from attacks, Sibyll attacks being a particularly obvious one. The system is highly transparent, so everyone can watch the watchmen, call out moderators who are misbehaving, and fork the cred if needed.

In the future where this is all more mature, we’ll have more formal systems, e.g. cred-weighted election of moderators, the ability to recall or appeal a moderator decision.


I feel like it might well be possible to do this trustlessly using a similar approach to colony’s off chain reputation mining. I will think on it and read the other stuff you’ve pointed me to and revert back. I’m really excited by any mechanism which could be used for allocating resources and authority which isn’t just voting on every damn thing, but for it to be really applicable in a DAO I feel like it needs to be ~trustless. It would be cool to figure that out.

1 Like

Assuming you want data from GitHub, it can’t be trustless, because you need to trust GitHub.

If all the data is coming from trustless / verifiable sources, maybe (probably?) it could be done. But losing out on the real data of people collaborating is a big cost.