Picking up on the validator tooling section — we would like to put our hand up for upgrade notifications.
Some context on why us rather than someone else: we already run a version of this for ourselves. VoidStake operates a monitoring stack for our own Hub validator — scheduled workers polling chain state, node health checks, and alerting on validator state with email and Telegram delivery. Adding a configurable notification layer is an extension of something already in production, not a greenfield build. (our validator profile, for context on who we are.)
What we could operate:
- Configurable upgrade notifications, with email as a first-class delivery channel alongside webhooks. Email was raised specifically in the Q&A and it is the straightforward part.
- A maintained upgrade-history record, also raised on the call. We would want this as structured data behind a public endpoint rather than a wiki page, so that other operators’ tooling can consume it rather than scraping it.
Three questions before anyone commits to anything, because “public good” should mean something more specific than enthusiasm:
- Is the configurable-upgrade-notification tool that was demoed going to be open-sourced? If so, we would much rather operate and maintain the Hub’s implementation than stand up a parallel one. Two competing notification services would be a worse outcome for operators than one maintained properly.
- What is the expected reliability bar? A notification service is only worth having if operators trust it enough to stop double-checking, and that implies an on-call commitment rather than best-effort. We are willing to take that on, but it should be stated explicitly rather than assumed, and it should be clear what happens if whoever operates it steps away.
- Who should hold the subscriber list? Operator contact details are the one genuinely sensitive piece here. We would rather the Hub owned that list and we delivered against it than accumulate operator emails ourselves by default — but we are happy either way if there is a clear preference.
One piece of operational feedback from standing up a fresh provider testnet node today, in case it is useful for the joining guide: state-sync was OOM-killed at the final snapshot chunk until we raised the memory ceiling — the IAVL restore peaks around 8.5 GB. What makes it costly is that the failure is silent, and the next start fails with found database at version N, must be 0, which sends you looking at state-sync config rather than at memory. A line in VALIDATOR_JOINING_GUIDE.md noting the peak requirement would save the next operator an afternoon.
Happy to go into any of this on the September 16 call if that is a better venue than the forum.