Signatory Remote Signer: End of ECAD Labs Maintenance

[jevonearth]

The Tezos Foundation stopped funding Signatory maintenance and development at the end of January 2026. Signatory is the only enterprise focused protocol-aware Tezos remote signer used by multiple exchanges, public bakers and enterprises across the ecosystem.

Given the significant engineering resources required to maintain and properly test Signatory, ECAD Labs has no choice but to wind down our support for this product. We will not ship under-tested security infrastructure, and the Tezos ecosystem is too small to support this work as a paid commercial product. If we cannot do it properly, we will not do it.

For context: Signatory is a remote signing daemon that protects Tezos private keys. It decodes incoming operations, applies protocol-aware policy, enforces watermarks, and delegates the actual signing to an HSM, Cloud KMS, or TEE (YubiHSM2, AWS KMS, Azure KMS, Google Cloud KMS, Hashicorp Vault, PKCS#11 / AWS CloudHSM, Ledger, AWS Nitro Enclaves, Google Confidential Space). It is Apache 2.0 licensed, carries the CII/OpenSSF Best Practices badge, has shipped dozens of releases over roughly seven years, and is in active production use by bakers and application teams across the Tezos ecosystem.

If you are a baker, validator, exchange, custodian, oracle, or application team relying on Signatory, please begin planning your migration now. Your options are at the end of this post.

Current state of Signatory funding

Over the last seven years of active development, we have consistently invested our own resources to build and maintain Signatory. Financial support from the Tezos Foundation helped accelerate this work and made Tezos our primary customer, but did not cover the full cost of development and testing.

After the Tezos Foundation chose not to renew Signatory funding at prior-year levels, we proposed a limited scope one-year maintenance and testing engagement at USD $50,000, which was also rejected. While this funding would not have covered all of our costs, it was sufficient for us to continue supporting Signatory and felt reasonable when framed as an open-source alternative to protocol wide closed-source enterprise licensing (if such a product existed).

In our view, this is a question of priorities, not scarcity. As of its most recent activity report (31 December 2025), the Foundation holds on the order of half a billion dollars in assets. The report itemizes USD 3.1 million in new non-core team initiatives for the half-year.

Unfortunately, we have no way of knowing whether the Tezos Foundation’s decision to stop funding our work on Signatory and Taquito, and to cancel the subsidy that made our free public RPC service possible, is a decision to stop funding public-goods generally or an effort to centralize control of all public goods and redirect resources to Trilitech and Nomadic Labs. Since the Tezos Foundation changed its reporting format in mid-2024, it no longer reports on the amount of funding provided to these organizations.

Why this software needs sustained funding

Signatory is serious software trusted to secure the network and protect real assets. Bakers and custodians use it to protect the cryptographic keys that secure stake, validator identity, and in many cases the operational integrity of the chain itself. The cost of one silent correctness bug, or one missed protocol semantic, is measured in compromised keys and slashed stake. This is not a category of software that can be sustained as a hobby project, and it certainly cannot be vibe-coded. Testing, code review, security response, and operator support are not optional, and they are not cheap.

A protocol-aware signer is, by construction, tightly coupled to the protocol. Every Tezos upgrade can introduce new operation kinds, new signing semantics, and new watermarking rules that have to be modeled, implemented, and verified across the full matrix of supported backends. Each HSM, KMS, and TEE has its own SDK, quirks, and security boundary.

We believe the Tezos Foundation’s decision to stop funding our work is a mistake on several fronts:

• Post-quantum signing is on the horizon. A well-maintained, audited remote signer is the natural integration point for post-quantum signature schemes once Tezos and the underlying HSM, KMS, and TEE vendors begin adopting them. Walking away from Signatory now means walking away from the layer where that work would happen.
• Baker key compromise is a network-level risk, not just an operator risk. A signer that falls behind on protocol upgrades, or accumulates unpatched vulnerabilities, is a liability for the entire chain. The cost of one serious incident dwarfs years of maintenance funding.
• Concentrating the signing layer is a censorship-resistance problem, not an aesthetic one. A baker’s only real leverage is the ability to run independent software and, in the extreme, to choose against the stack. That leverage is the operational form of censorship resistance, the property decentralization exists to protect, and it is conditional on alternatives existing. As the node, the signer, the SDKs, and the surrounding tooling consolidate into the same few entities, a baker can hold a dissenting view but has nothing independent to run, no exit, and therefore no real agency. Decentralization that cannot act is theatre. A signing layer folded into the entities that already control the protocol becomes a single, compliant point of control over what gets signed with bakers’ keys: the worst place in the stack to surrender independence, and the easiest place for outside pressure to land. Centralized actors comply; that is the problem decentralization was supposed to solve.
• Tezos’s evolving consensus features (DAL, BLS attestations, tz4) need sustained signer work. Bakers need software that keeps up. Without continued investment, they will not get it.
• Security software demands long time horizons. Single-cycle funding decisions are a poor match for software that has to be hardened, audited, and trusted for years.

What this means in practice

• No Ushuaia testing or support from ECAD Labs. Signatory will not be tested against, or updated for, the Ushuaia protocol upgrade by our team.
• No further releases from ECAD Labs. v1.4.0 (March 2026) is the last release we plan to publish.
• The GitHub repository will remain online. The source code stays published at github.com/ecadlabs/signatory under Apache 2.0.
• The documentation and the Signatory name are not covered by the Apache 2.0 grant. The website/ and docs/ directories are proprietary to ECAD Labs with all rights reserved (see the licensing section of the README). Separately, Signatory is our trade name: forks are welcome under Apache 2.0 but may not use the Signatory name, and our documentation may not be reproduced or redistributed.

What you should do

If you currently run Signatory in production, you have several options, and none of them is “do nothing”:

1. Migrate to an alternative remote signer. The honest state of the field, as of mid-2026. Actively maintained, tz4/BLS-capable, on-premise or air-gapped:

   • Tezos RPI BLS Signer (Nomadic Labs, MIT): Raspberry Pi, tz4/BLS only
   • Russignol (Rich Ayotte, MIT): Raspberry Pi Zero 2W, fully air-gapped, tz4/BLS
   • TezSign (Tez Capital): dedicated air-gapped hardware, BLS

   The Octez built-in signer (octez-signer) supports every curve including tz4/BLS, but only with on-disk key files or a Ledger, and Ledger does not sign BLS. It has no HSM, cloud-KMS, or TEE backend.

   Three signers we previously listed as peers are no longer maintained, and we mention them only so you do not lose time on them: the Tezzigator Azure signer (last release 2019, P256 only), the Tacoinfra remote signer (archived 2025; its own README now points users to Signatory), and the Polychain Labs HSM signer (archived 2019, marked “should not be used for any production activity”). None support tz4/BLS.

   Understand what has no replacement. If you sign tz4/BLS with cloud-grade key custody, an HSM, a cloud KMS, or a TEE such as AWS Nitro Enclaves or Google Confidential Space, there is currently no alternative to Signatory. No HSM and no cloud KMS supports BLS12-381 for Tezos, and Ledger does not sign BLS. tz4/BLS signing exists today only three ways: a key file on disk, a dedicated air-gapped device, or Signatory’s TEE. That gap matters precisely because the protocol is steering bakers toward tz4.

2. Test Signatory against Ushuaia yourself. The source is Apache 2.0. Any team with sufficient engineering capacity can pick up validation for their own deployment.

3. Sponsor ecosystem-wide testing. If your project, company, or foundation wants to fund a coordinated round of Ushuaia testing and a community release, please reach out. We would be glad to scope the work.

4. Engage ECAD Labs commercially. We are available to assist organizations that want help testing, patching, or extending Signatory for their own use on a paid engagement basis.

Why not just hand Signatory off to a community maintainer?

Forks under Apache 2.0 are welcome and we will not stand in anyone’s way, but we are not going to anoint a successor maintainer. Endorsing a particular fork would imply that we have vetted the new maintainers’ processes, supply chain, release signing, and security response, which we are not in a position to do. If a credible group steps forward, we are happy to talk to them and provide reasonable technical context. We note, however, that the Signatory name and documentation are the sole property of ECAD Labs.

What about Trilitech or Nomadic Labs maintaining Signatory?

We would not be in favor of that outcome, and we want to be direct about it. Our concern is not the technical capability of either team.

Rather, we are concerned about the corrosive impact of yet another project being absorbed by the very organizations that administer the Tezos Foundation’s funding, and the continuing consolidation of competing technical concerns.

Over the last few years, most of the Tezos Foundation’s administrative and engineering review functions have been outsourced to Nomadic Labs and Trilitech. In our view this has created a structural conflict of interest within the Tezos Foundation funding model. Whether this conflict of interest is real or perceived doesn’t matter, the negative impact on the open-source community cannot be ignored.

When independent projects like ours lose Tezos Foundation funding, transferring stewardship of those projects to the very organizations that administer this funding undermines trust in the funding model that sustains our open-source community. While publicly positioned as a positive outcome, under the hood, these moves look to us like a low cost acquisition strategy that alienates the very development community that believes in Tezos.

In our own experience, it was suggested to us that Nomadic Labs or Trilitech take over Taquito and Signatory maintenance when our funding renewal proposals were declined. Meanwhile, behind the scenes, Trilitech and Nomadic had already created a fork of Taquito (Octez-js) prior to the end of our funding period and were pressuring other funded teams to move away from Taquito. Efforts to force funded teams to migrate to the Octez-JS fork were ultimately walked back after we signalled our (continuing) intention to maintain Taquito.

We have heard stories about funding approvals being tied to transferring projects and IP not covered by open source licensing, or only being offered transitional funding to move projects to Trilitech or Nomadic after primary development funding was cancelled.

As more independent teams lose funding and transfer project stewardship to Trilitech and Nomadic Labs, a growing share of the Tezos tooling stack (the Octez node, major SDKs, indexer infrastructure, developer tooling, and a great deal of ecosystem coordination) are now overseen by a smaller leadership group.

This consolidation has already resulted in fewer eyes reviewing code and less input from stakeholders. Extending this consolidation into the signer layer that protects baker keys and governs what gets signed with them, would in our view be unhealthy for the network.

A resilient ecosystem benefits from independent tooling, particularly for security-critical components where separation of concerns is part of the value proposition. This is a structural objection about ecosystem design, not a comment on any individual team’s work.

Can the Tezos Foundation reverse this?

In principle, yes. Funding decisions are theirs to make and unmake.

In practice, the Foundation has now declined two separate funding requests: first for renewal at prior-year levels, and then for a reduced scope maintenance-only protocol tracking engagement with testing, and security response for software that protects keys.

Both were declined. We are publishing this announcement on that basis.

If the Foundation reverses course, we will say so plainly. We are not counting on it.

Closing

Signatory has been one of the more technically demanding pieces of software we have shipped, and we are proud of what it became. Thank you to everyone who has used it, contributed to it, tested it, and helped harden it over the years.

For commercial inquiries, scoping discussions, or migration support, please reach out at info@ecadlabs.com.

We welcome community discussion on this thread, both on migration logistics and on the broader question of how the Tezos ecosystem should sustain critical security infrastructure going forward.

The ECAD Labs Team

[Primate411]

Oh my lord…

Whoever made this decision to radically centralize and kick out faithful teams, hope you’re not confused by the abysmal outcome that’s about to befall us all. You think things can’t get worse but they will.

[murbard]

It should not cost $700K a year to maintain a fairly straightforward mature codebases. Absolutely nowhere near that.

My preference is always to work with external teams, but over the year we’ve seen the playbook happen over and over. A simple but critical piece of infrastructure is built, then massive “maintenance grants” are demanded, under the threat of disruption to the ecosystem or disparagement.

If one wants to understand the consolidation, understand that (with a few honorable exceptions) this has played over and over.

To address another point directly:

We have heard stories about funding approvals being tied to transferring projects and IP not covered by open source licensing, or only being offered transitional funding to move projects to Trilitech or Nomadic after primary development funding was cancelled.

Some teams which were 100% funded by TF have explained that they owned the domain names for the project, that they had no intention of parting with them (though they would abandon the project) and pointed out that asking users to switch would be disruptive to the ecosystem. It’s a way to get leverage.

When this happens, I agree that offering funding in exchange for the transfer is a mistake, it creates bad incentives. It’s best to rip the bandaid.

[Primate411]

Fair enough, that helps a little bit. What about $50,000? Was that a bad deal because it didn’t include tz5 work?

The centralization of tooling is just half of my concern. The other half is the seeming inability to maintain what Trilitech adopts. TzStats, that took weeks to just get running again, didn’t get any Adaptive Issuance updates and was sunset. The reason given was lack of use. Sure, why would anyone use it if it doesn’t even support the current protocol? Would be interesting to see what usage was at the time of the handover. TzGo hasn’t gotten any love either; it’s currently on the chopping block to go.

Are there any examples of excellence on adopted tooling to speak of?

ECAD might be expensive but you cannot point a finger at them and say they don’t know what they’re doing or they don’t care about the quality of their tools.

I want to give credit to Trilitech, I really do. Let’s see what this new slew to adopted tooling brings. Hopefully not a bunch of abandonware. Because everything seems like it should be easier and cheaper before you start doing the work yourself.

[murbard]

@Primate411

Fair enough, that helps a little bit. What about $50,000? Was that a bad deal because it didn’t include tz5 work?

This is definitely not where the numbers started and yet that is still overpriced for a mature tool.

Yes we’ll likely need XMMS sigs support, I will happily do that PR myself in a year time, and it will take me a well focused weekend.

Importantly as well, there is a matter of conduct, at which point the price doesn’t even matter that much anymore.

[Primate411]

Arthur,

You’re very good at telling people their work isn’t worth what they think it is. You’re also very good at doing the work yourself. The problem is those two traits combine into a pattern where you dismiss teams, they leave, and then the work lands on you anyway. At some point you run out of weekends. The community suffers as a result, as their tools get deprecated willy-nilly.

You said you’ll do the XMMS sigs PR yourself in a focused weekend. I believe you. But Signatory isn’t one PR. It’s operator support when someone’s YubiHSM firmware update breaks their signing pipeline at 2 AM. It’s testing every protocol upgrade across AWS KMS, Azure KMS, Google Cloud KMS, Hashicorp Vault, PKCS11, Nitro Enclaves, and Confidential Space, on every OS, with every watermark semantic change. It’s security response when a vulnerability drops. It’s release signing, supply chain integrity, and documentation that operators depend on to not lose their keys.

Are you going to do all of that yourself too? Because if the answer is no, then someone has to do it, and that someone needs to eat. $50K for a year of that work isn’t overpriced. It’s barely break-even for a team that takes the responsibility seriously.

The consolidation pattern you described makes sense from your side: teams build something simple, then demand large maintenance grants under threat of disruption. I get why that’s frustrating. But from the outside it looks different. It looks like independent teams build critical infrastructure, TF pulls funding, Trilitech or Nomadic absorb it, and then it slowly atrophies because the adopting team has ten other priorities and the original maintainers are gone. TzStats didn’t die because it was badly written. It died because nobody fed it. The same thing is happening to TzGo right now.

If the same dynamic plays out with Signatory, the signing layer ends up maintained by people who didn’t build it and have competing priorities, serving operators who have no alternative to run when they disagree with the direction of the protocol. That’s not a criticism of anyone’s engineering. It’s a structural outcome of burning every bridge with independent teams who know their tools cold and care enough to maintain them properly.

You’re brilliant enough to do it all yourself, for a while. But the ecosystem can’t depend on you having a free weekend every time a protocol upgrade breaks something in a KMS backend you don’t personally use. That’s not a sustainable signing layer.

On conduct: you raised it as a factor, and I won’t argue that ECAD handled every conversation perfectly. But conduct goes both ways. When independent teams watch their funding get cut, their work get absorbed, and their concerns get dismissed as a “playbook” in a public forum, they notice. The same precision you use to identify bad-faith behavior in others is visible to everyone when it’s directed at teams who spent seven years building Apache 2.0 infrastructure for this ecosystem. You’re not wrong that some teams have leveraged their position. You are wrong if you think the common factor in every broken relationship is always the other side. At some point the pattern reflects the dynamic, not just the counterparties.

[v32]

It should not cost that much for a mature codebase built on top of a mature and stable platform. Tezos is far from that. It may very well cost that much, or much more that you might expect to do a respectable job. The ecosystem has developed in a way that rewards extreme specialist knowledge. This is the result. Industry standard rates need not apply. You can’t expect to only work with teams that don’t know their worth.

Consolidation into the labs-foundation structure doesn’t bother me. Every chain has it. Getting there has left nothing stable in it’s path and has had far from clean transfers. That is much more concerning. I can’t name a single part of Tezos i trust to still be working the same way a year from now. I won’t blame anyone (there’s enough of that going around), but someone needs to take some responsibility for this mess.

Ideally the core structural issues would be fixed well in advance of cutting support.

[skullzarmy]

Arthur your responses here highlight exactly why this ecosystem is bleeding talent.

When independent teams raise valid concerns your immediate instinct is to accuse them of seeking leverage. That projection says more about how you operate than it does about the teams building Tezos infrastructure. You treat the survival of this network like a personal chess game where developers are just pieces to be maneuvered or sacrificed to consolidate control.

You also completely ignored the actual arguments presented to you. @Primate411 laid out exactly what that 50k covers from operator support at 2 AM to testing across multiple KMS environments and supply chain integrity. Your response was brushing it off and claiming you can do a PR in a focused weekend.

Maintaining a secure and protocol aware signing layer used by exchanges and public bakers is not a weekend hobby project. Instead of addressing the structural failures of centralizing tooling you fall back on vague accusations about conduct. Framing developers who ask for bare minimum maintenance funding as extortionists is just a manipulative tactic to avoid taking responsibility for a broken funding model.

The community does not need a chess master playing games with critical infrastructure. It needs sustainable tooling and leaders who actually listen to the arguments of the people keeping the network running instead of just calculating their next move.

[AlexL]

I find it unfair to say this is a projection on him and how he operates than the teams building Tezos infrastructure (which his team is also building that). If it was only as simple as a chess game and sacrificing pieces for whatever reason, but I think the ultimate reason here is because of austerity measures needing to be made given the state of the entire market, which isn’t just a Tezos problem, as it’s an every blockchain problem.

If he says he can do it, then let’s wait and see before casting judgment maybe?

With all due respect skullz, towards your last point, both is actually needed: the tooling and the people keeping the network running.

[skullzarmy]

@AlexL blaming this on austerity is a massive cop out. The foundation is sitting on half a billion dollars in assets. Refusing a 50k maintenance contract for the only enterprise grade remote signer the ecosystem relies on is not austerity. It is terrible prioritization or a deliberate attempt to starve out independent teams.

As for waiting and seeing if Arthur can do it himself, you do not play wait and see with enterprise key management and security infrastructure. A weekend PR does not cover emergency support or testing across different cloud environments when things break. Arthur has repeatedly shown he cannot properly scope the actual scale of this software, let alone scope or build a proper replacement for it. Treating an enterprise grade, multi cloud security layer like a casual weekend project completely misjudges the engineering reality. If a signing pipeline goes down bakers lose keys and the whole network suffers.

You say we need both tooling and people and I agree completely. But centralizing all the tooling under one umbrella and pushing out the independent people who actually built it destroys that exact balance. You cannot run a decentralized network by putting all the critical infrastructure in the hands of a single small group that treats security like a weekend hobby.

[murbard]

We cannot build a successful ecosystem or community by taking a bunch of random infrastructure bits, and having them built for over 10x the cost by a collection of companies.

In 2018 TF was paralyzed with fear of doing anything itself and “bought” a lot of friends this way. It didn’t move the needle then, it absolutely won’t now.

This was a terrible idea and it backfired badly. As soon as budget started being reigned in seriously around 2022, it became a long battle of threats , attempted extorsion, long online disparagement campaigns.

This is not true of all the teams, some have always been reasonably priced and done excellent work. And not all of them have resorted to extreme measures, liike theft in one instance. But it is true of the majority of them.

Overpaying doesn’t buy loyalty, it creates a situation where people will be willing to do bad things to keep it going.

[Val]

That makes me wonder about the actual numbers here. Is the 10x multiplier literal compared to TT’s operating costs, or is it a figure of speech? And on that note, was the suggested $700k meant just for the signatory itself, or for the entire ECAD operation?

Setting the numbers aside, if decentralized community teams aren’t the answer, how do we actually build a successful ecosystem from your perspective? Just trying to get a realistic ballpark and understand the strategy here.

As a side note on the domain handover—I can completely understand why a team wouldn’t want to just give up signatory.io willingly. Good domains and brand names are hard to establish, and since Signatory does not have to be a tezos-specific domain, it definitely holds value outside of this project. (Though I assume your point about community teams was meant generally rather than just about this specific case.)

[murbard]

$700K covered more things, but also libraries which need minimal maintenance. This is after a serious reduction of cost over the years. Taq was supposed to be a full fledged ide and cost an eye watering amount

Do teams at TT or NL sometimes not do a good job, waste resources, not deliver. Of course. But when they do, teams can be reorganized and we don’t have to deal with online disparagement campaigns, threats, disruptions to the ecosystem because domain names have to be changed.

As more money be wasted on very dumb things? Absolutely, but that still doesn’t mean budgetary discipline shouldn’t exist.

As to how to build a successful ecosystem, I think by focusing and helping products on the chain which have meaningful traction and revenues grow. Buying friends does not work.

[tokyo_on_rails]

I’ll start off by saying I love the ECAD team and they have always done great work, and I’m going to address the general topic rather than ECAD’s personal situation.

I think Arthur’s point is being interpreted more narrowly than intended, and it’s difficult to include all of the factors and history that go into his statements.

The question is not whether Signatory or other tools required significant engineering effort to build or maintain. Of course people invested time and expertise over the years, and continue to during maintenance.

The primary concern that I am aware of is that infrastructure (not only ECAD, as this became a larger broad discussion) which became important to parts of the Tezos ecosystem ended up in a position where continued availability, maintenance, branding, domains, and project stewardship appear to depend on a single organization continuing to receive their requested funding, which might be more than TF is willing to pay for the proposed work.

If that characterization is accurate, then the ecosystem should reflect on how it got there. Critical infrastructure should ideally be easy for others to maintain, fork, operate, and assume responsibility for when priorities change. Ideally without needing to change the name, domains, etc.

I don’t see this as criticism of the engineers who built the software. Rather, it is a discussion about governance, dependency risk, and the expectations around funding public goods. As others have mentioned, we have had this happen a number of times, and every time it forces either migrations or projects becoming unusable.

The ecosystem should be able to thank and appreciate ECAD and others for their work while also agreeing with Arthur that no critical component should effectively become indispensable through funding dynamics alone.

Perhaps all of us providing infrastructure to the ecosystem can proactively structure things in a way as to alleviate such concerns before they pop up, so that the Foundation doesn’t feel that anything the ecosystem is dependent on could possibly become a liability in the future, even if the team has been 100% trustworthy thus far.

Things TF and we as infrastructure providing teams could maybe try to do better going forward:

• Structuring funding/projects for critical infrastructure in such a way so that it alleviates the concerns. If not wanting the Foundation to own the IP while an outside team works on it, then funding agreements could include transition plans for project assets if the team ever ceases to maintain it.
• If scope has decreased because something has matured, work with the Foundation to determine what new work might be needed or desired, even if it’s not related to the specific project being funded. A price tag might seem high to some people if something becomes mainly maintenance, but not when you consider that there are engineers on payroll and that is their only job, and they are on call 24/7. But if we have those engineering resources and they have any extra time due to decreased scopes over time, maybe they can be utilized elsewhere too.
• Be willing to propose reduced budgets if the work being proposed is less than it was previously, without waiting for TF to counter a proposal.

From a TC perspective we try to:

• Proactively offer reduced budgets if we know overall ecosystem budgets are being reduced, market is bad, etc. This includes major reductions on things that have had a reduced scope over time as they’ve matured. Or at least fill the gaps with new proposed work to replace what has been reduced.
• Fill up any extra time we may have by helping out other teams, taking on side projects, volunteering on things that were not in our grant proposals, etc. Our contract even has points in it that are purposely vague and allow others to come to us for help, whether it’s engineering projects, boots on the ground around the world, taking on integrations that we didn’t source ourselves, etc.

Not saying any specific teams didn’t try any of this and I’m not aware of all negotiations that took place, I can only speak from our perspective as a recommendation to others, but in some cases there are certainly teams that got comfortable with inflated budgets and didn’t do anything to rectify it (in general about past experiences, not talking about ECAD).

[Val]

Do teams at TT or NL sometimes not do a good job, waste resources, not deliver. Of course. But when they do, terms can be reorganized and we don’t have to deal with online disparagement campaigns, threats, disruptions to the ecosystem because domain names have to be changed.

I didn’t mean to question the quality of work at all. I was honestly just wondering about the economics—whether TT can deliver/maintain for the 1/10th of the ECAD cost.

Buying friends does not work.

I completely agree that real relationships are built, not bought. But given the years of shared history here, I would have expected some path to a compromise that works for both sides. I’m only guessing based on rumors, but it seems like counteroffers aren’t really a thing. When the market reshapes as drastically as it is, I can imagine it being incredibly difficult for teams to figure out what the expectations actually are.

Btw thank you for taking the time to respond and share your perspective here @murbard

[tokyo_on_rails]

@Val

I didn’t mean to question the quality of work at all. I was honestly just wondering about the economics—whether TT can deliver/maintain for the 1/10th of the ECAD cost.

I think it can become difficult for a team that has a decreased scope over time but still have the same salaries you need to pay, and you naturally don’t want to have to let people go unless you absolutely need to. So you might have a team of multiple highly skilled engineers maintaining a project that maybe doesn’t require full-time hours from each member anymore, and you either need to find new work for them to do that everyone agrees is worth the amount being funded, or let people go.

It’s a tough call nobody wants to make, but on the other side when TF sees something cost a lot of money but looks through commits and comes to the conclusion that it shouldn’t cost X amount to do the work, while also coupled with the risks they’ve experienced in the past that come with not having rights to the IP, it might make them start to reconsider.

[Val]

To your point about structuring things better, maybe there is a hybrid approach or a dual-branding model that could give us the best of both worlds. For example, infrastructure teams could link their tools and libraries to TF-owned domains while keeping their own branding alongside it.

Speaking from our perspective with TzC—we could provide something like gov.tezos.com alongside gov.tez.capital. For newcomers and users, having that official domain makes the tool feel way more reputable. Without that we are sitting on a third-party domain, we are always playing the ‘next in line’ game rather than being seen as the go-to standard, which hurts adoption.

Historically, though, it never really felt like there was a desire to form that kind of partnership or co-branding.

[skullzarmy]

@murbard

We cannot build a successful ecosystem or community by taking a bunch of random infrastructure bits, and having them built for over 10x the cost by a collection of companies.

@murbard I get wanting budgetary discipline after watching money get wasted over the years. That makes complete sense. But saying we should only focus on revenue generating products and that funding independent infrastructure is just buying friends is a massive red flag.

Base layer security tools like remote signers do not generate revenue. They are public goods. If the foundation will not fund them and TT and NL just absorb it all because managing independent teams is frustrating then we are quietly giving up on a decentralized ecosystem.

Efficiency matters but centralizing critical infrastructure under one roof is a dangerous pivot for a network built on decentralization.

Edit just to add one more thing. Even if everything you claim about ECAD is completely true, handing a contract to internal players without a single RFP is backroom dealing at best. There is no public process to choose who should provide this critical work and at what cost. It is all just done behind closed doors.

[murbard]

As a further fyi,

the staff at TF was recently cut by nearly 2/3. There are consultation processes ongoing at NL and TT where it is likely that we will unfortunately have to part ways with a large number of people, the entire Trilitech Office inaugurated in 2021 has been let go to focus on a much smaller office with most of the work going remote.

The OP promulgates the idea that the decision not to fund ECAD is somehow self-serving for these entities who pull the strings. It’s not, these decisions are based on costs, and most of the cost cutting comes from reducing budgets to these entities.

[Val]

From my perspective, it would actually be really helpful if facts like the 2/3 staff cut were shared more widely. (Maybe it will be in the next report) If the community could see the harsh reality of the costs and cuts everywhere, it would go a long way in shifting the perspective away from the idea that it’s self-serving and help people see the bigger picture.

I get it—there is a lot of negativity and a lot of pressure on all sides. We are all just people at the end of the day. We have our lives, our fates, and we all need to eat. It’s natural to get defensive when we’re under pressure. In recent years, it feels like we are all alienating each other and forgetting that Tezos has to be about people too to make any sense. It would be nice if we could all open up a bit more and understand each other better, but I guess I’m a dreamer.

Anyway, good luck! I will leave it for others from here.

Thanks @murbard and @tokyo_on_rails for the responses. A huge thanks to ECAD and @jevonearth personally—it was always great to work with you, and I hope there is a way forward from here.