So first, what is Cred and/or Grain? This has not always been clear. In the past the terms “mana” and “grain” have been used interchangeably. This led to confusion for all parties involved (mostly me). This thread unpacks that in further detail. The TL;DR: is:
Cred is a non-transferable token based on your contributions to the SourceCred community
Grain is derived from Cred and minted in both “fast” and “slow” payouts
Note: SourceCred itself is called Cred (capital-C). The fungible token in SourceCred-systems in general are called grain; grain in SourceCred itself is called Grain (capital-G).
Ok great! So how does one get Cred, and thus Grain?
By contributing to the SourceCred community of course. More concretely, SourceCred is running a “CredSperiment” to mint Cred and Grain for the community on a weekly basis. There’s a lot to unpack in the CredSperiment category, but the introduction is a great place to start.
How’s the CredSperiment going so far you might ask?
Week1 and Week2 have not been unsuccessful. Unlike most scientific experiments, both the data (SourceCred community contributions) and the model (the SourceCred algorithm) are shifting here. People are not upset about this. In fact, contributions and conversations seem to be picking up steam. SourceCred is one of the first games that you can both play and design at the same time. Exciting times!
In the near future community contributors will be able to use their Cred to vote on the SourceCred roadmap. This makes sense as contributors to the community would know what’s important and what they want to contribute to.
In addition, “Initiatives” have been created. Initiatives are things that the SourceCred community wants to do. Soon people will be able to use their Grain to “boost” initiatives and drive more Cred to that topic. Think of it as a +1 mushroom that boosts all activity around that initiative. (@decentralion is that more or less accurate or do you have a better explanation?). The Initiatives Plugin is under active development (at the time of writing). If you want to help make it happen and earn some Cred jump in!
To address this dichotomy of experimentation, growth, and trust data is made freely available. This creates a “trust, but verify” model. Everyone has access to the underlying SourceCred data, and everyone can run the SourceCred algorithm. This puts pressure on the project maintainers to act honestly otherwise the community will fork and/or leave.
I’m still working out the details of the donation system. Please consider it a “tentative experiment”; I don’t recommend that anyone donate to SourceCred in expectation of receiving Grain at the moment.
I quite like it. I’m finding this a valuable resource for explaining the project to others; just now I’m on this thread because I’m going to send a link to it to a collaborator.
I think this would be better as a single wiki post. Having each new post as a thread means:
We can’t re-order them (e.g. I think your post with the link to Grain should come after the post that gives 1 sentence explanations)
We can’t easily remove outdated bits
Folks’ commentary (about the experiment) gets interspersed with the reference materials
Would you be game to re-collect the references into a canoncial wiki that we can keep maintaining? We could make a new “docs” category for such documents. E.g. having a wiki post with a deep dive on how the SourceCred algorithm works in detail could be great. (I can sign up to write it )
Agreed. It’s a living brainstorm of ideas for people to dive into, expand, branch, and do whatever with. It highlights a core narrative, but does so in chunks so that people can dive in or build on top of it. It’s meant to be a living ongoing conversation.
Docs are very very different than the spotlight/narrative idea. While docs would be great for SourceCred, docs aren’t as fun/engaging to write. Also, traditionally, documentation work has been paid less and been less appreciated than general discussions, design, or development. Having contributed to documentation for several projects, I’m hesitant to continue in that direction due to the reasons listed above.
If we were, however, sketching out and designing the incentive/token models of SourceCred and then needed to formalize that into a spec, I would be intrigued…
The great thing about SourceCred is we’re explicitly building a tool to let us solve incentive alignment problems like this. I agree that docs are a lot of work and are under-appreciated, so it makes sense that you’re hesitant to commit to them. However, I am personally committed to building systems in SourceCred that amply reward documentation work, and using the SourceCred community (“CredCore?”) to model new ways of valuing documentation work.
If you’re willing to take the leap of faith and start writing docs even though we don’t yet have the system for valuing them, you have my assurance that:
we will build systems that recognize documentation contributors, and reward them for the difficulty and disproportionate value of writing good docs
you’ll have a seat at the design table when we’re building the system that rewards documentation work
Right now, I’m prioritizing an “experimentalist” vs “theorist” approach to the incentive/token models. Which is to say, I’m pretty darn sure that ideas like Cred Bounties will be really important, and I know that we can make a very simple / obvious implementation and start getting some good results and data. Once we have a few more of these systems working experimentally, I’ll be more interested in taking the step back to try to spec our how they shoud work. It feels like we’ll be better equipped to have those discussions once we’ve experimented with prototyped versions for a few months.
That said: a great thing about permissionless open source projects is that people are free to contribute value in whatever way calls to them. If you want to champion WIP living spec exploring the cred/grain dynamics, I’ll be happy to support you.
Ok cool! I’ll actually be catching up on some documentation stuff for 1Hive really soon, so as I do that I’ll think about if/how to apply that process to SourceCred and/or what would be the best way to go about it.
@s_ben You do documentation work too right? Do you want to collaborate with me on this and/or are there any examples of inspiring documentation in the wild that that we could draw off of for inspiration?
Also agree on experimentation > theorization as a design process, but it would be cool to document the experiments as we go so that everyone can be on the same page and then we can clearly see how the experiments evolved.