Oxen Tokenomics Thoughts - The Need for Buffer and Flexibility in Staking Mechanism

[ghost]

The recent Oxen market fall raises a number of valuable discussions in the community.

One important issue in the Oxen market dynamic that is rarely mentioned is the staking mechanism: There is no enough "buffer" or "flexibility" in Oxen staking.

The current protocol requires a node operator to stake any amount between 3750 and 15000 Oxen per node, and a number of contributors can fill the gap between the operator's share and the cap of 15000 Oxen. This seems to create some buffer or flexibility, but it’s not enough.

The problem with this design is, for any potential new operator, there is a negative ROI to buy 1000 Oxen, 2000 Oxen, or virtually any value under 3750 Oxen, because that amount of Oxen will be sitting in their wallet and the value decreases over time. In practice, we have seen some new members in the community begging for a few Oxen to fill their gap to start a new shared node. The story for an existing operator is slightly better because they can purchase 3700 Oxen and combine them with their accumulated rewarded 50 Oxen to start a new node. Unfortunately, this inequality between new and existing operators is favorable to existing operators and unfavorable to new operators. This inequality makes Oxen less attractive to new operators, which reduces the demand for Oxen, reduces the diversity of the Oxen network, and ultimately harms all existing operators.

Even if an operator can afford 3750 Oxen to start a new node, the lack of buffer issue still applies to the contributors' side. A brand new contributor either buys at least 1250 Oxen, or buys 0 Oxen, and the ROI of buying or holding less than 1250 Oxen might be negative, unless he is lucky enough to find an unusual small slot to stake. The same inequality applies to contributors. Existing contributors can buy 1200 Oxen and combine them with the other 50 Oxen from accumulated rewards to fill a slot of 1250 Oxen. Again, this inequality penalizes new contributors in favor of existing contributors. Unfortunately again, the high-order consequence of this inequality is harmful to everyone, no one gains from it.

Sometimes we observe a scarcity of operators, sometimes we observe a scarcity of contributors. However, those are only the surface issue, as the core problem lies in the lack of buffer, which results in low liquidity in the market. An exchange that allows buyers and sellers to trade at least 1 whole apple will have much higher trading volume and deeper market depth than an exchange that requires a minimum trading amount of 1250 apples per customer. This is because people who cannot afford 1250 apples will likely quit the market in the latter case. Although Kucoin does not prevent anyone from trading less than 1250 Oxen per customer, the buffer issues explained above reduce the incentive and demand for buying less than 1250 Oxen, which effectively excludes potential buyers who cannot meet the threshold.

The lack of buffer issue results in a lack of liquidity, and we already see the consequence of the lack of liquidity. When some whales dump Oxen, the price collapses because the supply-demand curves are not smooth. The price collapses at the discontinuity point of the demand curve when the supply expands. The more granular and deeper buffer we have, the less discontinuity points exist in the demand curve.

A potential solution is to enable an upper-bound-lower-bound staking requirement, set up a relatively easy lower bound to attract new operators, and implement a flexible continuous staking mechanism for a running node.

Ideally, when an operator acquires as few as 100 Oxen, they should be allowed to receive node rewards immediately, regardless of any unfilled gap. Their reward should be proportional to the ratio between what they already staked and the upper-bound of 15000 Oxen. Once they have gained some rewards or have an additional budget to purchase more Oxen from the market, they should be able to continually fill up their node without having to unlock it and enjoy more rewards until they reach the maximum staking limit of 15000 Oxen.

To prevent sophisticated attacks, the maximum leverage allowed to any node should be limited. While we won't delve into the details reason for simplicity's sake, in short, if an operator stakes 100 Oxen, they should be allowed to receive at most 300 Oxen from other contributors. If an operator stakes 3750 Oxen, they should be allowed to receive at most 11250 Oxen from contributors. And if an operator stakes 14999 Oxen, they should be allowed to receive at most 1 Oxen from contributors, and so on.

By implementing an upper-bound-lower-bound staking requirement and a flexible continuous staking mechanism, the Oxen market could see several benefits. First, by lowering the threshold for starting a new node, more new operators could be attracted, which expands the demand and increase the diversity of the operator set, results in an improvement of the privacy property of the network. Second, the flexible continuous staking mechanism would improve the buffer of staking, increase liquidity in the Oxen trading market and eliminate the inequality between old and new Oxen stakers. This would also eliminate the discontinuous points in the demand curve, increase the stability of the Oxen price.

There are also additional benefits of this approach that are not directly related to tokenomics. For advanced users of Lokinet who do not care about token rewards but simply don't fully trust the network, they can easily purchase a minimum amount of Oxen and run their own node as their personal guard node. This reduces their level of doubts and increases their confidence in privacy. The side effect of increasing this segment of users is that it also increases the demand for Oxen.

I proposed the upper-bound-lower-bound staking mode about a year ago, and promised I will continue to raise this topic again and again over the next 3-5 years, in the hope that more people will take the time to give it deep consideration. Tokenomics is not always easy to understand and can be risky to change, but it is critical enough that we should take it very seriously.

There is no better time than this bloody market collapse to convince everyone to deeply reflect on Oxen's tokenomics. In any case, I will persist in bringing up this topic until we finally have a clear understanding and agreement of what is needed to improve the tokenomics design of Oxen.

Edited:

