In May, the Aztec Foundation ran a feedback survey for sequencer operators, provers, delegators, and people preparing to set up a node. The goal was to make sure the work we prioritise reflects what operators actually need.
This post summarises what came back, what is being worked on already, where we’re still thinking, and a small number of points where we want to clarify because the situation isn’t quite what the feedback assumed.
We received 45 responses across two weeks. Thank you to everyone who took the time. By our estimate, the responses represent roughly half of the active sequencers on the network, and we heard from the full spectrum of operator types.
Who responded
The mix breaks down as follows:
· 17 solo sequencers (38%)
· 13 large providers running >10 sequencers (29%)
· 9 small providers running ≤10 sequencers (20%)
· 3 delegators (7%)
· 2 prover-only operators (4%)
· 1 person considering joining (2%)
Respondents by operator type.
Pain points that surfaced consistently across solo operators, small providers, and large providers are the ones we’ve prioritised below. Items raised by only one segment are noted where useful, but weighted accordingly.
Top five themes
1. Monitoring and alerting
This was the clearest single signal in the survey. Operators consistently said there is no official, end-to-end answer for the “is my node healthy, and if not, what should I do” question. Most operators we heard from have built their own monitoring stack with custom scripts, AI-assisted Grafana dashboards, or community-built tools.
We hear this and agree it’s a gap. An official monitoring and alerting reference, both as documentation and as a starting-point dashboard set, is on the roadmap. We want this to coexist with the community tools operators already rely on rather than replace them. The Foundation’s contribution is meant to lower the floor for new operators and standardize the metric names. Timeline will be shared once it’s firmed up.
2. Coinbase address management for providers
Almost every provider that responded mentioned some version of this. Each new delegation creates a new split-contract address that has to be added to the relevant sequencer’s keystore. At provider scale, this becomes a real workflow problem, and several providers have built their own tooling to manage it.
We agree this should not be the operator’s problem to solve at the keystore level. The Foundation is working with Aztec Labs on changes to the L1 contracts that would make the coinbase an on-chain parameter set at delegation time, rather than something the operator configures and maintains per-sequencer.
This is the direction. Details on what the change looks like and how operators will experience it will follow as the design firms up. Stay tuned for more in the coming weeks.
3. Documentation is fragmented
This came through from multiple operators. The framing wasn’t that the docs are too complex or too simple — it was that they are scattered across multiple locations, occasionally inaccurate, and missing specific operator-critical topics.
A docs rework is in progress to consolidate operator-relevant content into a single navigable surface, correct the inaccuracies operators flagged, and fill in the gaps.
For balance, several respondents also told us the docs work well for them today. The goal is to raise the floor without breaking what already works.
4. Upgrade and release communication
Operators want earlier notice, clearer changelogs, less ambient noise, and more reliable delivery than a single Discord channel.
We’re designing what the next version of release communication should look like. Two pieces are in motion:
· An option for operators to upgrade automatically through an upgrade is being explored to remove the problem entirely for operators who want a hands-off path.
· A more institutional release-communication pipeline — a single source of truth, fan-out to the channels operators actually monitor, predictable cadence, structured release notes. Being scoped now.
The direction is to keep Discord as one channel among several rather than the default. More details will follow once the design is firmer.
5. Provider economics
Several providers raised the structural concerns around commission and the gap between current rewards and current L1 gas costs. This is the most-discussed topic in operator channels right now, and it is one we are actively working on.
There has been continuous internal discussion, and the Foundation has agreed on a near-term format that will be presented soon. It will be a temporary solution while we work on a longer-term answer that may require contract changes and will therefore take more time.
We also want to be honest about scope. There are things the Foundation is well-positioned to help with — better information, better tooling, better protocol-level mechanics — and there are things the Foundation, by design, is not in a position to do. Provider economics will improve as the network matures, but the path is structural rather than discretionary.
Smaller items worth surfacing
A handful of points didn’t make the top five but are worth addressing directly, particularly where the underlying assumption isn’t quite right or where a solution already exists that operators may not be aware of.
HA migration before V5
Three respondents told us they are still running an older HA setup that shares a publisher key across nodes. This topology is no longer supported, and operators on it will be at risk once the slashing conditions in V5 activate, currently targeted for mid-July.
If you are still running the older setup, please migrate to the documented Postgres-coordinated HA before V5.
One related clarification: some operators have told us that running Postgres-coordinated HA increases L1 gas costs. This is not the case in the documented setup. It is specifically designed so that only one node publishes per duty, so the L1 gas profile matches a single-node setup. The older shared-publisher topology had both nodes attempting to publish (creating duplicates), and we believe the concern may be a holdover from that experience.
Reward claiming
Several operators flagged that reward claiming is fragmented across rollup versions and that the dashboard doesn’t scale for providers with many sequencers. The relevant work has already shipped: the Aztec Staking Dashboard now consolidates reward claiming across rollup versions and supports batched claims. If you’ve tried recently and the flow didn’t work as expected, please let us know so we can dig into the specific case.
Centralisation of the sequencer set
A small number of respondents raised concerns about how centralised the active sequencer set has become. The on-chain numbers don’t fully bear this out: between the end of January and the end of May, every concentration metric we track moved towards a more even distribution:
· Top-5 provider share of active stake: 51.8% → 49.1% (−2.7 pp)
· Top-10 share: 70.6% → 68.0% (−2.6 pp)
The chart below shows the Top-5 and Top-10 lines alongside the active provider count over the same window:
Top-5 and Top-10 provider share of active stake with active provider count, Jan–May 2026.
Total staked supply contracted modestly over the same period, which is a separate and real concern, but speaking of concentration specifically, the trend has been toward a more even distribution.
Governance voting UX
One respondent said that voting on a governance proposal requires editing an environment variable and restarting the container. This is no longer the case. The proposer payload address can be updated at runtime through the node’s admin API. The governance voting docs walk through the exact nodeAdmin_setConfig call.
We’ll surface this in the next governance proposal announcement, so it isn’t buried in the docs.
OTLP / metrics labels across restarts
One respondent described Grafana dashboards breaking on every docker restart because metric labels were changing. The root cause is the OpenTelemetry SDK auto-generating a fresh service instance ID on every process start.
The fix exists today: setting OTEL_RESOURCE_ATTRIBUTES=“service.instance.id=my-sequencer-01” in the environment pins a stable instance ID across restarts. The Aztec telemetry client honours this via the standard OpenTelemetry environment detector. This isn’t currently in the operator-monitoring docs and should be. We’ll add it as part of the docs rework.
What comes next
The actionable items from this survey are being tracked, and the workstreams above will surface in the relevant channels as they progress.
We won’t be running another full survey of this shape in the immediate future. What we heard here is enough to work from for the next quarter. If anything arises, the operator channels remain the right place to flag it.
Thank you again to everyone who took the time. The depth of the responses was the most useful single signal we’ve had on operator priorities since the Alpha launch, and the next round of work reflects that.