Grain seems like a smart distribution system once Source Cred is good enough (I would argue it’s already good enough to experiment). I really do think you could start with small amounts.
There’s a higher activation energy for creating Grain, since I also want the smart contract to have some particular properties:
- It’s possible to send a dividend to grainholders with O(1) cost (i.e. it doesn’t matter how many accounts hold that grain)
- The dividends accumulate recursively, i.e.:
- at t0, a dividend of Bar was sent to the holders of Foo
- at t1, a dividend of Zod is sent to the holders of Bar
- at t2, a holder of Foo should be able to retrieve a dividend of Bar, and a divided of Zod (which they transitively own because of the Bar that was owned by them at t0)
I spent some time thinking about this back when starting up SourceCred, and I’m pretty sure I’ve worked out a construction with good properties, where basically when a token produces periodic “dividend claim checks” tokens which accumulate the right to withdraw dividends from the pool. Then there can be liquid markets in the “claim checks” so that your average contributor doesn’t need to do the mechanics (and pay gas costs) for receiving all the small transitive dividends they’ve earned, they can sell the claims checks and market makers can do it efficiently at scale. Implementing it and testing it will take a while, though.
If we wanted to demo grain, we could just make an ERC20 token that is a placeholder, and then fork/migrate to a new contract when we’re ready for it. I like the idea of just paying out ETH to start though, it’s simpler.
That’s one way to do it. Another would be to automatically set up a wallet for each contributor. Then just somehow send them the private keys. Perhaps use multi-sig transactions.
Seems safer to never be sending the private keys over the internet. Also for some users this might be their first ETH address, and they might then do the very bad thing of using a wallet whose keys they got from someone else as their de facto main wallet. Better to not encourage bad habits, and instead have them generate the wallet and then we can send to it.
I don’t know if any of these systems remove trust entirely. If we just created wallets for each contributor, and send them the private keys when they contact us, then they don’t have to trust us. They can move those funds to a wallet only they control at any time.
Let’s suppose evil me sets up a cred donation instance for ETH developers. I do a good job building community and being really responsive to making the parameters work well, and so people start routing more and more funding through my portal. I get to the point where I have say, $100k/month in donations. Then one month I take all of the money and run, rather than sending it to real developers like I did all the previous months.
Shower thought (literally): Source Cred already has temporal information. Maybe this is kinda hacky, but you could just run the ranking algorithm up till different points in time
Yep, I describe a similar proposal in the other thread.
But what if, as we reinvent money, non-fungability becomes a desirable trait for some use cases?
This is an interesting idea, and also one I’ve been riffing on in my head. Fungibility can be a big problem, e.g. if I donate $1000 dollars to you with the goal of saving pandas, nothing stops you from spending it on a jet ticket to the Bahamas, due to the fungibility of money. What if we could make non-fungible money which tied it to a particular purpose? So every transaction of “save-pandas money” would need to include a compelling proof of why using the money in this way helps save pandas. Maybe once it’s produced a certain number of hops in save-pandaness it starts to regain fungibility, so that people who don’t have saving pandas as a terminal goal are still inclined to accept it in exchange for goods and services.
There’s also no reason in theory cred couldn’t be fungible and exchangeable. I don’t think so. Consider the cred I earn for writing this particular post. It’s not fungible with the cred that I get for fixing a bug today in SC, because they will vary independently. Maybe this post winds up being important to our future plans and so the cred for writing this post keeps on getting more and more valuable, vs maybe it turns out that my bugfix was poorly written and actually introduced more bugs, and so the cred for that PR later gets devalued to 0. Non-fungibility.
I think even managing grain and a Source Cred instance within a project, you’d run into governance issues.
Yes, totally! But if every project has its own governance problem, the system can robustly adapt as individual projects find good approaches to them and others can then adopt those practices. If we create a single unified instance, then it’s much more likely to get stuck in a terminal bad state and not be able to adapt. The robustness of decentralization.
I think MakerDAO has proved a system that is limited to voting on a small number of key parameters (via active voting).
This is another side discussion, but I don’t like MakerDAO’s governance model, for the same reason: it centralizes too many decisions with the same group of voters. I think that once MakerDAO needs to set parameters for N different currencies, the groups skin-in-the-game towards any individual paramter choice will not be very high, which will create an opening for lobbyist type people with an interest in moving particular parameters to exploit the system. I think MakerDAO would be more robust if every currency that gets added had its own “MKR” token equivalent (MKR_ETH, MKR_BTC, …) and then the holders of any individual token only vote on the risk parameterization for that particular collateral.
One could imagine limiting the voting to what weights to give the ranking algorithm, for instance.
I imagine that running a high-quality distribution will involve a lot of manual configuration of the graph, e.g. creating nodes that represent project level priorities and core infrastructure, and then connecting those nodes to individual pull requests, commits, parts of the codebase. It will be a lot more than voting on a few individual parameters. Take a look at the Odyssey hack design doc for an idea of what we’re thinking about.
If the weights were gamed, since money is invoved, contributors would be incentivized to quickly come vote out the scammers.
Kind of like how voters in real democracy are incentivized to quickly vote out corrupt politicians? 
OSCoin looks very interesting. I’m not sure distributing cred at the project level is the right level.
Yeah, I agree. I talked to the founders about this a little while ago; they made the case that maintainer-ship is the bottleneck for OS projects, so only paying maintainers is fine. I disagreed, because even if this is approximately true right now, it creates really weird power dynamics and social dynamics and will be hard to fix down the line. Having read about your experience with the stickiness of power dynamics in a ‘guild’ I’m further convinced that doing distributions just on the project-level is a mistake.
Cred (which could exist permissionlessly outside of IP laws), would essentially assign a micro patent on every contribution, which distributed royalties in perpetuity to the contributor (or whoever owns rights to that cred).
Yes, with the caveat that unlike the American patent system, you cannot use your holding IP to restrict others from using it, ever. You can just request (or assert?) a right to the share of the value created. If I have cred in something, it should be impossible for me to use that to prevent you form releasing open software or IP on top of it. (Open == freely usable and accessible.)