Lido CSM Dashboard

Projects
1

Hey everyone :waving_hand:

I’ve been running a CSM node for a while now, and like many of you, I found myself constantly wanting to check on my rewards, bond status, and validator performance without having to piece together information from multiple sources.

Lido CSM Dashboard is a simple monitoring tool that pulls together all the data I care about as a node operator into one place. It started as a quick CLI script I threw together for myself, but it grew into something I thought others might find useful too.

What it does

  • Shows your current bond vs. required bond (and any excess you can claim)

  • Tracks unclaimed rewards and total claimable ETH

  • Displays validator counts (active, pending, exited)

  • Calculates your actual APY (both from CSM rewards and stETH rebasing)

  • Works with either your wallet address or operator ID

Two ways to use it

CLI - If you’re comfortable in a terminal, you can run quick checks or set up continuous monitoring:

csm check 0xYourAddress --detailed
csm watch 0xYourAddress

csm-dash-cli
csm-dash-cli1920×1292 195 KB

Web Dashboard - If you prefer a browser, spin up the local server and get a nice visual interface:

csm serve

csm-dash-web
csm-dash-web1892×2554 349 KB

API Endpoints

  • GET /api/operator/{address_or_id} - Get operator rewards data

  • GET /api/operators - List all operators with rewards

  • GET /api/health - Health checkWhy I made this

Honestly, I just got tired of:

  • Checking the Lido CSM UI, then cross-referencing with beaconcha.in

  • Manually calculating whether my bond was sufficient to restake

  • Not having a quick way to see my unclaimed rewards

This pulls data from the CSM contracts, the rewards merkle tree, beaconcha.in, and the Lido API - all in one place.

Getting started

It’s a Python CLI tool. If you’ve got Python installed:

git clone https://github.com/0xdespot/lido-csm-dashboard.git
cd lido-csm-dashboard
pip install -e .
cp .env.example .env
csm check YOUR_ADDRESS

You’ll need an Ethereum RPC endpoint (defaults to publicnode, but you can use your own). A beaconcha.in API key is optional but helps with rate limits if you’re checking frequently.

GitHub: https://github.com/0xdespot/lido-csm-dashboard

Nothing fancy - just trying to make life a little easier for fellow CSM operators.

Cheers!

-0xD

17 Likes
2

This dashboard looks genuinely useful, especially for CSM operators who want a single place to sanity-check bond status, rewards, and overall performance without hopping between multiple tools.

I particularly like that it surfaces unclaimed rewards and effective APY — those are things that are easy to overlook in day-to-day ops but matter a lot over time.

Quick question: how resilient is the data sourcing at the moment? Are there fallback mechanisms if a primary RPC or beacon API becomes unreliable, or is that something planned for later iterations?

Overall, this feels like a strong step toward reducing operational overhead for smaller or solo CSM participants. :clap:

3

Good points!

RPC - I have some resilience built in (RPC falls back to sequential if batching fails) but I do not have full RPC failover. This is probably fine for most users who casually run from the cli but you are right, for folks using the --json flag and parsing STDOUT, or using the REST endpoint, then a failing RPC node would be problematic. RPC failover is pretty easy to implement so i’ll put it on the list.

Beaconchain - There’s “graceful” degradation on errors. When validators fail to respont their status is assigned UNKNOWN status and we continue on with partial data rather than failing completely.

4

This is really cool! Nice work.

1 Like
5

One of our community members, cnupy, just added docker support. Very slick!

6

I had been considering building a similar project myself, but it’s great to see that such a well-designed and thoughtfully executed solution already exists.
This is genuinely impressive work — well done, and thank you for sharing it with the community.

One additional question: if Community Staking Module (CSM) penalties are applied in the future, are there any plans to surface that information as well? Having visibility into CSM penalty events and their context would be extremely valuable for operators and the broader community.

7

Wait, you want to track more than number-go-up!?! :wink:

Good points though. Maybe a CSM Health summary? Any particular priority?

Digging into the CSStrikes contract… looks like strikes are stored off-chain… Lemme see what I can come up with.

8

Maybe something like this?

Screenshot 2025-12-18 at 14.08.00
Screenshot 2025-12-18 at 14.08.001836×1658 250 KB

Screenshot 2025-12-18 at 14.10.59
Screenshot 2025-12-18 at 14.10.592784×1456 484 KB

2 Likes
9

Cool, added some health checks to look for the usual suspects, slashing, strikes, etc. Also added a new endpoint.

csm health --id 328

You can now install with pip:

pip install csm-dashboard

or docker:

docker pull 0xdespot/lido-csm-dashboard:0.2.2

2 Likes
10

This looks absolutely fantastic — thank you for putting this together.

I really appreciate how thoughtfully this is designed. Surfacing CSM health signals in this way makes the system much easier to reason about, especially for operators who care about more than just rewards.

The idea of a CSM health / strikes view is particularly valuable, and the mockups already feel very intuitive. This kind of visibility would be a huge win for both operators and the broader community.

Great work, and I’m excited to see where this goes.

11

Lots of changes in 0.3.2

Screenshot 2025-12-23 at 16.40.18
Screenshot 2025-12-23 at 16.40.181568×1420 301 KB

Added:

  • Reward History (-H)
  • Withdrawal History (-w)
  • Estimated next reward date & amt.
  • Historical APYs
  • Operator Types and operator type variables (bond/strikes,etc).
  • Lots of under the hood cleanup to make data aggregation/inspection easier

Thanks to @pjhnocegood and @crymo99 for some great suggestions and testing.

12

Rolled out a couple requested additions:

Added more detail to withdrawal history

Added Distribution History and Withdrawal History to web view

Screenshot 2026-01-05 at 12.17.29
Screenshot 2026-01-05 at 12.17.291850×1692 290 KB

Added Unraid docker template

4 Likes
13

This is excellent work!!

As someone who constantly finds themselves context-switching between the Lido UI and beaconcha.in just to check bond status, this is exactly the “single pane of glass” solution I was looking for.

I particularly appreciate that you included the API endpoints (/api/operator) and the CLI option alongside the web dashboard. It makes it much easier to integrate these metrics into my existing monitoring setup without having to scrape multiple frontend sources myself.

Going to spin this up on my local server tonight. Thanks for sharing!

14

Hi, this looks really intersesting/usefull!

Does this need to be run on a node directly, or can you just run the container on any computer when you would like to see how your node is doing?

15

Hey @JohnSilverSnow
You can run the dashboard on any machine. No dependency on your node, or any node, for that matter.

1 Like
16

Nice, Wil definitly try it!

If I’ll encounter some dificulties/issues with it, should I just use this post for assistance, because I feel semi-capable in making it work?

17

Sure thing you can ping me here or on discord @0xdespot

Of course, it’s always nice to have the journey documented for others that might run into similar issues :slight_smile:

1 Like
18

awesome work and thanks so much. I hope the same idea but for telegram bot will be implemented soon :smiley: . It is even easier to monitor I think!

19

This is fantastic and super helpful!

1 Like
20

Oh just discover this bot have implemented, play around with it today with @CSMSentinel_bot telegram