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.
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.
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.
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) \]
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
token volatility
fee volatility
feeUpdate().system defualts to higher fee equilibrium
Example Scenario:
Price movement:
SSV price goes up 100% in two weeks
Operators:
Stakers:
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?
Stakers need to buy token in order to use the system
—
@Fod’s takeaways/ Marko’s points
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe