You spent a lot of words accusing my post of being long, overconfident and “numerically decorated.”
Yet after all the phrases about “spreadsheet fan fiction,” “deadline cosplay,” a “product fever dream” and a “technically literate ultimatum,” you provide not one alternative customer price, one alternative payout schedule, one operating-cost ceiling, one financing requirement or one prioritized product plan.
Your central criticism is that a public proposal does not contain private data that only Storj possesses.
That limitation was stated openly in the post. It is not the discovery you present it as, and it does not invalidate the calculations that can be made from the filed numbers.
The title is How to survive without reducing SNO compensation.
So yes, the plan starts with that condition. It is neither buried nor disguised. It is literally in the title, the opening paragraph and the conclusion.
The purpose is to answer a specific question:
Can Storj become viable without reducing SNO compensation?
Every serious plan has constraints. Service continuity is a constraint. Legal obligations are constraints. Customer contracts are constraints. The availability of capital is a constraint. The minimum price at which a critical supplier base remains available can also be a constraint.
A restructuring does not require management to cut every cost category merely to prove its neutrality.
It requires management to determine which changes produce the best net result without destroying the business it is trying to preserve.
You use the phrase “metaphysically exempt” as though I claimed a law of nature. I did not. I stated a commercial position:
I will not support or contribute to a restructuring that reduces SNO compensation.
Creditors state the treatment they will accept. Investors state the return and protection they require. Employees decide whether compensation is sufficient to remain. Customers decide what price and risk they will accept.
SNOs are also allowed to state their conditions.
Correct—and insolvency does not prove that the supplier price is excessive.
The court filings identify the failure of the enterprise-sales expansion, the unsuccessful Object Mount investment, disappointing results from Petagene and Valdi, and payroll and technology costs greatly exceeding income.
They do not identify SNO compensation as the cause of the filing.
That does not make SNO rates immune from discussion. It does place the burden on anyone proposing a reduction to show that it creates a positive net result.
“Supplier prices are renegotiated constantly” is not an analysis. Suppliers also reject new terms, withdraw capacity, reduce quality or leave the relationship entirely.
The buyer being insolvent does not magically make the buyer’s preferred supplier price sustainable.
The comparison exists to show scale.
A 20% storage-rate cut would generate approximately $22,800 in gross monthly savings against an estimated monthly operating gap of roughly $137,000.
That does not mean every smaller saving is worthless. It means this particular saving does not remotely remove the need for customer repricing, central cost reductions, claim restructuring and new capital.
More importantly, $22,800 is the gross saving.
It is not demonstrated net value.
The net result also depends on operator departures, the amount of customer data affected, repair traffic, repair payouts, central repair costs, reduced diversity and the future cost of rebuilding capacity.
You demand operator supply curves, elasticity estimates and internal concentration data before I may reject a cut.
Fine.
But then those same missing data also prevent you from treating a cut as a useful component of the restructuring.
You cannot require a complete operator-level model from the person opposing a cut while requiring no such model from the people proposing one.
That is the actual asymmetry here.
No. That is your logic, not mine.
A cost-saving measure should be judged by its net effect.
A payroll reduction that saves $300,000 but removes the people required to operate the network could be a bad reduction.
A software-contract reduction that saves $100,000 but creates $200,000 in migration and operational costs could also be a bad reduction.
The word “cumulative” does not transform every gross saving into a good decision.
And SNO compensation has one particularly relevant feature: Storj already pays nothing for unused storage.
If the network has 100 PB of unnecessary empty capacity, the direct storage payout for that empty capacity is still $0.
A lower storage rate therefore does not reduce the cost of the free space repeatedly offered as justification. It reduces compensation for occupied storage containing customer data.
If Storj wants less excess capacity, it can slow onboarding, slow vetting in oversupplied placements and recruit only where additional capacity is required.
Those actions address excess capacity.
Cutting payment for existing customer data does not.
Of course they are different scenarios. That is why the post calculates several different reductions instead of pretending they are identical.
The table shows the spectrum:
- small reductions produce limited gross savings;
- larger reductions produce larger savings but increase operator risk;
- total abolition removes the supplier network.
Showing the endpoints is not claiming that a 10% reduction and total abolition are the same event.
It shows why there is no obvious painless point where the saving becomes transformative while the supplier consequences remain irrelevant.
You have not identified such a point either.
It is a sensitivity analysis.
A sensitivity analysis is supposed to be arithmetic.
The filed budget shows that cash inflows would need to increase by approximately 40.7% merely to cover the same outflows with zero customer loss and no additional reserve.
The proposed move from $7 to $12 is approximately 71%. The table then asks how much weighted usage could disappear before the higher price no longer covers the filed outflows.
It does not claim that customer loss will actually be 5%, 10%, 17% or 25%.
The post says explicitly that no outsider can predict churn without Storj’s customer-level data.
You attack the table for failing to predict customer behavior when the text directly states that it is not a prediction.
It is the exact algebraic break-even point under the stated assumptions.
It is not an empirical churn forecast.
Those are different things.
Writing “approximately 17%” may be easier to read, but it does not change the calculation. Numerical precision in an equation is not a claim that customer behavior can be forecast to two decimal places.
You list contract restrictions, discounts, collection failures, procurement rules, bankruptcy risk and customer-specific behavior.
Those are precisely why the post demands a customer-cohort review before applying the proposal blindly.
The absence of private customer data limits every outsider. It does not make the current $7 price sustainable, and it does not make a transparent sensitivity table “fan fiction.”
The plan does not assume that every fixed contract can be repriced immediately. It explicitly says the opposite.
New customers move immediately. Month-to-month customers receive notice. Fixed contracts move at the earliest lawful opportunity. Material customers require individual treatment.
The Day-30 number is a turnaround target, not a promise that every customer has already completed several billing cycles.
And the company does not have the luxury of waiting a year before discovering whether its customer economics work. The filed budget provides roughly twelve weeks of runway.
An aggressive deadline may be missed. That is why the plan contains failure triggers.
Calling it “deadline cosplay” does not supply a more credible timetable.
How long do you propose Storj should wait before establishing whether its post-restructuring revenue can cover its recurring costs?
It is derived from what the business can afford.
At $500,000 in monthly collected revenue and 40% direct COGS, $300,000 remains for fixed costs.
That is a solvency boundary.
A bottom-up department budget is still required, but no outsider can produce it without payroll records, contracts, staffing plans and infrastructure details.
A turnaround requires both directions:
- a bottom-up determination of what operations require;
- and a top-down determination of what available revenue can support.
You dismiss the second because the first is not public.
That does not make the affordability limit arbitrary.
It means management must decide whether Storj can operate below it. If not, then $500,000 is not enough revenue and the revenue or financing requirement rises.
It is not “convenient.” It is accurate terminology.
A forecast claims what management expects to happen.
A target states what must happen for the strategy to remain viable.
The Year 2 and Year 3 numbers are not evidence that Storj will achieve them. They are performance gates. If Storj cannot build a credible acquisition model capable of supporting those targets, it should not expand spending on the assumption that growth will somehow arrive.
Pretending the numbers are forecasts would be dishonest.
Calling them targets is the opposite.
You took items spread across a 36-month roadmap, stacked them into one list and presented them as though all of them were promised as finished production products within ninety days.
That is not what the plan says.
The core idea is one reusable provisioning and integration layer. WordPress, NAS, backup, media and AI tools are not each supposed to reinvent account creation, credentials, buckets, billing and health monitoring.
They reuse the same layer.
Storj also does not begin from zero. It already has S3 compatibility, native Uplink, Object Mount technology, Rclone support and manual guides for several of these systems.
The proposal is to turn existing technical capability into a usable product instead of forcing every customer to reconstruct the integration manually.
Yes. That is what software products do.
They move complexity away from every individual customer and implement it once in reusable, tested software.
The fact that an automatic installer must handle authentication, credentials, caching, updates and recovery is not an argument for making every customer handle those things manually.
It is an argument for proper engineering, limited scope and staged releases.
The plan also requires named ownership, security review, code review, testing, support tooling and a real release path. You repeat those requirements as though they were omitted.
Nobody claimed otherwise.
That is why the plan requires paid pilots, paying design partners, contribution-margin measurement and failure triggers.
An integration is a hypothesis about reducing customer-acquisition friction. It is tested by whether customers activate it, pay for it, retain it and require an acceptable level of support.
If it fails those tests, it is stopped.
That is considerably more disciplined than Storj spending substantial resources on products before establishing sufficient traction—which is exactly what the court filings say happened with Object Mount.
That is a straw man.
Stating the amount of capital a turnaround requires is not “ordering” anyone to provide it.
Every financing process begins by estimating the funding requirement and use of funds.
Only then can potential sources, valuation, security, dilution and return be negotiated.
The post identifies possible instruments: equity, preferred equity or a deeply subordinated convertible instrument. It proposes conversion or extension of major existing claims and milestone-based release of capital.
The exact valuation and investor terms cannot responsibly be invented without the cap table, asset valuation, final claim treatment and actual investor discussions.
Doing so would be the pseudo-precision you accuse me of elsewhere.
Whether anyone is willing to invest remains a market test. If the capital cannot be raised, the plan contains a strategic-sale trigger.
That is not an assumption that money will materialize. It is a stated financing requirement followed by a fallback if the requirement cannot be met.
You offer no alternative estimate and no alternative funding structure.
The comparison includes Backblaze B2 and Cloudflare R2 and expressly states that Storj will not be the cheapest solution for every workload.
That is the opposite of hiding inconvenient competitors.
AWS and Azure demonstrate that the proposed prices remain below important premium alternatives. B2 and R2 demonstrate that Storj cannot compete on price alone.
The proposed response is not merely a “list of desirable nouns.” It includes specific prices, bundles, self-service checkout, direct integrations, agency and MSP channels, partner compensation based on collected revenue, paid pilots and sales compensation based on collected gross profit.
You may disagree with the strategy.
Pretending it consists only of the words “security” and “performance” ignores most of the actual proposal.
The calculation is explicitly introduced as a simplified uniform-distribution illustration.
It does not claim to describe Storj’s actual placement-weighted network.
It answers one narrow hypothetical:
If one of three independent host domains failed at each of three large operators, under uniform placement, what would the piece-loss distribution look like?
Under those assumptions, the calculation is mathematically correct.
Scientific notation is not “aesthetic authority.” It is simply a practical way of writing a very small number.
You are free to reject the assumptions as unsuitable for estimating the real network. The post itself says real concentration must be tested using Storj’s internal operator, host, subnet, ASN and placement data.
The purpose of the illustration was not to certify every large farm as risk-free. It was to show that a partial host-domain failure is not automatically equivalent to the simultaneous complete disappearance of every node operated by those companies.
That distinction remains valid.
Of course I have an interest.
So do the creditors, management, employees, investors, customers and every other participant in a restructuring.
The relevant distinction is not between interested and interest-free stakeholders. There are no interest-free stakeholders.
The relevant distinction is between a hidden interest and a disclosed one.
Mine is in the title, the premise and the conditions of my offer.
You quote those conditions as though you uncovered them.
I offered development work with a normal commercial value in the five-figure range.
I did not claim that this contribution alone would finance the entire roadmap, maintain every product or replace exit capital.
It is an additional contribution toward a defined part of the work.
The post also states that donated code requires product ownership, specifications, sandbox access, code review, security review and a real release path.
Your warning that “software is not free merely because the initial commits are unpaid” attacks a claim I never made.
That is not a contradiction.
It is the premise being tested.
A plan entitled How to survive without reducing SNO compensation naturally tests whether all other available levers are sufficient to preserve the current rate.
The calculations show that this is at least financially possible under the stated assumptions.
They do not prove that management will execute it, that customers will accept every price, or that investors will provide the capital.
That is why the proposal contains tests, milestones and failure triggers.
Your preferred methodology appears to be that no external proposal may be called a plan until it contains all internal data, completed customer research, final investor commitments, a department-level budget and validated product-market fit.
At that point it would no longer be a proposal.
It would be the completed restructuring.
The central problem with your criticism
You repeatedly demand evidence for every part of my proposal while supplying none for the alternative you preserve.
You say I cannot prove an SNO cut is harmful without operator elasticity and concentration data.
Then you cannot prove that it is a useful net saving without those same data.
You say a price increase is unvalidated.
Correct—that is why the proposal includes a sensitivity analysis, cohort review and failure triggers rather than pretending the outcome is known.
You say integrations are not automatically demand.
Correct—that is why the plan requires paying design partners, margins and staged releases rather than assuming every integration succeeds.
You say $5 million is not automatically available.
Correct—that is why it is described as a capital requirement, with a strategic transaction if it cannot be raised.
Those are uncertainties to be tested.
They are not contradictions.
After more than two hundred lines of criticism, you have not shown:
- what Storj should charge customers;
- what it should pay SNOs;
- how much a cut would save net of its consequences;
- what recurring fixed cost it can afford;
- what product should be built instead;
- how much capital is actually required;
- or what happens when your preferred assumptions fail.
You have shown that a public proposal lacks Storj’s private data.
Everybody already knew that—including the person who wrote the proposal and stated it explicitly.
If you want to replace the plan, provide a better one.
Put numbers on the customer price, SNO rates, fixed costs, runway, financing, product priorities and expected consequences.
Until then, this is not a demolition of the proposal.
It is a very long objection to the fact that an external stakeholder cannot already possess the internal information required to complete it.
