changed 2 years ago  
Published Linked with GitHub

SSV network tokenomics analysis

Economics 101

Price is determined ONLY by Supply & Demand, thus only those effects that change either of the above have any effect on price.

\(Price(S,D)\)

We can increase \(Price\) by either, making \(S\) go down or \(D\) go up or both. The inverse is true for decreasing it.

Important takeaway is to always look for what changes if any has a particular mechanism Supply or Demand.

Value transfer mechanism

Direct effect

The Token total supply in the system can be thought of as a sum of all agent's balances \(B_{a}\) in the system.

\[ \sum_{i=1}^n B_{ai}=B_{a1} +B_{a2} ... + B_{ai} \]

All of these mechanisms facilitate transfers between agents in the system. Here is a basic example, where Staker pays Operator for his services. For simplicity's sake we disregard the network fee for now. We can say that Payment \(P_i\) is subtracted from Staker's Balance \(B_{s}\) and added to Operator's Balance \(B_{o}\)

\(B_{s}\) - \(P_i\) , \(B_{o}\) + \(P_i\) \(=>\) \(B_{a1}\) + \(P_i\), \(B_{a2}\) - \(P_i\) \(=>\)

\[ \sum_{i=1}^n B_{ai}=(B_{a1}+ P_i) +(B_{a2}-P_i) ... + B_{ai} \]

…

What is easy to spot but important to note, that these payments have no effect on the overall sum of balances as they will always net each other to zero.

Thus all payments within the system within certain time window can be added separately or netted for each agent, to be a pure inflow or outflow if negative payment \(P_{ai}\) of a particular \(Agent_i\) but their sum will always be equal to zero.

\[ \sum_{i=1}^n P_{ai} = P_{a1} +P_{a2} ... + P_{ai} = 0 \]

Thus we can say that pure transfer payments within agents in the system have no direct effect on either Demand or Supply, thus no effect on price. They also do not change Total supply, thus no effect on MCap.

Special case

There is a special case, where token transfers have direct effect on the price. That is, if some part of the supply is taken permanently off the market, thus decreasing supply. In our case this would be network fees that are burned.

NOTE:
If fees are used by the governance to fund protocol or whatever else, they have no effect on the token price, as they are only redistributed.

Indirect effect

Increased demand

The ONLY reason why using a native token for value transfer has an indirect effect on MCap is because of transaction costs and system inefficiencies.
If and only if a new user (\(Agent_{i+1}\)) wants to use the system, he needs to acquire some tokens, thus increasing Demand \(D\), thus having positive effect on token price.

It is also important note that in a perfect world forcing users doing transfers in a native token has NO effect on the price.
Why?
Because an agent \(Agent_{i}\) has a set utility preference \(u_i()\) for holding \(Token_x\) at \(T_0\) which will amount to \(u(Token_x)\) = \(B_x\) . Thus he may be holding a non-zero Balance \(B_x\) of a given token, but there is no reason to believe that using the system would make him more or less bullish on the project since this is already reflected in his utility function. Thus the rational thing for him to do is to buy every block only the amount he needs for the payment within this block. If he were to buy more, he would increase his exposure above his \(u(Token_x)\) and desired target balance \(B_x\) .
Conversely if he did not buy more he would be decreasing his exposure below his target balance.
Of course to buy a specific token on a block-by-block basis is impractical and unrealistic.

Thus it is reasonable to assume that a part of agent's balances \(B_{a}\) is a balance used for transfers.
NOTE:
Even though we do not live in a perfect world it is important to be cognizant of "unnaturallity" of this demand, since it is dictated by system inefficiencies thus it is unstable, since it does not correspond to agents' utility function.

In SSV only Stakers need to hold a balance for this purpose, lets call it transfer balance \(B_t\) since, they are the only agents in the system with outflow of payment within it. Neither Governance, nor Operators perfom any transfer payments.
Thus what we are looking for is a cumulative sum of transfer balances for stakers \(S\) (s of n) \(\sum_{s=1}^s B_{ts}\) at a specific time \(T_0\).

The question then is, what will be the the expected ranges of:
number of validators \(num(V)\)
what will be the average price per validator \(avPrice(V)\)
and what would be the the average runaway \(avRunway(V)\)?

thus we need input into this function that we need to find are as follows:
\[ B_{ts}= avPrice(V)*num(V)*avRunway(V) \]

Important to note here, is that stake operated by private Operators needs to be substracted. Thus we need to find \(privateStakeRatio\) = \(privateStake/allStake\)
as well as
\(operatorFeesRatio=Operator fees / total fees\),
since total fee will include \(networkFee\) which should not be subtracted.

To subtract privateOperators:

