## Name of Grant
**RP Node Pulse — self-hosted monitoring, paging and public reliability
dashboards for Rocket Pool node operators**
### What is the work being proposed?
We will productize and open-source the monitoring + alerting system HostDeFi
already runs in production across a multi-network validator fleet, packaged as
a drop-in stack for Rocket Pool Smartnode operators. Four deliverables:
1. **rp-pulse-agent** — a small, read-only collector that runs next to the
Smartnode stack. It polls the execution client (JSON-RPC), the consensus
client (Beacon API), the Rocket Pool contracts (minipool status, bond,
fee-recipient, smoothing-pool membership) and host metrics (disk, peers,
clock drift). It signs nothing, holds no keys, binds loopback only, and
makes outbound connections only.
2. **rp-pulse-server** — a self-hosted off-box alert server (single binary +
docker-compose, runs on any free VPS tier or a spare machine). Deep checks
every 60 s plus a 3 s “is the box alive / are the clients answering” fast
path, so a frozen, unplugged or hung node still pages the operator —
the exact blind spot of running Alertmanager inside the same box that can
die. Alert rules cover: EL/CL dead-or-hung (answers but stops advancing),
missed-attestation streaks, proposal missed, sync-committee duty,
pre- and post-sync-attestation participation, minipool state transitions
(promoted/staked/dissolved), bond-reduction events, fee-recipient changes,
low disk, peer-count drops and clock skew. Optional self-heal hooks ship
disabled by default (e.g. container restart on verified hung-client) —
alerting first, remediation strictly opt-in.
3. **Operator Reliability Board** — a public, per-operator dashboard
(opt-in via signed challenge or node-address registration) showing
uptime, attestation effectiveness and incident history — giving
prospective NOs a public track record to point at and the community a
neutral view of fleet health.
4. **Upgrade & snapshot notifier** — watches Smartnode releases, client
releases (Geth/Reth/Nethermind/Besu + Lighthouse/Prysm/Teku/Nimbus/
Lodestar) and Rocket Pool contract events, and pings operators with
“your stack is N releases behind / a contract event requires action”
notices over the same alert channels.
Alert channels: Telegram, Discord, email and generic webhook at launch —
chosen because they are what small operators actually read. Delivered as
MIT-licensed code with a one-command `docker compose up` install and a
documented uninstall.
### Is there any related work this builds off of?
- **Smartnode’s built-in alerting** (Prometheus + Alertmanager inside the
Smartnode stack) — we complement it, not replace it. Its alerts die with
the box and it has no dead/hung-client rule.
- **beaconcha.in watchlist alerts** — off-box and free, but
notification-only, per-account, not self-hosted, and unaware of Smartnode
internals (minipool state, fee recipient, bond changes, smoothing pool).
- **NodeBeat** (announced on this forum 2026-10-06) — a hosted alerting
SaaS with an open-source agent. We differ in three ways: everything we
ship is open and self-hostable (no dependency on a third-party service’s
uptime or pricing), we ship a **public** per-operator reliability board,
and we include the upgrade/snapshot notifier. Both can coexist; the gap
they expose — on-box alerting blindness — is the same one our fleet
monitoring was built to close.
- **Rescue Node** — complementary: Rescue Node answers your validator when
you are down; RP Node Pulse is how you find out you are down before the
misses accrue.
- The internal HostDeFi fleet monitor this is ported from — in production
today across our Solana, Cosmos-SDK, NEAR and Ethereum (Hoodi Obol DVT)
infrastructure with the same 60 s deep + 3 s fast check cadence,
self-heal autofixes and direct operator paging.
### Will the results of this project be entirely open source (MIT, GPL, Apache, CC BY license or similar)? If not, which parts will not be, why, and under what license will they be published?
Yes — 100% MIT. Agent, server, dashboard, notifier, dashboards-as-code,
docs and deployment manifests all ship in a public repository from the
first milestone. No hosted component is required: the reference deployment
we run is itself just the open source stack.
## Benefit
| Group | Benefits |
|—|—|
| Potential rETH holders | More reliable node operators → a healthier validator set securing the ETH their rETH is staked against. The public Reliability Board makes operator quality visible, which is an indirect trust signal for the protocol. |
| rETH holders | Faster detection and recovery of operator downtime means fewer missed attestations/proposals across the set → better and more consistent rETH yield performance vs. solo baseline variance. |
| Potential NOs | Lowers the scariest part of running a node — “how do I know if it’s broken at 3 a.m.?” — with a free, self-hosted, one-command answer. The public board gives new operators a way to build a visible track record. |
| NOs | Direct: dead/hung-client paging in seconds instead of finding out from beaconcha.in after the misses; Smartnode-aware alerts (minipool transitions, bond, fee recipient) nothing else provides off-box; upgrade notifications so client releases don’t get missed. Self-hosted means no SaaS lock-in and alerts survive the monitored box dying. |
| Community | Public operator-reliability data (opt-in) gives the community a neutral health view of the node set and a concrete quality signal for oDAO/minipool-economics discussions. |
| RPL holders | Better operator reliability → better protocol performance → healthier RPL-denominated incentives. A funded, maintained public-good monitoring stack reduces operator churn, which protects the network the RPL bond depends on. |
### Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?
The agent’s collectors are Rocket-Pool-aware but its health engine is
client-generic, so solo stakers and DVT operators on the same clients get
value immediately. We expect downstream reuse by Lido CSM operators and
Hoodi/Holesky testnet operators, and the public dashboard schema is useful
to researchers tracking validator-set health. We will say so plainly in the
docs; no other protocol funds this work and none is promised delivery.
## Work
### Who is doing the work?
HostDeFi Validator Collective — an operator collective that runs production
validator infrastructure across multiple networks. The work is executed by
the collective’s engineering operation (Devin-driven, human-supervised);
no individual is being paid by this grant — funds go to the recipient
address listed below to cover build, hosting and maintenance.
### What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
- We operate a multi-network validator fleet: Solana testnet validator
enrolled in the Solana Foundation Delegation Program (TestnetOnboarded,
~315k testSOL activated), an Obol distributed-validator cluster on Hoodi
(32 ETH validator `active_ongoing`, attesting), a NEAR staking pool
registered on-chain (`hostdefi.pool.near`), a Babylon finality provider,
and an approved Canton Validator Operator seat.
- We run public RPC infrastructure across 80+ networks
(`rpc.hostdefi.com`, `chain-rpc.hostdefi.com`) — customer-facing
endpoints, not just our own stake.
- The monitoring system being productized is already in production on our
own fleet: 60 s deep health checks, 3 s fast liveness checks, self-heal
autofixes and direct operator paging — this grant packages proven
internal tooling rather than building from a blank page.
- For Smartnode-specific validation we will stand up a Hoodi Smartnode
minipool during Milestone 1 and run the tool against it for the
remainder of the project.
### What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Award expected ~2026-11-29; dates below are from award.
- **Milestone 1 — core agent + alert server (by 2026-12-19, ~3 weeks).**
Repo public. `rp-pulse-agent` collecting EL/CL/host/RP-contract signals;
`rp-pulse-server` with the 60 s + 3 s check engine, alert-rule set and
Telegram + webhook channels; docker-compose bundle; Hoodi Smartnode
test minipool live under the tool. **$2,500**
- **Milestone 2 — dashboards + full channels (by 2027-01-23, ~5 weeks).**
Operator Reliability Board public (opt-in), Discord + email channels,
upgrade/snapshot notifier live for Smartnode + all major EL/CL clients,
docs site, uninstall/clean-room verified install. **$2,500**
- **Milestone 3 — hardening + handover (by 2027-02-20, ~4 weeks).**
Fault-injection test report (hung-client, dead-host, API-stall
scenarios), signed releases + SBOM, public demo instance against Hoodi,
maintenance plan activated (below), community feedback pass from the
forum/Discord incorporated. **$2,500**
### How is the work being tested? Is testing included in the schedule?
Yes — testing is inside every milestone, not appended:
- Unit + integration tests in CI from M1 (client simulators for each
EL/CL pair; alert-rule golden tests).
- Fault-injection suite in M3 on the Hoodi rig: kill EL, hang CL API
(answers but stops advancing), freeze host, drop peers — with
measured alert latency published in the report.
- Real-operation soak: the tool monitors our own Hoodi Smartnode
minipool continuously from M1; uptime of the tool itself is
self-monitored and published on the dashboard.
### How will the work be maintained after delivery?
12 months of maintenance included in the ask: tracking Smartnode and
client releases (rule/schema updates within 7 days of a breaking client
API change), security patches within 72 h for criticals, issue triage on
the public repo, and a `MAINTENANCE.md` + `handover` doc so the community
can fork cleanly if we ever go dark. The reference public dashboard
deployment stays up for the same period. Renewal to be decided with the
GMC after delivery — by then the codebase stands on its own regardless.
## Costs
### What is the acceptance criteria?
- Repo public since M1, MIT-licensed, tagged releases for each milestone.
- M1: agent + server + compose install works on a clean VM; the Hoodi
minipool is visible in the tool with live metrics.
- M2: opt-in public dashboard shows at least our Hoodi operator entry
live; alerts verifiably arrive on ≥3 channels in fault-injection runs.
- M3: fault-injection report published (all four failure modes detected,
latencies stated); signed releases + SBOM; docs complete enough that a
stranger can install without our help (we verify with a clean-room
install recording).
### What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
**$7,500 total**, milestone-gated: $2,500 on M1 acceptance (~2026-12-19),
$2,500 on M2 (~2027-01-23), $2,500 on M3 (~2027-02-20). Payable in RPL
equivalent at time of payment if the GMC prefers. Roughly 12 weeks of
build + 12 months of included maintenance and hosting for the public
instance.
### Who will directly receive the payment? (Required — the GMC can only send grants directly to a recipient address and cannot accept invoices.)
HostDeFi Validator Collective — fleet operations wallet:
`0x5fD498D85e328D2c245932dfFe7684c351e40930` (EVM, controlled by the
collective; we can sign a verification message on request).
### How will the GMC verify that the work delivered matches the proposed cadence?
- Public repo with commits/issues/tags from day one — progress is
auditable commit-by-commit.
- Each milestone ships a forum reply in this thread linking the release
tag + the live Hoodi demo dashboard URL + the milestone’s evidence
artifacts (fault-injection report, clean-room install recording).
- The public dashboard instance is itself the living proof-of-cadence —
its uptime and coverage are visible to the GMC at any time.
### What alternatives or options have been considered in order to save costs for the proposed project?
- **Extend Smartnode’s own Alertmanager rules** — rejected: on-box
alerting still dies with the box; it cannot close the core failure mode.
- **Point operators at hosted SaaS (NodeBeat-style)** — rejected as a
deliverable: solves the same gap but moves operators onto a paid
dependency; we still encourage operators who want zero ops to use it.
- **Smaller ask / agent only** — considered dropping the public dashboard
to ~$5k, but the dashboard + notifier are where the *public* benefit
(transparency for potential NOs and rETH holders) concentrates; the
marginal cost is small relative to the value.
- The monitoring engine is already built and battle-tested internally —
the grant pays for productization, Smartnode-specific signals, the
public surface, docs and maintenance, not ground-up R&D.
### Have you already been compensated by the RP protocol in any way for this work?
No. No prior GMC grants, bounties, retrospective awards or oDAO
compensation.
## Conflict of Interest
### Does the person or persons proposing the grant have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the grant).
None. No GMC membership or financial relationship with any GMC member.
### Will the recipient of the grant, or any protocol or project in which the recipient has a vested interest (other than Rocket Pool), benefit financially if the grant is successful?
Indirectly and incidentally only: we will run the tool on our own future
Rocket Pool and other-network infrastructure (it is, by design, the same
monitor we use ourselves), and it may modestly improve our own validator
uptime — the same benefit any operator gets fro## Name of Grant
**RP Node Pulse — self-hosted monitoring, paging and public reliability
dashboards for Rocket Pool node operators**
### What is the work being proposed?
We will productize and open-source the monitoring + alerting system HostDeFi
already runs in production across a multi-network validator fleet, packaged as
a drop-in stack for Rocket Pool Smartnode operators. Four deliverables:
1. **rp-pulse-agent** — a small, read-only collector that runs next to the
Smartnode stack. It polls the execution client (JSON-RPC), the consensus
client (Beacon API), the Rocket Pool contracts (minipool status, bond,
fee-recipient, smoothing-pool membership) and host metrics (disk, peers,
clock drift). It signs nothing, holds no keys, binds loopback only, and
makes outbound connections only.
2. **rp-pulse-server** — a self-hosted off-box alert server (single binary +
docker-compose, runs on any free VPS tier or a spare machine). Deep checks
every 60 s plus a 3 s “is the box alive / are the clients answering” fast
path, so a frozen, unplugged or hung node still pages the operator —
the exact blind spot of running Alertmanager inside the same box that can
die. Alert rules cover: EL/CL dead-or-hung (answers but stops advancing),
missed-attestation streaks, proposal missed, sync-committee duty,
pre- and post-sync-attestation participation, minipool state transitions
(promoted/staked/dissolved), bond-reduction events, fee-recipient changes,
low disk, peer-count drops and clock skew. Optional self-heal hooks ship
disabled by default (e.g. container restart on verified hung-client) —
alerting first, remediation strictly opt-in.
3. **Operator Reliability Board** — a public, per-operator dashboard
(opt-in via signed challenge or node-address registration) showing
uptime, attestation effectiveness and incident history — giving
prospective NOs a public track record to point at and the community a
neutral view of fleet health.
4. **Upgrade & snapshot notifier** — watches Smartnode releases, client
releases (Geth/Reth/Nethermind/Besu + Lighthouse/Prysm/Teku/Nimbus/
Lodestar) and Rocket Pool contract events, and pings operators with
“your stack is N releases behind / a contract event requires action”
notices over the same alert channels.
Alert channels: Telegram, Discord, email and generic webhook at launch —
chosen because they are what small operators actually read. Delivered as
MIT-licensed code with a one-command `docker compose up` install and a
documented uninstall.
### Is there any related work this builds off of?
- **Smartnode’s built-in alerting** (Prometheus + Alertmanager inside the
Smartnode stack) — we complement it, not replace it. Its alerts die with
the box and it has no dead/hung-client rule.
- **beaconcha.in watchlist alerts** — off-box and free, but
notification-only, per-account, not self-hosted, and unaware of Smartnode
internals (minipool state, fee recipient, bond changes, smoothing pool).
- **NodeBeat** (announced on this forum 2026-10-06) — a hosted alerting
SaaS with an open-source agent. We differ in three ways: everything we
ship is open and self-hostable (no dependency on a third-party service’s
uptime or pricing), we ship a **public** per-operator reliability board,
and we include the upgrade/snapshot notifier. Both can coexist; the gap
they expose — on-box alerting blindness — is the same one our fleet
monitoring was built to close.
- **Rescue Node** — complementary: Rescue Node answers your validator when
you are down; RP Node Pulse is how you find out you are down before the
misses accrue.
- The internal HostDeFi fleet monitor this is ported from — in production
today across our Solana, Cosmos-SDK, NEAR and Ethereum (Hoodi Obol DVT)
infrastructure with the same 60 s deep + 3 s fast check cadence,
self-heal autofixes and direct operator paging.
### Will the results of this project be entirely open source (MIT, GPL, Apache, CC BY license or similar)? If not, which parts will not be, why, and under what license will they be published?
Yes — 100% MIT. Agent, server, dashboard, notifier, dashboards-as-code,
docs and deployment manifests all ship in a public repository from the
first milestone. No hosted component is required: the reference deployment
we run is itself just the open source stack.
## Benefit
| Group | Benefits |
|—|—|
| Potential rETH holders | More reliable node operators → a healthier validator set securing the ETH their rETH is staked against. The public Reliability Board makes operator quality visible, which is an indirect trust signal for the protocol. |
| rETH holders | Faster detection and recovery of operator downtime means fewer missed attestations/proposals across the set → better and more consistent rETH yield performance vs. solo baseline variance. |
| Potential NOs | Lowers the scariest part of running a node — “how do I know if it’s broken at 3 a.m.?” — with a free, self-hosted, one-command answer. The public board gives new operators a way to build a visible track record. |
| NOs | Direct: dead/hung-client paging in seconds instead of finding out from beaconcha.in after the misses; Smartnode-aware alerts (minipool transitions, bond, fee recipient) nothing else provides off-box; upgrade notifications so client releases don’t get missed. Self-hosted means no SaaS lock-in and alerts survive the monitored box dying. |
| Community | Public operator-reliability data (opt-in) gives the community a neutral health view of the node set and a concrete quality signal for oDAO/minipool-economics discussions. |
| RPL holders | Better operator reliability → better protocol performance → healthier RPL-denominated incentives. A funded, maintained public-good monitoring stack reduces operator churn, which protects the network the RPL bond depends on. |
### Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?
The agent’s collectors are Rocket-Pool-aware but its health engine is
client-generic, so solo stakers and DVT operators on the same clients get
value immediately. We expect downstream reuse by Lido CSM operators and
Hoodi/Holesky testnet operators, and the public dashboard schema is useful
to researchers tracking validator-set health. We will say so plainly in the
docs; no other protocol funds this work and none is promised delivery.
## Work
### Who is doing the work?
HostDeFi Validator Collective — an operator collective that runs production
validator infrastructure across multiple networks. The work is executed by
the collective’s engineering operation (Devin-driven, human-supervised);
no individual is being paid by this grant — funds go to the recipient
address listed below to cover build, hosting and maintenance.
### What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
- We operate a multi-network validator fleet: Solana testnet validator
enrolled in the Solana Foundation Delegation Program (TestnetOnboarded,
~315k testSOL activated), an Obol distributed-validator cluster on Hoodi
(32 ETH validator `active_ongoing`, attesting), a NEAR staking pool
registered on-chain (`hostdefi.pool.near`), a Babylon finality provider,
and an approved Canton Validator Operator seat.
- We run public RPC infrastructure across 80+ networks
(`rpc.hostdefi.com`, `chain-rpc.hostdefi.com`) — customer-facing
endpoints, not just our own stake.
- The monitoring system being productized is already in production on our
own fleet: 60 s deep health checks, 3 s fast liveness checks, self-heal
autofixes and direct operator paging — this grant packages proven
internal tooling rather than building from a blank page.
- For Smartnode-specific validation we will stand up a Hoodi Smartnode
minipool during Milestone 1 and run the tool against it for the
remainder of the project.
### What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Award expected ~2026-11-29; dates below are from award.
- **Milestone 1 — core agent + alert server (by 2026-12-19, ~3 weeks).**
Repo public. `rp-pulse-agent` collecting EL/CL/host/RP-contract signals;
`rp-pulse-server` with the 60 s + 3 s check engine, alert-rule set and
Telegram + webhook channels; docker-compose bundle; Hoodi Smartnode
test minipool live under the tool. **$2,500**
- **Milestone 2 — dashboards + full channels (by 2027-01-23, ~5 weeks).**
Operator Reliability Board public (opt-in), Discord + email channels,
upgrade/snapshot notifier live for Smartnode + all major EL/CL clients,
docs site, uninstall/clean-room verified install. **$2,500**
- **Milestone 3 — hardening + handover (by 2027-02-20, ~4 weeks).**
Fault-injection test report (hung-client, dead-host, API-stall
scenarios), signed releases + SBOM, public demo instance against Hoodi,
maintenance plan activated (below), community feedback pass from the
forum/Discord incorporated. **$2,500**
### How is the work being tested? Is testing included in the schedule?
Yes — testing is inside every milestone, not appended:
- Unit + integration tests in CI from M1 (client simulators for each
EL/CL pair; alert-rule golden tests).
- Fault-injection suite in M3 on the Hoodi rig: kill EL, hang CL API
(answers but stops advancing), freeze host, drop peers — with
measured alert latency published in the report.
- Real-operation soak: the tool monitors our own Hoodi Smartnode
minipool continuously from M1; uptime of the tool itself is
self-monitored and published on the dashboard.
### How will the work be maintained after delivery?
12 months of maintenance included in the ask: tracking Smartnode and
client releases (rule/schema updates within 7 days of a breaking client
API change), security patches within 72 h for criticals, issue triage on
the public repo, and a `MAINTENANCE.md` + `handover` doc so the community
can fork cleanly if we ever go dark. The reference public dashboard
deployment stays up for the same period. Renewal to be decided with the
GMC after delivery — by then the codebase stands on its own regardless.
## Costs
### What is the acceptance criteria?
- Repo public since M1, MIT-licensed, tagged releases for each milestone.
- M1: agent + server + compose install works on a clean VM; the Hoodi
minipool is visible in the tool with live metrics.
- M2: opt-in public dashboard shows at least our Hoodi operator entry
live; alerts verifiably arrive on ≥3 channels in fault-injection runs.
- M3: fault-injection report published (all four failure modes detected,
latencies stated); signed releases + SBOM; docs complete enough that a
stranger can install without our help (we verify with a clean-room
install recording).
### What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
**$7,500 total**, milestone-gated: $2,500 on M1 acceptance (~2026-12-19),
$2,500 on M2 (~2027-01-23), $2,500 on M3 (~2027-02-20). Payable in RPL
equivalent at time of payment if the GMC prefers. Roughly 12 weeks of
build + 12 months of included maintenance and hosting for the public
instance.
### Who will directly receive the payment? (Required — the GMC can only send grants directly to a recipient address and cannot accept invoices.)
HostDeFi Validator Collective — fleet operations wallet:
`0x5fD498D85e328D2c245932dfFe7684c351e40930` (EVM, controlled by the
collective; we can sign a verification message on request).
### How will the GMC verify that the work delivered matches the proposed cadence?
- Public repo with commits/issues/tags from day one — progress is
auditable commit-by-commit.
- Each milestone ships a forum reply in this thread linking the release
tag + the live Hoodi demo dashboard URL + the milestone’s evidence
artifacts (fault-injection report, clean-room install recording).
- The public dashboard instance is itself the living proof-of-cadence —
its uptime and coverage are visible to the GMC at any time.
### What alternatives or options have been considered in order to save costs for the proposed project?
- **Extend Smartnode’s own Alertmanager rules** — rejected: on-box
alerting still dies with the box; it cannot close the core failure mode.
- **Point operators at hosted SaaS (NodeBeat-style)** — rejected as a
deliverable: solves the same gap but moves operators onto a paid
dependency; we still encourage operators who want zero ops to use it.
- **Smaller ask / agent only** — considered dropping the public dashboard
to ~$5k, but the dashboard + notifier are where the *public* benefit
(transparency for potential NOs and rETH holders) concentrates; the
marginal cost is small relative to the value.
- The monitoring engine is already built and battle-tested internally —
the grant pays for productization, Smartnode-specific signals, the
public surface, docs and maintenance, not ground-up R&D.
### Have you already been compensated by the RP protocol in any way for this work?
No. No prior GMC grants, bounties, retrospective awards or oDAO
compensation.
## Conflict of Interest
### Does the person or persons proposing the grant have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the grant).
None. No GMC membership or financial relationship with any GMC member.
### Will the recipient of the grant, or any protocol or project in which the recipient has a vested interest (other than Rocket Pool), benefit financially if the grant is successful?
Indirectly and incidentally only: we will run the tool on our own future
Rocket Pool and other-network infrastructure (it is, by design, the same
monitor we use ourselves), and it may modestly improve our own validator
uptime — the same benefit any operator gets from the tool. No other
protocol, token or project of ours receives revenue, referrals or
exclusivity from this grant. The dashboard treats every operator
identically.
-–
m the tool. No other
protocol, token or project of ours receives revenue, referrals or
exclusivity from this grant. The dashboard treats every operator
identically.
-–
廣東話速讀版（書面粵語）