# Thoughts on State of SSV Tokonomics
*The below are some of my thoughts on [Fod's](https://hackmd.io/@fod/SJPzQ5SCo) open letter on SSV's tokonomics and potential roadmap.*

## Current tokonomics and assumptions

Today's staking industry seems to have hit some **equilibrium price for infrastructure** (Lido set it to 5% of rewards). This means that with any fluctuation of ETH price or APR the rewards should go up and down with the same ratio.
Lido (and others) solved this issue by paying operators with stETH which is pegged 1:1 with ETH and is updated via oracles to the current APR.

The SSV model mimics the above, operators are free to charge what they want but are bound by market ask/demand which will dictate some equilibrium point.
With SSV there is another degree of complexity which is SSV/ETH price.
This seems to require users of SSV to be exposed to SSV/ETH price since they need to purchase some SSV, load it to wallets and keep some collateral in place as well (as fee wallet funding).

If we compare to other protocols we can find both native and protocol examples. Both shown to be successful.
Every L1 out there requires its own protocol token for transactions.
Ethereum itself requires ETH for every ERC20 (and other) transactions.

| Fee Token | Pros | Cons |
| -------- | -------- | -------- |
| SSV | Value capture, Greater SSV exposure for users of the protocol | SSV/ETH volatility |
| ETH | Simplicity, requires 1 token, APR peg | ETH not staked, Reduces SSV value capture(as a network) |
| Stable | No exposure to volatile asset, Easier UX | Stable/ ETH volatility, Reduces SSV value capture(as a network |

## SSV/ETH movements
For the sake of analysis below we consider the ETH staking APR constant.

At time t the price of SSV/ETH is $P_{t}$ and the cost for 1 block for using the SSV network is $BP_{t}$.
If at time t+1 the price of SSV goes up relative to ETH, $P_{t+1}$ = $2P_{t}$, the price per block will be $BP_{t}$+1=1/2*$BP_{t}$.
**Users are happy as they extended their runway usage of SSV by a factor of 2.**

If at time t+1 the price of SSV/ETH drops by 50%, $P_{t+1}$=1/2*$P_{t}$, then $BP_{t+1}$=2*$BP_{t}$.
A prudent user could hold the bare minimum in its fee account and top it up periodically to reduce (almost to 0) its SSV/ETH volatility exposure.

One could argue that ethereum users are already used to price volatility when it comes to transactions. The chart below shows ethereum gas prices for the past 5 years, in periods of high demands we can see gas price spiking 5-15X.
If today (March 2023) the price of an [SSV transfer](https://etherscan.io/tx/0xab3a83e9a2397b67f6414b4cce0ccd71474b40650df530b154c25006f1a2f5ae) is ~$2, in periods of high demand it can go up to $10-$30 in today's ETH prices. If ETH price goes up 3-5X, users could see 15-75X price increase for simple ERC20 transfers(as high as $150).

[](https://ycharts.com/indicators/ethereum_average_gas_price)
(click for source)

## SSV/ETH movements - Example
To illustrate SSV/ETH volatility i've simulated 3 SSV/ETH price scenarios and their effect on total SSV paid as fee.

**Case 1:** SSV/ETH stays in constant ratio for 12 months. In that case the SSV amount paid as fee will be: Fee = (32*$ETH_{APR}$ * $FEE_{APR}$)/(SSV/ETH)
$ETH_{APR}$ - 12 months APR on ETH staking
$FEE_{APR}$ - fee as percentage of APR (e.g Lido takes 5% to validators out of APR)
SSV/ETH - SSV's price relative to ETH
In the [example](https://docs.google.com/spreadsheets/d/1HveEB9fwFltS_c3lIWW4V7acL8cxtXwyAatLmY2tIBM/edit#gid=0), as a reference, it will be 3 SSV/ year

**Case 2:** SSV/ETH price increases by 45% throughout the year. Following the [example](https://docs.google.com/spreadsheets/d/1HveEB9fwFltS_c3lIWW4V7acL8cxtXwyAatLmY2tIBM/edit#gid=310588938) we can see that the amount of SSV paid in fee is reduced throughout the year. Total yearly fee will be 2.5 SSV (17% less)

**Case 3:** SSV/ETH price decreases by 45% throughout the year. Following the [example](https://docs.google.com/spreadsheets/d/1HveEB9fwFltS_c3lIWW4V7acL8cxtXwyAatLmY2tIBM/edit#gid=218735001) we can see that the amount of SSV paid in fee is increased throughout the year. Total yearly fee will be 4 SSV (33% more)

## Abstracting fee payment
There is a function in the SSV registry contract for private operators that can set fee to 0. It enables operators to whitelist access for a specific address that can register validators to them (could be a contract).
By setting fee to 0 they can handle fee payment outside of the SSV registry contracts.
This opens up the opportunity to use ERC20 tokens as fees, off-chain credit card payments (and much more) while enabling complex fee structures that already exist with protocols like RPL who pay both in LSD and RPL rewards.

**[Example] External fee contract:**
- An operator wants to get paid in a random ERC20
- Sets a smart contract to manage fees outside the SSV contracts, a.k.a fee contract
- The fee contract requires min X ERC20 tokens deposit to add the user to the whitelist (that will enable it to register validators)
- User can register validators to the operator, paying in any ERC20
- A small network fee in SSV is still required

**[Example] External off-chain fee payment**
- An operator sets a contract to whitelist who can register validators to it
- A centralized entity controls the above contract
- The entity pays the operators on a monthly basis with USD via wire

Abstracting fee payment is like using L2 on ethereum, there is still some fee paid on the L1 chain (SSV network fee) but the majority is externalized to an L2 (in our case a different contract or off-chain payment).

# It's all about usability
At the end the goal should be the create the most usable DVT implementation out there. To that end SSV should enable what developers need to create successful staking applications on SSV.

Handling complex fee structures with various assets/ methods is one of those enablers.
The best parallel is ethereum externalizing some of fee to L2s in favour of higher tps which will increase the overall use of ethereum. Same goes here with SSV and fee abstraction.

# Summary and final thoughts
SSV/ETH volatility can produce friction for users at the beginning as it will require them to buy and re-buy SSV on the open market with the hopes of flattening the fee charges.
Bigger protocols like ethereum have similar volatility but enjoy a wide spread token holder community which seems to reduce that friction point.

I believe we should make SSV as approachable and easy to use as possible, in that fee management is critical.
I believe fee abstraction could be a big step forward.
As an intuition i feel that network fees should remain in SSV, operator fees should be abstracted.