We explain a lot more over on our website, but Storj is basically AirBnb for hard drives. Some people have free hard drive space (you?), and some people need hard drive space to store their data. Storj connects people who have space (storage node operators, or SNOs), with people who will pay to store data. Data is stored on the Storj network.
Certain peers (called Satellites) on the Storj network manage details of how data is stored, such as which storage nodes are storing what specific data and how much storage node operators should be paid for providing hard drive space. Based on this information, storage node operators are compensated for the bandwidth and capacity they provide to the network through payment in STORJ token, which is an ERC20 token that runs on the Ethereum blockchain.
When a storage node operator configures their node software, they are asked to provide a destination address on the Ethereum network for these ERC20 STORJ token transfers. Storage node operators then get paid on a monthly basis for providing storage and bandwidth to the network by receiving STORJ tokens at that address. The address can be a privately held wallet, an exchange address, or any contract.
When configuring the address, the storage node operator can choose the distribution mechanism. The default is plain Ethereum ERC20 transfers, but a storage node operator can also choose layer 2 transactions on zkSync or more recently Polygon transactions. For storage node operators who choose zkSync, we add a 10% bonus.
How much you earn is based not only on the resources you have, but what resources the Storj network uses. Our current prices are listed here, and you can find more about what this means in practice in our knowledge base.
You can use the STORJ you earn to purchase storage space and egress on the Storj network, or you can trade STORJ on a number of public exchanges for other digital assets or funds paid out in fiat.
If you pay for storage space and egress on the Storj network with STORJ, you get a 10% discount.
Payments happen monthly. We’re committed to getting payments for the prior month out between the 4th and 15th of the subsequent month. Our systems run monthly reports at fairly regular times for accounting and invoicing purposes.
Even though our whitepaper suggests that storage node operators will be responsible for payment and withdrawal fees, for this phase of our growth, Storj has been paying transaction fees for sending funds to storage node operators.
Unfortunately, due to the growing pains of the Ethereum ecosystem, fees on Ethereum (our chosen blockchain) can sometimes be significantly higher than the amount the storage node operator has earned. As a result, we will not pay out until you’ve earned enough so that the transaction fees are less than 25% of your earnings (though this will change to 10% soon).
For storage node operators who haven’t earned enough to clear this threshold for their chosen payment layer (zkSync, Polygon, or layer 1), we keep track of what you earned and you accrue it over time. Once the total accrued makes it over the minimum payout threshold, we send the balance to you.
As an example, if the transaction fee is $25, you will need to have earned $100 or more to receive a payout. Otherwise, payout will be postponed until either your total outstanding earnings reach $100, or transaction fees drop below 25% of what you earned in a subsequent payment cycle.
An undistributed payout is the amount we have calculated you have earned and what we would send the next payout cycle if fees were a nonissue. If you have an undistributed payout, it means you either need to earn more to clear the minimum payout threshold, need to wait until fees naturally drop, or switch to another less expensive payout mechanism (zkSync or Polygon).
This is a good question that deserves a longer answer for Ethereum in general, but suffice it to say the Ethereum network is going through growing and scaling pains. Ethereum is the most popular smart-contract blockchain in the world, and many applications are trying to use it simultaneously.
Ethereum is trying to solve these scaling problems in a number of ways, but the developers of Ethereum expect that layer 2 solutions (like zkRollups provided by zkSync) will be the future of scalability for Ethereum.
zkSync was the first Ethereum layer 2 payment solution that we have successfully integrated to enable us to both reduce the impact of high Ethereum transaction fees and pay transaction fees using STORJ tokens. zkSync is making great progress and layer 2 solutions are the future of the ecosystem. We prefer to pay storage node operators using STORJ token but also prefer to pay transaction fees in STORJ token as well. zkSync allows for this.
If a Satellite operator receives funds from users in STORJ, it is most convenient to be able to pay storage nodes in STORJ directly as well. Satellites are not in the position and do not have the capability to exchange tokens for other tokens; they need an exchange for this. Using just STORJ tokens for payment to SNOs and usage of the networks removes the steps of exchanging tokens for other value.
Read the documentation to configure zkSync. If you have more questions ask us here in the forum. As noted above, we offer a 10% bonus to people who select zkSync.
Polygon is a newer option we recently introduced. Until Polygon is in our official documentation, please see the launch announcement for setup instructions.
Right now you can withdraw from zkSync at your discretion back to layer 1 or you trade on a growing number of exchanges (both centralized and decentralized, OKEx will be live soon).
In addition to the existing ability to pay for usage on the Storj network with STORJ on layer 1, we are working on enabling payment for the Storj network through zkSync STORJ transfers.
Polygon is similar.
For zkSync 1.0, configuring a wallet address for use with zkSync requires a one-time activation fee. It’s generally anticipated that zkSync 2.0 will not have activation fees. While we can’t commit to this yet, we are investigating a system to cover one-time wallet activation fees for operators who want to use zkSync.
The other main downside of zkSync is that it also requires a relatively expensive Ethereum layer 1 transaction fee at the time tokens are withdrawn or sent back to layer 1. Several exchanges (such as OKEx) have announced future support for zkSync which would allow node operators to avoid these high costs once implemented.
Polygon’s downsides are similar to zkSync’s, with two notable exceptions:
- Polygon doesn’t have an activation fee.
- Polygon’s bridging security properties are much less clear than zkSync. While node operators assume responsibility for their funds after Storj has completed payment transfers for all transaction options, this is of particular concern for Polygon.
Ultimately, we believe rollups on Ethereum to be the future of smart contracts and we are trying to “skate to where the puck is heading,” as it were.
That said, it is reasonable to ask if there is another technology or approach we could be using instead of Ethereum or rollups on Ethereum.
One popular suggestion is to wrap STORJ tokens through a bridge and actually use another blockchain for the transactions. It’s worth pointing out that this has some of the same problems as zkSync. Once the transaction is sent, what can be done with the tokens?
If an exchange (centralized or decentralized) has a trading pair for the wrapped token, then perhaps it can be traded. If no exchange exists, an Ethereum layer 1 transaction must be made to withdraw from the bridge, and then withdrawal fees are still a problem.
Popular suggestions we have looked into include Tezos, Avalanche, Polkadot, Cardano, etc.
Trade-offs aside, this is frequently requested. Once a permissioned bridge is willing to add us without scammy hoops or a reasonable permissionless bridge exists, we will certainly explore this. Like zkSync 2.0, most bridges do not have activation fees, which would be an improvement over zkSync 1.0.
For regulatory and other reasons, we do not plan to change the monetary policy of the existing STORJ token (e.g., by minting new tokens). We are disinterested in trying to get an alternate token configuration or contract on another chain instead of or in parallel with the existing STORJ token. These steps are complicated, take time, and distract us from our main goal of distributed storage.
Generally, we’re committed to the Ethereum ecosystem and the STORJ token. We believe that the collection of upgrades to Ethereum known as Ethereum 2.0 will further cement Ethereum as the dominant smart contract platform, especially with rollups and proof of stake, and will alleviate much of the current fee pain. We remain convinced that despite growing pains, STORJ token being on Ethereum is right for us now and in the future.
While we experience a number of difficulties related to storage node operator payments on the Ethereum network, STORJ token is still much more cost effective and tractable for paying more than 10K nodes today in over 100 countries and territories.
Storj is driving to decentralize the world’s data, and we can’t do this without node operators of all sizes but especially small node operators. The minimum payout threshold currently disproportionately affects small node operators (who potentially don’t earn enough to regularly clear it), and we are investigating ways to try to alleviate this pain.
Some upcoming changes may improve things:
- More exchanges are beginning to support layer 2 scaling such as zkSync. Hopefully soon, needing to create transactions on layer 1 will be a rare event.
- We are researching layer 1 contracts for batch multisends. We hope to have more to share here soon.
- We are researching the feasibility of paying for node operators’ zkSync wallet activation fees.
- We are researching other payment options, such as Polygon.
We want to thank small node operators for their patience during this time! Digital assets and cryptocurrency are seeing explosive growth and significant growing pains. Just like the user experience improvements the industry saw for layer 1 between 2009 and 2019, we expect layer 2 will see an even faster growth curve as blockchain congestion continues to increase.
Honestly, we want to, but have not been able to think of a way that is not ripe for abuse. To make up for this, payments made through zkSync include a 10% earnings bonus.
Many node operators operate more than one node, and we ask that node operators use the same Ethereum wallet address for all of their nodes. This not only allows us to have a better understanding of the makeup of our network, but it also allows us to help payments clear the minimum payout threshold faster.
If we sent a minimum transaction bonus for every wallet to cover the withdrawal fee, this would incentivize multi-node operators to use different wallet addresses per node, pool the bonuses, and get potentially significant extra free STORJ which also would undermine our efforts to reduce blockchain congestion generally.
If we pay one-time wallet activation fees (something we are considering), we don’t have the same problem, because pooling can’t happen without activation.
This seems especially unfair to small node operators who regularly have earned less than the fee. Even if we only do this when they have earned more than the fee, the fee will eat into a vast majority of profits for the node operator.
With the exception of the one-time activation fee, this is precisely the user experience zkSync affords us. If a node operator chooses zkSync, then the node operator can decide when to cash out to layer 1 at their own convenience. We hope to help make zkSync more broadly applicable instead of reinventing this wheel.
The short answer is that for a window of time at the beginning of the month, this is precisely what we do.
We created an internal tool to conduct our STORJ token payments. We are able to set a max gas for transactions, and the tool will simply wait for fees to go under that maximum before it creates and publishes any transactions to the blockchain. This allows us to set a relatively low max gas and simply run the tool until all of the transactions have been completed. If you look at fees on the Ethereum blockchain they sometimes drop down drastically, and those drops are what our tool is able to take advantage of with this max gas feature.
What we don’t do is run this all month long. Our current position is that we have made a commitment to pay node operators on or before the 15th of the month for the previous month’s usage. Since the V3 network went live we have never missed this commitment, and we don’t plan on missing it. It’s important for us to establish consistency and reliability with the node operators on the network, just as it is important for our own internal auditing and accounting.
Development takes time, and we still have a lot to build! We currently use a third party tool to accept STORJ token payments for customers using Storj Satellites. Since we are using this third party tool we are very limited in how we can improve the experience. We realize our current functionality set is a challenge, and we are working to build STORJ token payments natively into our service so that we can have much more control around these user experience issues. This is the point where we will also integrate L2 payments for our customers.
When configuring your storage node’s payout address, you might wonder if you can save a step and have your funds sent directly to an exchange.
If you use an exchange address on layer 1, your deposit immediately makes it to your exchange account and you do not need to pay for an intermediate transaction to get your funds there. This has a lot of upside - it’s convenient and quick. The downsides are that you may not meet the layer 1 minimum payment threshold, and more concerningly, the address key is not yours. If the exchange decides to change or invalidate your wallet address (Kraken does this if you have more than 5 addresses, for example), or worse, the exchange is compromised, you may irretrievably lose your funds.
Perhaps surprisingly, even though the keys are not yours, you can use an exchange address with zkSync, even if you don’t have the address’s private key and even if the exchange doesn’t support zkSync. To withdraw funds from layer 2 to layer 1 without owning the key, you will have to do an alternate withdrawal. Alternate withdrawal can be expensive; on the other hand, if your exchange supports zkSync, this may be the cheapest choice in terms of fees.
If you use your own address on either layer 1 or zkSync, you will have to send your funds to an exchange, but you can manage custody of your assets. Remember, payments made with digital assets are not reversible, like bank transfers or credit card payments. From a security point of view, using your own key with a hardware wallet such as a Trezor or Ledger is highly recommended.
After receiving funds via zkSync, Polygon, or layer 1, a storage node operator may have to:
- Pay an Ethereum fee to withdraw funds from zkSync to layer 1 (we expect this to become unnecessary as more layer 2 options arrive)
- Pay a zkSync fee to move fees between zkSync addresses
- Pay an Ethereum or zkSync fee to send funds from their wallet to an exchange
- Pay a Polygon fee to withdraw funds from Polygon to Ethereum
- Pay an Ethereum fee to send funds from their wallet for Storj network usage
- Pay a fee to the exchange for executing a trade
- Pay a fee to the exchange for withdrawing funds
Performance is a critical aspect to the design of the Storj system. Blockchains are by definition shared global ledgers that all peers must agree on, and this adds a significant point of contention. Bitcoin does 4-5 writes per second globally, whereas Amazon’s cloud object storage platform S3 supports 3,500 writes per second per prefix per bucket per account with default account limits. A shared global ledger simply cannot be in the file storage hotpath for cloud object storage. Because we’ve decided to avoid using a blockchain in the core product, it didn’t make sense to spend additional developer time on using blockchains for settlement only.
You can read more about our design decisions on this topic in our whitepaper, especially section 2.10.
Why, here, in our lovely forum, of course!