SMT Vesting

Stability

Let p be the pot (total_vesting_fund_steem), and c be the claims (VESTS). Let r(p, c) = c/p be the exchange rate (number of claims per pot token). Suppose the pot increases by Δp = kp. Then:

r(p + Δp, c) = c/(p + Δp)
             = c/(p + kp)
             = c/((1+k)p)
             = (1/(1+k)) (c/p)
             = r(p, c) / (1+k)

To keep the percentage increases bounded, we must remove small-p situations from occurring. To do this, I propose initializing the pot with some "ballast" of claims and tokens, c_0 and p_0, respectively. The purpose of the ballast is to provide stability to the calculations by bounding the possible percentage increase of the pot.

The ballast is not owned by any user, and cannot be withdrawn. Since the balance tokens can never "escape" the pot, they can never be directly interacted with. The ballast will cause effects on the vesting exchange rate, supply limitation, and percent-of-supply emissions. Whether the ballast "exists" is actually a semantic question that depends on precisely what is meant by the word "exists."

What is the worst-case exchange rate? The worst-case exchange rate occurs when the remaining tokens, max_supply - p_0, are emitted into the pot. In this case, we have an exchange rate of r(max_supply, c_0) = c_0 / max_supply. If we want to limit the worst-case exchange rate to some value r_min, we must set r_min = c_0 / max_supply. Since r_min and max_supply are settable parameters, this implies c_0 = r_min * max_supply.

But of course we cannot allow c_0 to become arbitrarily large, since the worst-case number of claims occurs when the remaining tokens, max_supply - p_0, are emitted into user balances, and the users then vest them at the large initial exchange rate r(p_0, c_0) = p_0 / c_0. Since the exchange rate doesn't change, we have r(max_supply, c) = r(p_0, c_0), which can be re-written as c / max_supply = c_0 / p_0 and solved to find c = max_supply * c_0 / p_0. Substituting c_0 = r_min * max_supply, we find c = max_supply^2 * r_min. If our integer data type cannot hold integers greater than max_value, this means we have the following constraint:

r_min * max_supply^2 <= max_value

The upshot of this is that claims need to use 128-bit values in general case, and max_supply cannot be too close to 2^64 if we want r_min to be large.