(You can see more detail on the calculations in the notebook.)
Changes since Week 1
Alpha
As discussed here, I’ve changed the alpha used by SourceCred from 0.05 to 0.20. Alpha determines how “far” cred will travel on the graph, away from its source nodes. With the low alpha of 0.05, cred travelled very freely, including getting into some strange tight loops for users who had very little activity; I discussed these issues here and here; in both cases, users with very few discourse posts were getting a disproportinately large share of the Discourse cred.
If you’d like to explore the effects of changing alpha, you can tweak it yourself in the live SourceCred instance. Alpha is now included as one of the weights.
Payouts in mana
In contrast to week 1, I’m now denominating the payouts in mana rather than dollars. $1 = 100¤. The redeemability and cash value is the same, it’s just a swap in what quantity gets displayed first.
Adaptive slow payments
Now that we’ve had our first retroactive cred adjustment, the “adaptive/slow payout” mechanism kicks in! You can see how since my cred adjusted upwards, I get a larger slow payout, whereas others who had their cred adjusted downwards get a small (or 0) slow payout. Also, people who got a large weekly payout but haven’t been with the project for long may get a small slow payout.
Take a look and feel free to ask questions! Also, let me know if you’d like to redeem your mana for cash (you can post here, or send me a PM on the forum or via Discord).
I like the simplicity and implications of that. All money poured in / all cred earned = the value of 1 cred
This means if the project suddenly grows it’s budget, everyone gains. If it grows the budget over time, people who’ve also grown their cred gain proportionally.
Should everyone collectively stop being active in the project, which would keep a steady slow payout, while there’s till payouts happening. The fast portion of the budget should provide incentive for people to resume working on the project.
The adaptiveness also was very quick to rectify the changes in alpha. It “needed” $420 to do so, and since it had $400 to work with got pretty close in the same week the change was applied. I guess you can consider that a general property of this ratio. Having 4/5ths of the budget be adaptive will be quick to catch up with any differences.
const underpayment = target - past - fast;
Including this week’s budget and the fast component in the underpayment value is pretty interesting. In a way that makes earning cred a little faster than just the fast component. As being pretty active this week means you should see a similar increase in the totals.
Preliminary conclusion
I like the way it’s set up, and the parameters.
Catching up quickly with differences is a good property for the experiment when you’d like to change the cred algorithm or parameters. But in the future as well if the algorithm and parameters are more stable, it means you have significant leverage to moderate/curate whether positively or negatively.
Having the “double fast” effect where recent contributions will also show up immediately in the slow payout makes it intuitive the slow payout should be the majority of the budget.
They’re also very much tied to each other now. The fast and slow components don’t make sense independently anymore. Though that’s fine. I think they serve their purpose.
Time to publish the code from this notebook into a package and require('@sourcecred/payouts') next?
Yeah, but consider that it was using 1 payment to “catch up” on 1 previous payment. If there had been 10 weeks with the old alpha, the adaptiveness would take a few more weeks to catch up.
Yeah, I considered going the other way (calculating the adaptive payment while not considering the fast payment–like running them in parallel rather than sequence). I felt this way was slightly conceptually cleaner.
The slow payouts are calculated weekly, but are based on lifetime cred, not weekly cred. I do intend to increase the payment sizes in the near future as I believe they are too small right now. Does that answer your question?
Neither mana nor cred have a half life, in the sense that they do not “decay”. However, they do “dilute”, as more mana and more cred are created over time. The value of the project should increase faster than dilution, so that neither mana nor cred tend towards irrelevance.
It’s possible that mana will dilute faster than cred, but this is far from assured. I think the ratio in the mana->cred conversion process (boosting) will be very important here.
Oh I just saw that I had a 0 for the slow payout in week 2 because I was MIA the week before. If it was averaged over the course of a month vs a week it would “fix” that (for me). Maybe the week to week thing incentivizes more regular contributions though?
Is there a separate post somewhere discussing the economics around cred/grain (supply schedule, price discovery, how value is captured, etc…)?
If not, something like this would be good to create in the context of a post announcing the new grain/cred names
I think that’s much more because alpha was changed than because you were MIA for a week. When I boosted alpha, it meant less cred flowed to you along edges.
Good idea. I’ll try to write one soon. It’s tricky because I’m still figuring out some of the mechanics in my head. (And looking forward to get to chat with @mzargham about them.)
Please do! I’m very very interested in this and would love to join in on the brainstorms if there’s room. Maybe we could start a thread outlining how the current process works, and then the community could weigh in with thoughts/suggestions for improvement, and then based on that another post would be created “announcing” the cred/grain token model
edges.