The held back fees are described in the T&Cs as being based on a percentage of the Storage Node Fees accrued during such defined time periods of the nodes life and cover the first nine months using a quarterly sliding scale. With the logic being that the sum accrued will cover the repair costs of the data lost if the node goes offline.
From what I can tell this method of calculating the charge may be simple to code, but very arbitrary in nature. For the following reasons
All examples I have found have the fee being charged on the total monthly income and so includes the Egress Revenue (and possible the Repair Revenue). The fee is by definition a Storage Revenue fee and has nothing to do with the other revenue streams.
As described the fee can be gamed by adding storage to an already active node. If I was to take my current 1TB test node and in a few months increase the space to 10TB the current fee structure does not seem to correctly build up the correct balance as it accrues based on the life of a node and not its used capacity.
The amount accrued over the nine months is also going to be rather arbitrary as it depends on how fast data is pushed to a node. All the examples I have found shows it taking months for a node to be filled. My 1TB test system took days and so will end up with a higher overall amount held than a system that took 2-3 months.
As described it does not correctly handle any reduction in the amount of data held on a node. The ablity to do this is currently limited (but possible) but seems that it will be far easier in the future.
Even the Graceful Exit Release process is rather arbitrary as the description indicates that it has to 100% complete to release the outstanding funds. Surely it should payout based on the percentage of data that has been correctly handled.
None of these are a show stopper for a start-up business with 1.X processes and code in place, but in time they seem to need a revision.