As a core developer, I don’t feel that it’s my job to a. follow the price of ETH, b. care about the price of ETH, or c. optimize for the price of ETH. As Justin says here, the price is an “external factor” that’s going to do what it’s going to do – the markets are stupid and irrational and should not have an impact on our building.
I think it is fair for a core dev to not worry about price at all, but if you are involved in specifying the economic aspects of the protocol it is absolutely critical to think about the economic dynamics of the system including price (and many other factors).
Another interesting perspective. @lkngtn suggests that maybe we should not try to have a staking token that’s also a “money” or SoV token:
I’m not sure if this is completely on topic with regard to whether devs should care about ETH price, but since the twitter thread was posted I figured I would clarify and expand on my position.
I think it is a mistake to attempt to design a token to take on the dual purpose of staking and as a store-of-value currency/commodity money. Though I do believe that having a native store-of-value asset is important for capital allocation, investment, and healthy ecosystem growth.
My suggestion, which has already be explored by Cosmos, is to separate the staking token economics from that of the fee token economics. There are a few intuitive reasons why this might be a good idea:
- The utility of a fee token (commodity/currency) is improved with liquidity, and by the predictability and stability of issuance.
- Security of a proof of stake network is improved by illiquidity. It is much more difficult (or at-least more time consuming) to acquire a significant amount of an illiquid asset in order to perform an attack, and if your attack fails and you are slashed (in protocol or via a fork) both the capital cost and time cost must be considered.
The liquidity of a token can be influenced by a dynamic supply policy, which adjusts the inflation rate based on a target percent of the supply which is locked up to stake. See this article about participation rate targeting for a more thorough exploration.
If a single token is used for both fees and staking, adopting such a policy in order to make the token price illiquid (and as a result more volatile) would come at the expense of the utility and practicality of the fee token. But if these tokens are kept separate, we can optimize liquidity of the staking token independently of the issuance policy for the fee token.
The goal of staking protocol design should be to optimize for cost-effective security. We want to be able to process many transaction at low cost and we want to be able to create and secure value on top of the protocol. One way to increase security is to increase token price and market cap, as this represents the budget an attacker would need to perform an attack. This is intuitive and easy to quantify–but this is not a particularly efficient means to increase security.
There may be many optimizations, some of which we have yet to even conceive, which become possible over time. We may move away from from proof-of-stake and instead rely on Web-of-Trust graphs for social sybil resistance in order to provide more cost-effective security and better decentralization and means of more fair and sustainable wealth distribution. We may use tokens to emit reputation for staking, to further manipulate liquidity of the validator set and reduce the capital costs of validating the network.
By tightly coupling the fee token and speculative value capture to the economics of the staking token we significant limit our current and future options in terms of optimizing for cost effective security. I suggest we optimize for the value proposition of participating as a validator without trying to optimize issuance to imbue the staking token with store-of-value properties, and instead optimize a separate token for store of value properties (including using it as the designated payment token for transacting on the network or paying storage rent).
