Becoming the Readiness Gate for Another Team's Scale-Up

Most engineering work gets justified by its own metrics: faster, cheaper, more reliable. Some of the most consequential work gets justified by someone else's roadmap depending on it. That was the actual shape of the concurrency and trigger-removal work described elsewhere in this series. It wasn't scoped because SupraScan's own dashboards demanded it. It was scoped because a separate team, building automated on-chain task execution, had explicitly tied their own launch decision to it.

A capability that was ready, gated by a system that wasn't yet

The automation team had already done real validation work of their own: their Automation V2 system had been privately tested to handle 100,000 concurrent tasks on a private test network. That's not a small number, and it's not a hypothetical claim either, it was measured. And yet, that team explicitly agreed not to raise the live, on-chain capacity limits for real automated tasks on a real network until the indexer's ability to handle that scale was confirmed.

That's an unusual kind of commitment for one team to make around another team's infrastructure, and it only makes sense once you understand what those capacity limits actually control. The chain enforces a default cap on how many tasks a single account can register, alongside a separate cap on the total gas budget those tasks can consume, plus a lower, distinct ceiling for tasks registered through a governance process rather than a normal account. None of these caps are hard-coded ceilings in the underlying protocol logic; every one of them is adjustable through a standard configuration update, with no code change required. The only thing standing between the current limit and a much higher one is a decision to raise it, which means the real gate on scaling automation usage was never a protocol constraint. It was confidence that the systems consuming the resulting transaction volume, this indexer chief among them, wouldn't buckle the way it already had once, during the four-wallet contention incident that first exposed the trigger-locking problem this same work fixed.

Why the dependency was structurally sound, not just cautious

It would be easy to read this as one team simply being conservative. The more precise read is that the dependency was well-scoped because of how automation execution actually behaves on-chain: each registered task executes at most once per block. That means the worst-case number of executions in any single block scales linearly with whatever the capacity cap is set to, not multiplicatively or unpredictably. A team raising that cap can reason precisely about the additional load it introduces, which is exactly the kind of predictable, boundable increase that makes "we'll raise this once the downstream system is proven ready" a decision you can actually commit to, rather than a vague promise to be careful later.

That precision is also what made this indexer's readiness work legible as a real gate rather than a soft suggestion. The automation team didn't need to trust a general assurance that "the indexer should be fine." They could point to a specific configuration value, know exactly how it maps to worst-case block-level load, and wait for confirmation that the exact failure mode which had already happened once, contention on a small number of hot wallet rows under concurrent load, had been genuinely closed.

What this demonstrates

The trigger-removal and concurrency work described in this series would have been worth doing on its own merits, the four-wallet incident alone justified it. What makes it a more interesting case study than a standard reliability fix is that a different team's product roadmap was explicitly, formally waiting on it. That's a different kind of leverage than fixing your own system's stability. It's being the reason someone else's already-validated capability sat unused on a real network until the work described here shipped, verified, across every environment. Infrastructure work rarely gets to point at a concrete, named dependency like that. When it does, it's worth naming directly instead of folding it quietly into a general reliability narrative.