Grain: a project-specific, cred-powered token

A big part of SourceCred’s vision is the desire to create project-specific cryptoassets, called ‘Grain’, which represent contribution to or support of a project. Here’s an overview, as lifted from my own writings on GitHub.


SourceGrain will make open-source software projects financially sustainable by letting them issue their own project-specific cryptoassets, called grain.

Properties of Grain

  • Grain is always project-specific. For example, “SourceCred grain” and “IPFS grain” would be wholly different assets.
  • Every week, new grain is created, or “harvested” by the project.
  • Most of the harvested grain goes to people that have directly worked on the project.
  • A fraction of the harvested grain flows to those who hold grain in the project’s dependencies.
    • For example, if you have grain in Python, then you would continually earn a small share of NumPy’s grain, and so forth.
  • Grain is a freely transferrable and exchangeable asset. Most likely it will be implemented as an ERC20 token, meaning that it can be bought or sold using the 0x Protocol.

How Grain is Acquired

There are three ways to acquire grain in a project:

  1. Contribute to the project directly.
  2. Financially support the project (either directly, or by buying grain from a contributor)
  3. Own grain in the project’s dependencies.

Grain as Proof of Support

In all of these cases, owning grain means that you’ve supported the project in some way: either via direct contribution, financial support, or by supporting a dependency. Therefore, grain is a proof of support for a project.

Rewards for Grainholders

Projects could choose to reward their supporters, by giving prioritized attention to those with a lot of grain. For example, projects could reward grainholders by prioritizing their feature requests and bugs, or giving them a say in project governance. Crypto projects could even give tokens directly to grainholders. (For example, a cryptocurrency could direct 10% of its block reward to everyone who holds grain in the project itself.)

Rewarding grainholders would be in the best interest of the project: if owning grain confers valuable rewards or access, then more people will want to buy it, increasing the price. This will mean a greater reward for the project’s developers, meaning more people will work on improving the project itself. The result will be a positive economic feedback cycle.

Another way of raising funds for grain-supported projects will be licensing along the lines of a Harberger Grain License, whereby proprietary dependencies of open projects will need to pay a tax, and the tax consists of buying and burning a project’s grain.

SourceGrain as Economic Scaffolding

Thus, grain will serve a lot of economic functions for open-source projects:

  1. It provides a new way to support an open-source project: by buying its grain.
  2. It provides a way for contributors to earn money for their work: selling the grain they earn for contributing to the project.
  3. It provides funding for widely-depended on open-source infrastructure: such projects will earn grain in all of their many dependencies.
  4. It lets users of a project who need prioritized support or access to acquire it, by paying the developers.
  5. It provides rewards for early investors in successful projects, both via grain appreciation, and via dividends from dependent projects.

I think of SourceGrain as producing general-purpose economic infrastructure for open-source projects.

It would not be inaccurate to say that SourceCred exists so that SourceGrain can be a reality. Actually, initially I was thinking of these as a single project. However, over the course of some convos with @jbenet, I realized it made more sense to split the reputation protocol and the crypto-incentive parts into separate projects, much like how IPFS (protocol for storing data) and Filecoin (incentives for storing data) work best as separate but related projects.

Grain Related Resources


So… in the Gentle Introduction to Cred you said that “The SourceCred implementation is a JS-based program that anyone can run.”. Here you’re saying that you’re going to create a crypto asset. Creating a crypto asset requires a decentralized network with cryptoeconomic security guarantees. How is SourceCred going to have a token (Grain), have that token connect to and flow between different projects, and have that token trade on open networks and markets if you don’t have it on a blockchain?

Saying that everyone will compute the SourceCred graph, and then if someone gets a result that’s different than the majority they are out of consensus, is literally the definition of a blockchain protocol. Nodes calculate stuff, the protocol defines what they calculate, if you’re not in consensus then the network ignores you, and the chain with the most consensus is the “valid” chain. For SourceCred to work, and for Cred to be fungible, you need to roll your own “blockchain” with validator nodes performing SourceCred computations and sharing results.

If you want to do all the computation on your chain you could build it on Substrate, then have it checkpointed via Polkadot (which would provide the real cryptoeconomic “finality”). Otherwise you’d have to build a commit/reveal contract where people submit data with a stake attached, then during a reveal phase earn rewards if their data is accurate and are slashed otherwise (like Daonuts is building). Ultimately tho, the data that tokens are based on need to be verified to have value, and you need a bunch of nodes doing that verification otherwise there’s no way to prove if the calculations are accurate, and once you do all that you’ll need to store it on an immutable public ledger so that everyone can verify the history. So… are you guys rolling a blockchain, or is it just a JS project?

The confusion is that SourceCred and SourceGrain are separate projects. SourceCred is a system for assigning reputation scores based on contributions to a project; it’s not feasible to run on a blockchain. SourceGrain is a system for letting projects create their own cryptocurrencies based on reputation scores; it will run on the blockchain (maybe implemented using frameworks from Aragorn, etc).

For each SourceGrain instance, you’ll need some trusted oracle(s) providing the cred scores from the corresponding SourceCred instance. This is unfortunate, because your oracle could start putting doctored scores in. Since the SourceCred scores are reproducible, you’d be able to tell that this happened, and fork the token, or take some other remedy. (But it would be bad.)

Quite likely a staking commit/reveal style game would be an improvement on this high-trust setup. I could imagine there being lots of “cred validator nodes” that are trusted to accurately compute cred scores across many projects, and are rewarded for it. This would remove the need for individual project maintainers to do the update process–even if they are trustworthy, managing important private keys, having good uptime for pushing updates, etc, is non-trivial.


Got it. That makes more sense. Thanks for clarifying :slight_smile:

A post was split to a new topic: What if data disappears?

Notes to self

Since the concept of “Grain” has evolved a lot it would be great to have a History section

  • SourceGrain
  • Mana
  • Grain

Once we figure out the bonding curve stuff we’ll need to add that in here. Just like you can’t separate Cred from the SourceCred protocol, you can’t separate Grain from the minting/redemption mechanism.