Arthur, thank you for sharing the numbers about TF’s staff reduction. That changes the picture considerably, and I don’t think anyone in this thread would have guessed it was that severe. When people see a half-billion-dollar treasury declining a $50K maintenance ask, without knowing that two-thirds of the staff is gone and the ecosystem’s core orgs are in consultation to cut large numbers of people, it looks like something it’s not. That context should have been front and center from the beginning. A little transparency goes a long way toward making cuts feel like shared sacrifice rather than targeted defunding.
To Jev and the ECAD team: I don’t think anyone can read your post and come away questioning your commitment to this ecosystem or the quality of your work. Seven years, dozens of releases, Apache 2.0 the whole way, CII Best Practices badge. That’s the kind of stewardship every open-source project wishes it had. The fact that you offered a $50K maintenance-only engagement after the full renewal was declined tells me you weren’t trying to squeeze the Foundation. You were trying to find a number that let you keep the lights on and the signing layer secure. You didn’t want to walk away from operators who depend on you, and $50K was the smallest number that made that possible.
I think both of you are telling the truth, and the tragedy is that the truth from each side makes the other side’s truth sound like an accusation.
But I want to zoom out for a moment, because this thread is not an isolated incident. A few weeks ago I went through every developer-experience post on Agora and catalogued them in a single thread. The list is long: PascaLIGO deprecation that caused concrete harm to Madfish and Mavryk. Rapid protocol deprecations that broke dApps and shut down Endless Ways. The TZIP process described by participants as “broken and dead,” with standards MRs going nowhere. ECAD’s RPC shutdown that forced wallets, dApps, indexers, and tooling to scramble. Governance compression that shut external devs out and treated the community as unpaid QA. TZStats decommissioning that left us with a one-explorer dependency and no self-host path. Giganode, TezEdge, Nautilus, Galleon, Tacode, TezGraph. All gone. Babylon’s rushed upgrade that broke indexers with insufficient communication. The Babylon hotfix debate where everyone agreed “we cannot fail developers like that.” The freeze and adoption-window request where builders begged for certainty before activation. Broken LIGO docs and tutorials. Wallet interaction standards that never materialized. FA2.1 and FA3 standards that left token builders in pain. Support requests ignored in Discord.
Every single one of these has its own specific explanation. Budget, priorities, maturity, market conditions. Individually, each one is defensible. But collectively, they are a catalogue of developer trust being eroded one deprecation at a time. The Signatory thread is the latest entry in that catalogue, and because it touches the signing layer, the part of the stack that protects baker keys and determines what actually gets signed. The stakes are higher than usual.
The root cause is simpler: we don’t treat the developer and operator experience as a first-class product. We treat each tool, each standard, each service, each upgrade as its own project with its own lifecycle, and when it ends, the people depending on it absorb the cost. Nobody is evil. Nobody is trying to break things. But the system has no mechanism for ensuring continuity, no transition planning by default, and no feedback loop that makes the cumulative cost of these disruptions visible to the people making the decisions.
If the bear market is going to force austerity anyway, this is exactly the right time to fix the root cause. The money is tight, but process fixes cost nothing. Transition plans cost nothing. Transparency costs nothing. Treating developer continuity as a requirement rather than a nice-to-have costs nothing.
Arthur is right that TF has been burned by the “fund me or the ecosystem suffers” dynamic before. He’s right that budget discipline is necessary when the treasury is shrinking and everyone is cutting. He’s right that not every team has handled these conversations well.
ECAD is right that $50K for a year of maintaining enterprise-grade security software across eight backends with operator support and security response is barely break-even. They’re right that “I’ll do it in a weekend” misunderstands what maintaining a signing layer actually costs. Not in code, but in the grind of testing, support, and security response that doesn’t make it into commit logs. And they’re right that when the signing layer consolidates into the same organizations that control the protocol, an independent baker’s ability to run something else becomes theoretical rather than real.
Here’s what I think we should take away from this, not as criticism of anyone, but as lessons the ecosystem genuinely needs to internalize:
-
Transparency about the financial reality matters.
If TF is cutting 2/3 of staff and the ecosystem’s core teams are in contraction, that needs to be in the biannual report, plainly stated. People can handle bad news. What they can’t handle is watching critical infrastructure get defunded while the treasury appears flush and nobody explains the math. -
Security infrastructure is not ordinary tooling.
A remote signer that protects baker keys and enforces watermarks across cloud KMS and HSMs cannot be sustained as a hobby project, and it cannot be absorbed into a team that has ten other priorities without atrophying. This category of software needs a funding model that doesn’t reset to zero every cycle. A multi-year maintenance commitment at modest cost, with clear transition provisions if the relationship ends, would cost the Foundation almost nothing relative to the treasury and would prevent exactly the crisis we’re now in. -
The consolidation problem is structural, not personal.
Nobody in this thread is acting in bad faith. But when independent teams lose funding and their projects migrate to entities that already control the node, the SDKs, the indexers, and the protocol itself, the surface area for independent action shrinks. Nobody’s engineering is at fault here. The system itself narrows the surface area for independent action every time another project consolidates. We should be honest about it and actively preserve space for independent tooling, especially at the signing layer where the stakes are highest. -
Transition planning should be built into every funding agreement from day one.
Tokyo’s suggestion is the right one. If a critical piece of infrastructure stops being funded, there should be a pre-agreed path for the domain, the docs, and the stewardship to continue, not as a weapon but as a normal part of how public goods work. ECAD keeping the Signatory name and docs proprietary is their right, but it also means the ecosystem loses both the software and the brand identity when funding stops. We can design around that next time. I don’t know if the Foundation reverses course on this. Arthur said he’s not counting on it, and I’m not either. But losing ECAD hurts regardless, because we’ve already lost them on the RPC, on Taquito, and now on Signatory. This ecosystem is bleeding one of its most consistently competent independent teams. It compounds, and we’ll feel it for years. Expecting Trilitech to maintain Taquito on par with ECAD is unreasonable and unlikely, especially at first. The same goes for Beacon.
To Jev: thank you for everything you and the team have built and maintained. I hope there’s a way back. To Arthur: thank you for engaging here directly when it would have been easier to stay silent. The conversation got heated, but the fact that it happened in public is better than the alternative.
And to everyone reading this who runs a baker or operates infrastructure: the tz4/BLS cloud-KMS gap is real and there is currently no alternative to Signatory for that use case. Plan accordingly.
This thread has surfaced real tensions that the community needs to work through together, not let harden into resentments. I’d like to see us channel the energy here into a few concrete discussions while everyone is still at the table. The TZIP process is one. It’s been called broken and dead by the people trying to use it, and standards MRs sit idle while builders ship without them. That’s a process problem the community can fix if we treat it as urgent. Beacon, now Octez.Connect, is another. Wallet-to-dapp interaction is the front door to every Tezos application, and right now there is no standard that gives developers confidence their integration will still work next year. Both of these are community-level problems that don’t require a single dollar of new funding. They require people to show up, agree on a direction, and follow through. If this thread has done anything, it’s reminded us that waiting for someone else to fix things hasn’t worked. Trying to fix it alone hasn’t worked either. Let’s use the momentum.
Even if Nomadic and Trili are going to take over progressively more of the infrastructure, they’re still building all of this for other people. Other people need standards, stability, predictable deprecation timelines, and migration paths that don’t require rebuilding from scratch. Those things don’t happen by accident. They require process, and (decentralized) process requires the community to participate. The TZIP process and Beacon are both places where that participation can start immediately, with no budget line item and no permission from anyone. If consolidation is the reality we’re headed toward, the best thing the community can do is make sure the consolidated stack is built to serve the people who depend on it, on terms that outlast any individual funding cycle.
If these talks are already happening inside Nomadic or Trili, surface them here on Tezos Agora. Not as announcements after the fact. Not as completed proposals that arrive fully formed with an adoption window already ticking. Surface them early, in draft, while there’s still room for the people who will have to live with the outcome to weigh in. That’s the difference between community governance and community notification. The Agora exists for exactly this purpose, and the best way to rebuild trust with the developers and operators who have watched tool after tool disappear is to show them the process while it’s still malleable. Dogfooding the forum means treating it as the place where standards get debated, timelines get pressure-tested, and migration paths get designed with the people who will actually walk them. If consolidation is the direction we’re going, the community’s only protection is visibility into the decisions that affect them. An open Agora thread costs nothing and buys a lot. We’re either going to take 5%-10% of our time to communicate openly daily or redo 100% of the work every 3 years.
