Utility is the first of the three principles of tokenomics in the Demand-Side Tokenomics framework.
This thread is dedicated to identifying, quantifying, and evaluating the utility of proposed functions of the SSV Network protocol. For each, we want to identify:
the total addressable market, in dollars
percentage of the TAM addressable by SSV
each group of participants in the protocol
the utility to each of these groups of participants
The other two principles of tokenomics, value capture and economic security should have their own threads where utility functions can be evaluated with respect to each of the principles.
The main utility function currently generated by SSV Network is the facilitation of a marketplace for buyers and sellers of ETH staking services.
Total addressable market of ETH staking services is directly proportional to Ethereum fees, which are paid out to ETH stakers. As of Feb 24, 2023, daily fees are ~$7m, or $2.555b annually - the present TAM of this utility function. Fees vary with market conditions, so $2.555b is a conservative estimate of the total addressable market for the utility function of SSV Network as the facilitator of a marketplace.
The percentage of TAM addressable by SSV Network is technically 100%, subject to competition with other staking protocols, solo validators, institutions.
The groups of participants in this marketplace are stakers, and operators. There is room for the DAO to adjust parameters of this utility function, but at the cost of decentralization, and possibly some utility to both groups of users.
Utility of the marketplace function of SSV Network is in matching and ensuring the good behavior of stakers and operators for each other. While the Ethereum blockchain is ultimately the escrow agent of funds, we may say that the escrow service provided is part of the utility function that SSV Network provides as a marketplace for staking services.
SSV Network might provide other utility (dynamic parameters per Marko, validator derivatives per Sheldon) which should be included in this thread.
I just wanted to say thank you for providing your thoughts. This is great, and I hope you continue to provide your valuable input. For everyone who hasn’t heard of EatSleepCrypto, he has many solid writings and talks on the subject of tokenomics.
SSV has great properties to anchor it to ETH mainnet trends but balancing productization and tokenomics is a significant challenge. The utility of the token itself may be desirable to expand for the sake of stability, but consciously that can hurt productization because of the risks acquired. Please hear my comments in the context of tokenomics, where an economy of money is the first priority and an economy based on that money’s velocity, ie operation and utility, is the second priority, if not tied for first.
Through our discussions, I’ve cited a handful of considerations that I find valuable, mainly dynamic self adjustment, where an epoch would map a scope of time for each validator (not each operator) and the DAO would have a cadence of access to change the epoch, but no requirement to regularly attest any config/network:
In this equation, we see a ratio of activity rolling in ETH validators joining and leaving the network, a ratio of valid/invalid signatures of an operator threshhold, and an inclusion of ETH gas at the base and [up to the] burstable block size of 30M gwei. This ensures that large blocks would not harm the SSV network over time, where validator costs could increase without SSV incentives/changes. Additionally, I believe this would mitigate some volatility as long as the main epoch is 30000 blocks or less, approximately 100 hours. The “minimum viable signatures” could be maintained with broadcasts or a series of parties responsible for segwit, likely the validators/operators of last resort.
I believe this is worthwhile but I’m not sure how to manage the mini-epoch where validators would need to add a module for caching/reading messages at the point of round change (so that they can maintain validator joining/leaving stats), meaning that no SSV reward would be feasible until that broadcast was observed. I’m being honest about my unknown unknowns here: if there’s any broadcasts from ETH or SSV that note a validator joining or leaving that should satisfy the requirement as long as the mini-epoch is ≤50% smaller than the epoch in the right side of the equation.
ETH block headers are a lightweight recommendation to consider [for validators to monitor/cache/trust] but it hasn’t been confirmed what hardware requirements would be needed for gaslimit and gasused to be monitored over a larger number of blocks (30k??), or by a sequence of roots from prior blocks the size of the mini-epoch.
Other concepts were lightly discussed/dismissed, including but not limited to:
-adding a second identity value to SSV operators for future tagging and obfuscated data tooling (opt-in)
-requiring buyers of last resort to run a minimum of 3 validators, granting them special treatment for offnet engagements with a foundation (central planning not recommended)
-requiring other values from ETH block headers and calculating a “stability ratio” somewhat like the equation above, but with price replaced by a “network health” number (too big of a businees/value pivot). I’m wording this poorly but it’s the idea that user/operator stats on ETH could be provided by SSV before that data is visible/settled on ETH, however that would be data visible to all SSV operators, a dicey thing for a[ny entity like a] central planner. Realistically, the foundation could pivot on this model and become compliant as a central planner and arbiter if desired, but we don’t recommend that for longevity sake, and recommend similar options be discarded.
-participating heavily in EVM testnets to support buyers of last resort (socially confusing, not recommended)
-prepositioning to incoming EIPs, for example, offering summary stats from abstracted mempools and getting rewarded for relaying that to other operators who opt-in to that data from other offchain mempools (EIP too new, risks unclear)
References:
-A Platform Architecture for Multi-Tenant Blockchain-Based Systems, 2019
