The Bounty Valuation Equation

[historical post via ]   This is a companion post explaining the math behind our new improvements to bounty valuation. Read more about the feature.

We have designed a bounty recommendation system that attempts to balance numerous, sometimes conflicting, goals. Early contributors are awarded proportionally more than later ones, reflecting the increased value of the product. The range of bounty offers scales exponentially. We discovered that Assembly Users ‘in the wild’ assigned bounty values roughly according to a power law distribution. We have drawn from users’ instinctive behavior to design the recommendation system.

The recommendation system is not a departure from the previous model. It is merely an additional layer that offers guidance. Users are free to add custom bounty values as before. No matter whether they choose a custom value, or a suggested one, their choice counts as a vote in the same weighted-average schema. Thus, as before, users with large ownership fractions have more say in valuations than users with little ownership.

As products mature, the suggest bounty values decline according to a sigmoidal curve. They settle down to a minimum base value. This is a continuous, gentle way to capture the growing maturity of a product. It’s only a rough estimate, however, and should never override realities experienced by contributors.

Below is an example of a sigmoidal curve with a minimum baseline. The X axis, in our case, represents the maturity of a product, as measured in bounties awarded.

The five increments of suggested values scale exponentially. This reflects the power law distribution observed earlier in historical bounties. In other words, exponentially expensive bounties are exponentially rare, whereas dramatically cheaper bounties are dramatically more common.


Products that are profitable have bounties calculated differently. We take the average income per month in the product’s history and extrapolate to average yearly profits. Then, out of the five suggested increments, we normalize the middle increment to a reasonable dollar per year value. As before, higher and lower increments are exponential multiples of that middle increment.

We figured that, with products like Coderwall for instance, there was no need to use extremely fuzzy metrics for ‘maturity’ when hard data existed as Dollars and Cents.

Coins for new bounties are always awarded out of the pool of unvested coins for each product. Since each product starts out with some small number of coins (typically 600,000), there are a large number of unvested coins (9,400,000 in this case) available to be awarded in bounties. For unprofitable products, the internal calculation for suggested bounty values takes into account the number of remaining unvested coins. This means that, as products mature, fewer coins are unvested, thus bounty rewards should be lower.

If a product runs out of unvested coins, it may issue more in a discrete, ‘dilution event’. We decided that dilution should occur infrequently, in explicit, discrete steps, to protect owners. Owners who bring profitable products onto Assembly should rest assured that they will not be diluted in an uncontrolled process. By specifying unvested coins, that can only be increased rarely, it is always possible to know the maximum extent of one’s own dilution. This makes coins more valuable, and the whole system more robust.

No algorithmic answer will work comprehensively for valuing people’s work. We can’t capture the breadth of possible use cases in five simple choices. Use this tool as a rough guide. But in no way feel constrained by it. Ultimately, if you’re an owner, you get a say.

Try it out live and let us know what you think. Ping @vanstee or @abarisser on Twitter with any questions or feedback.


By Andrew Barisser

About the author