\[ B_{ts}= avPrice(V)*num(V)*avRunway(V) - privateStakeRatio*operatorFeesRatio* avPrice(V)*num(V)*avRunway(V) \]

Decreased Supply - Token stickiness / inelasticity

We can observe in the market that there is a certain "token stickiness" in the market. As reported in this article after a token airdrop, the MCap of the project usually goes up. This may be obvious but is not rational, thus should be accounted for in any system that supposes rational agents.

Why this should not be so?
Because an agent \(Agent_{i}\) has a set utility preference \(u_i()\) for holding \(Token_x\) at \(T_0\) which will amount to \(u(Token_x)\) = \(B_x\) .
There is no reason why a sudden helicopter money (airdrops) should affect his utility function \(u(Token_x)\), thus a rational thing for him to do is to sell the whole airdrop, push the price down, thus have no effect (or negative) on the MCap. In practice and especially in the bull market this does not happen.

Stickiness could be defined as a ratio of tokens received either (from airdrops, payments, as gift, etc.) but not sold. (the ratio assumes non-zero stickiness, obviously)
\[ stickiness = \frac{tokensReceived-tokensSold}{tokensReceived} \]

Thus if an a token stickiness is 10% or 0.1 we can expect an agent receiving 100 tokens to only sell on average 90 and keep 10.

In our case Operators are the ones receiving tokens. It is hard to say what would be a stickiness of rewards received, since operators are forced to sell in the long term to cover their expenses, however the actual cost of running one would probably be negligable for most.
It is also hard to say how usefull would be this, since in times of stress Operators' reserves that seemed to be sticky during good time can easily cause huge market dump.
This can contribute in pronounced price volatility and system instability

Systemic effects

Increased volatility

token volatility

  • "sticky liquidity" may turn out not to be so sticky in times of stress and be dumped

fee volatility

  • fees change based on the token price
    • there is inherent mismatch between staker's profit in ETH and cost in SSV. He either needs to take on this risk or hedge it. Both are costly and bad UX
    • Sudden fee increases / drops bring perverse incentives and inefficiens into the system that are insuficciently addressed by feeUpdate().

Worse UX

system defualts to higher fee equilibrium

  • automatic real fee increases caused by the rise in SSV price leads to higher fees
    • raise of operator fees due to SSV price increase is different to manual increase triggered by the operator
      • this is so, because the fee increase in this case is coordinated, put simply all operators raise fees at the same time
        • since this new price equilibrium is set automatically operators need to "defect" from it which would go against their own interests.

Example Scenario:
Price movement:
SSV price goes up 100% in two weeks

Operators:

  1. Operators are super happy suddenly they are making 100% more.
  2. Now if Not more than 50% of stakers were to change their operators, operators are still making more than 2 weeks ago and it makes no sense for them to lower their price.

Stakers:

  1. Can we expect at this point that staking services are able + willing to change operators at moments notice at this stage? Is it a good UX?
  2. Who would they changed to? This is basically synchronized raise of prices of all operators, thus all large operators suddenly charge 100% more and unless more than 50% of stakers would leave them, they are making higher profit than before.

Effects:

Who has an incentive to defect from this new equilibrium?

The only actors with incentive to defect are operators managing small amounts of validators who want to gain market share.

Can we expect at this point that stakers will move their services to small lesser known operators?

Even If they started doing this in mass this may have the effect on incumbent operators to somewhat lower their prices.

Is this the UX we want the stakers to go through?

Barriers to entry

Stakers need to buy token in order to use the system

Takeaways

  • Using native token for value trasfers (utility token) has no direct effect on MCap
  • It has indirect effect on MCap by creating Demand pressure. This is however unstable
    • We can Calculate size of this demand, if we can come up with reasonable ranges for the variables
  • It introduces higher tx costs for agents
  • It makes fees more volatile for the stakers

—

@Fod’s takeaways/ Marko’s points

  • Using SSV as the utility token worsens UX, and we want to make the UX as good as can to maximize the number of users.
  • If SSV is used as a utility token, it creates volatility in several ways (breaking of “stickiness”, selling when price changes, needing to keep operator fees stable/operators needing to change fees often.
  • Having the SSV as a utility token has weak value through “stickiness”, etc., but this is irrational and unreliable, and therefore it doesn’t really add much value.
  • We can have the SSV token as a governance token, where ownership is incentivized through a staking mechanism and other incentivization mechanisms.
  • The network fee drives value to the SSV token regardless if its used as a utility token or a governance token.
  • Therefore, we might want to use ETH (or other ERC-20) as the fee payments.
  • How practical is this change?
    • We might be able to copy and paste from RPL.
    • We might only have a month before audits.
Select a repo