Proposal to exclude Change Reserve from the desktop wallet


In the current Veil protocol, stakeable Zerocoins exist in fixed denominations, 10, 100, 1000, etc. With RingCT, coins will reside in UTXOs. To provide for anonymous staking, ranges of UTXOs will be stakeable, i.e. UTXOs containing 0 to 10 Veil, 10 to 100 Veil, 100 to 1000 Veil, 1000 to 10,000 Veil, etc. (The specific ranges have not been defined but for the purpose of this discussion assume the above hold.)

The veild software will ensure that if the user had 50,000 Veil in a UTXO, they would get split into five UTXOs of 10k for efficient staking.

Change Reserve

It has been proposed that the wallet UI allows the user to define an amount of Veil that is “always spendable”. This is called the “Change Reserve”.

What’s the motivation for the Change Reserve?

Imagine that a user has two UTXOs, each containing, say 500 Veil that are staking. While they are staking, the full balance of 1,000 Veil is spendable. However, if one of the UTXOs wins a stake, then its balance for a period of time will be unspendable. (The number of blocks for a spent stake to mature, i.e. the immaturity period, is still TBD.)

During this period of immaturity, the maximum Veil the user could spend is 500 Veil, because the other 500 is immature and unspendable.

The concept of the Change Reserve was proposed to allow the user to set aside a certain amount of Veil that would be always spendable, and, hence, not staking.

Downsides of a Change Reserve

Supporting a Change Reserve feature carries the following downsides:

  1. We have to communicate to the user why the Change Reserve exists.
  2. The user will need some understanding of how their staked balance is segregated into staking ranges in order to even know if they need to set a Change Reserve. (E.g. if I have ten 10k UTXOs, it’s unlikely I even need to set aside a Change Reserve.)
  3. We have to design the UI workflows to allow the user to manage the Change Reserve
  4. We have to communicate to the user that their total spendable balance is the Change Reserve plus that portion of their staked balance that is spendable.
  5. We have to design for the edge case that a user’s balance is within the first staked range, such that if they set any Change Reserve amount, then they won’t be able to stake anything.

Supporting Change Reserve complicates the user interface, and burdens 100% of all users with concepts to understand, all in order to protect against a set of circumstances so rare as to likely only ever affect a tiny segment of users:

  1. The need to spend right now, and can’t wait.
  2. A portion of their staked balance just staked, is immature and unspendable.
  3. The resulting staked (spendable) balance is less than the amount they need to spend.

Proposed solution