RFC 57: Safecoin Revised

I think best would be starting out with the most basic criteria:

  • the network should never run out of coins
  • the network should never fill up

NOTE: As @neo has noted, I messed up the order of these points but you’ll figure it out :slight_smile:

The first point could be guaranteed if the PUT price approached infinity when running out of space, so we’d want “free space” (or a suitable proxy) in the denominator for the price function.

Similarly, the second point needs that rewards approach zero when running out of coins, so we’d want “free market cap” (or a suitable proxy) in the numerator and/or “coins in circulation” (plus constant) in the denominator for the reward function.

We’ll just need to shoehorn in whatever desired behavior is not achieved by the above, though they already do most of what we need, I think.

Then, some parameters, e.g. what should the theoretical maximum reward be (when there are no coins in circulation) or how flat the price / reward rise should be when we’re not near the extremes (very empty or very full network, very few or almost all coins used).

Then, some technical details: smoothing out changes (averaging over time, Kalman filtering, etc), including some headroom for the storage space (just in case), and so on.


The big question is, do we need to connect the storage cost and the farming rewards at all, or could they work as two independent sides? Could it lead to chaotic oscillations and, if so, can it be stopped? (For example, one side could be dampened using a much longer period than the other.)

7 Likes