After completing last month’s payouts, we shared some of our thoughts about where things might go next for storage node operators, and one particular piece stood out to many operators here, which was that we were contemplating making zkSync be the default behavior.
We have heard you loud and clear and (unless the community clearly requests otherwise down the road) will not be making zkSync the default.
But we wanted to share more about our thoughts around this. First, our plans with zkSync were just one aspect of a recently published blog post, which we encourage you to read in full. In it, we talk about upcoming changes to the incentive model such as held amount and pricing, in addition to technical aspects like payment layer. Please take a look at it and let us know what other feedback or questions you have.
Over time, many decentralized systems need to re-evaluate their incentive structures (much like Ethereum is in the progress of doing), and we must do so too, as our network grows. We want to make sure we take the time to listen to and get thoughtful feedback from our operator community before making these changes, and so we want to apologize for how this “it’s likely zkSync will become the default” was sold, instead of a more cordial “this is what we’re thinking. What do you think?” approach.
Fees on layer 1 right now over the last few months have sometimes reached over $100 USD per transaction, which is a significant problem. We understand this disproportionately impacts new node operators or small operators who aren’t earning that much. We’ve been investigating many different ways to fix this, but of course the current solution is the minimum payment threshold, in which we simply hang on to your funds for you until your balance is four times larger than the transaction fee we would need to pay to get it to you.
When we originally adopted Ethereum for the STORJ token, we did so because we believe in the future of the Ethereum ecosystem, and believed that it would be the best opportunity to make payments programmatic, decentralized, and keep fees low. The current fee situation is certainly not something we anticipated. That said, we still believe in the Ethereum ecosystem, and believe that a couple of trends make Ethereum the best choice for us.
- Layer 2 scaling solutions such as zkRollups and optimistic rollups show great promise at increasing per-block transaction counts by orders of magnitude (see: An Incomplete Guide to Rollups).
- Ethereum’s upcoming changes such as the EIP-1559 fee market overhaul appear poised to reduce the fee problem.
- Ethereum’s upcoming move to proof of stake will significantly increase performance, significantly reduce resource usage, and overall improve Ethereum all around.
- The ERC-20 standard is starting to see great cross-chain support (The Wrap Protocol on Tezos, the EVM chain on Avalanche, upcoming cross-chain support in Polygon, Cardano, Polkadot, etc). ERC-20 has become the flag bearer for tokens such as ours. Perhaps soon you will be able to receive and transfer STORJ token across chains.
We have been on the forefront of pushing this ecosystem to its limits and we want to invest in continuing to adopt new and better technologies to push the ecosystem forward, and we are evaluating many options along these angles.
One useful aspect of zkSync for us is that it works with all wallets, including exchange wallets, via an alternate withdrawal mechanism. A lot of the feedback we received was concern that zkSync wouldn’t work with certain wallets, and if this alternate withdrawal mechanism didn’t exist, we wouldn’t have even suggested it to begin with. So it’s a good point, but one that we didn’t clarify well enough upfront.
The other feedback we received was that using zkSync shifts the cost of withdrawal to the operator, and this is indeed an interesting tradeoff that we believe will lessen as more exchanges and wallet providers add native zkSync support (zkSync backers include Binance and Coinbase, for example). However, given the current cost sensitivity of our storage node operators today, we understand that many storage node operators prefer the current layer 1 minimum payment threshold process and so unless the situation changes significantly and operators want something else, we will be leaving Layer 1 as the default for Storj Labs operated Satellites.
If you’re a node operator who has decided to initiate graceful exit, you may be wondering what happens to funds that haven’t met the minimum payment threshold. When we originally implemented the minimum payment threshold, we did so in a very strict way, which was that even if you gracefully exited and had, for example, $39 accrued, but the minimum payment threshold was $40, we would not pay it out. This seemed undesirable to us, and so we added the concept of wallet addresses becoming “terminal,” in which the wallet is no longer associated with any live node. In cases such as this, for the last few months, we would pay out the balance, regardless of the threshold. We didn’t make a big deal about it, but hopefully the community felt supported.
Recently, we did a sweep and cleaned out many nodes we hadn’t seen in months, and discovered that many of these nodes belonged to operators with a terminal balance of sometimes less than a dollar. These are payments these operators really earned, but we were unable to pay due to the payment threshold before the wallet was marked terminal. We spent somewhere around $15k USD equivalent in Ethereum fees this last month sending storage node operators closing balances that amounted to dollars or cents. We believed that switching the default to zkSync would at least allow us to close out small value accounts more efficiently, with the hope that soon zkSync would have broader support with exchanges and so on, so small balances could more easily be cleaned up when the technology and integrations existed. It was in this context of supporting these smaller operators that we started leaning towards making zkSync be the default.
Instead, given the feedback from our community, we are proposing two replacement changes we think will actually make a lot of sense given current policies:
Instead of calculating the minimum payment threshold average over the last 12 hours upfront and running all payments using that threshold, we want to move to calculate the minimum payment threshold on a per transaction level. We will do our best to run payments at affordable times considering layer 1 fees to get the most payments out, and may even attempt to run payments more than once to catch people we miss the first round. Again, we believe that the Ethereum ecosystem will soon make this problem significantly less of a challenge, if all we do is wait patiently, but we need an interim solution now.
We propose to no longer close out terminal wallet balances. Many active node operators perhaps did not know we were even doing this, but it does affect nodes that are gracefully exiting. So, the proposal is instead, if you are interested in getting your final payment and your balance is less than the payment threshold, then you can either:
a. let us hang on to your balance for you if and until the payment threshold drops enough or the layer 1 technology advances, or
b. you can configure your node to opt into a lower-fee option such as zkSync.
It’s worth saying that we are indeed working on adding additional options besides zkSync and are considering other technology stacks. We’ve heard from a lot of you about ways you’d like to see our payment functionality change - please let us know if there is a technology we should be considering. Chances are, we actually are already considering it, but the more we hear from you, the better we can prioritize.
As always, thanks again for being a stellar node operator community, and we commit to do right by you. You are the backbone of this community and network, and we are grateful for all of your contributions. We understand very well that for Storj to succeed, it absolutely has to be economically viable and rewarding to be a storage node operator. Under no circumstances can our business succeed if storage node operators cannot also turn a profit. As we continue to work on refining our payout processes and contemplate possible changes to the incentive model, we voraciously welcome ideas, input, and feedback from our community.