An even more underestimated consequence of the high staking threshold and inflexible staking mechanism is the potential resistance Oxen may face in the next or any future bull market. For instance, if Oxen is traded at $0.20 USD, buying 3750 Oxen requires $750 USD. Only a limited number of investors can afford this amount, further limited by investors with a budget of n*750 USD. Suppose the price of Oxen increases to $0.25 USD, people with a budget of $750 USD will no longer be able to start a new node if they missed the chance to buy at $0.2 USD. Their budget is only enough for 3000 Oxen, which is now below the threshold. This slows down the momentum of Oxen from further increasing its price because long-term loyal supporters who believe in the project can no longer afford to start new nodes. It takes time to bring in new supporters, while existing supporters are hindered from further investing in the project at critical time. The threshold issue creates a gap between bringing in new supporters and further support from existing supporters which flattens the growing curve.

Potential operators who can't afford 3750 Oxen might still opt to purchase 3000 Oxen and stake in one of the available slots first; however, this exacerbates the imbalance between available staking slots and potential contributors, making it more difficult for other potential contributors to find a slot. Moreover, if there is no slot for staking, investing in a high-inflation token becomes less appealing. Not only are potential skilled operators without enough Oxen pushed to become contributors, but existing operators who don't have enough Oxen for their next node are also temporarily pushed into the contributor role until they accumulate sufficient Oxen to start another node. This aspect can be measured:

At the time of writing, according to data from https://oxen.caliban.org/contributor/ranking:
There are currently 502 contributor wallets, with 441 being pure contributors who do not operate any nodes.
This means there are 502-441=61 wallets that are both contributors and operators.
In total, there are 406 operator wallets, which means that 61/406=15% of operators are currently also occupying some staking slots, competing with potential pure contributors for those slots.

15% is not a small number. Ideally, these 15% should be freed up as a "buffer," so that if Oxen suddenly attracts many new supporters one day, they can immediately stake in the network without the frustration of not being able to find any available slots. In a bull market, it's quite common for a standout project to attract 10% to 20% new supporters day by day during several consecutive peak trading days. If a project misses this critical window of growth during those few trading days, it risks missing out on the entire bull market.

Even if there are enough new investors with plenty of budget, a mis-match between operator budget and contributor budget will result in stagnation of growth as well. For instance, assume there are more operator budgets than contributor budgets on January 1st. Operators will stop launching new nodes if they find existing nodes struggling to find enough contributors. If on January 2nd, some external event triggers a huge influx of new contributors, the mis-match might suddenly shift to the other side, new contributors might quickly find that there are not enough operators available, and stop buying Oxen. Ideally, operators and contributors should be able to act asynchronously, but the fixed staking requirement forces operators and contributors to act almost synchronously. It is like two people tying their legs together while running. The effectiveness of a market is heavily dependent on the successful exchange of information. However, the absence of a buffer between the operator and contributor pair makes it extremely challenging to publish and exchange information.

The most effective way to attract new supporters is often through the break out of price movements. Research on stocks, gold, and other assets shows that majority of market cap growth often happens in a very small amount of consecutive trading days. For other projects, an increase in the price of their coin can naturally attract new investors. However, for a project like Oxen, with a high staking threshold and inflexible staking capacity, the increase in the price of Oxen can actually slow down the overall price increase, creating a paradox.
https://www.wellsfargo.com/investment-institute/sr-perils-time-volatile-markets/

[jagerman]

It's important to also think about the reason for the 3750 cap: we want it to be non-trivial to spin up a bunch of nodes onto the network controlled by a single entity.

To take your example, if we have an operator with a 100 stake, how does this node participate on the network in terms of pulse, lokinet routing, swarm storage? There's a risk here that if it does participate in any of them then this cheap node becomes a way for network attacks by swarming the network at relatively little cost, and then using larger numbers to circumvent the network structures that rely on difficulty in owning a large share of network nodes. And if it doesn't participate then paying it out means taking rewards away from operators who are contributing to the network.

Batching allowed us to significantly reduce contributor staking requirements but keeping operator contribution high was a necessity for privacy and security.

The one way I could see "small" stake nodes operating would be if we scaled down the requirement of such a node (for example: a node with 1000 staked with only have 1/15 reward, only be selected for routing or swarm storage 1/15 of the time, pulse would be selected just 1/15 of the time, and so on. (There are other advantages to it on the other side as well, e.g. a single heavy box could run one 150000 stake and be expected to do 10x as much). That is possible in theory, but would be a lot of work as there is quite a bit of current assumptions that each service node is "equal" across the software stack.

[ghost]

Thanks for the comment.

The one way I could see "small" stake nodes operating would be if we scaled down the requirement of such a node (for example: a node with 1000 staked with only have 1/15 reward, only be selected for routing or swarm storage 1/15 of the time, pulse would be selected just 1/15 of the time, and so on. (There are other advantages to it on the other side as well, e.g. a single heavy box could run one 150000 stake and be expected to do 10x as much). That is possible in theory, but would be a lot of work as there is quite a bit of current assumptions that each service node is "equal" across the software stack.

I totally agree with you, I did address exactly the same issue and proposed the same solution (discriminate lower stake nodes with lower voting power) in my previous version one year ago. I remember I posted it in Oxen community and/or Oxen Service Node community but I lost the history now.

I'm well aware of the increasing complexity of changing the voting system, that's why I planned to raise this topic again and again in 3~5 years, which might be needed before finally implement such a big change.