-
The dashboard.
Inspiration
The idea for NCV came from observing a critical gap in blockchain infrastructure monitoring. I was researching validator slashing incident when I noticed a disturbing pattern: nodes were being penalized not because they crashed, but because they were serving stale or incorrect data while appearing healthy to traditional monitors.
This is what I call the silent failure problem, it is when a node responds to pings, shows normal CPU and memory usage, and passes basic health checks, but is actually stuck on an old block or serving corrupted state. For validators, this means slashing penalties. For dApps, this means serving bad data to users. For infrastructure providers, this means undetected degradation that compounds over time.
I wanted to build something that could actively challenge nodes to prove they're not just online, but correct, fresh, and trustworthy.
What it does
NCV (Node Correctness Verification) is an active verification system that goes beyond passive monitoring. Instead of just checking if a node is up, NCV sends targeted challenges to verify:
Head Correctness: Does the node's state_root match the network consensus at a specific block height?
Execution Correctness: When simulating a transaction, does the node compute the exact same fees and weights as trusted references?
Freshness: Is the node receiving new blocks on time, or is it silently stalled? Every verification cycle generates a JSON evidence bundle, which is a cryptographic proof of either correctness or failure that can be used for debugging, alerting, or slashing evidence. The system includes:
Challenger Service: Runs continuous verification cycles against nodes Saboteur Proxy: A testing tool that simulates silent failures (dormant nodes, corrupted state)
How we built it
I built NCV as a solo project, working through significant infrastructure challenges in Nigeria where power outages and limited internet connectivity are daily realities.
Architecture:
Backend: Python with the Substrate Interface library for Polkadot RPC interactions Proof System: Modular design with a base ProofResult class that standardizes evidence across all verification types Saboteur: HTTP proxy server that intercepts RPC calls and injects failures for testing Frontend: React dashboard with glassmorphism effects, real-time log streaming, and human-readable timestamp formatting Log Server: Python Flask server serving verification results to the frontend Development Process: I started with the core verification logic, implementing head correctness checks first. Then I built the saboteur to simulate failures, this was crucial for testing without needing actual failing nodes. The execution correctness and freshness proofs came next, each as a separate module.
The frontend was redesigned multiple times to achieve the premium dark theme and other features you see now. I implemented glassmorphism effects, subtle animations, and improved the timestamp format from Unix epochs to readable "18 Jan, 17:37:17" format.
Every component was built incrementally, tested in isolation, then integrated. This approach was necessary given my intermittent power and internet access.
Challenges we ran into
Technical Challenges:
State Persistence in the Saboteur: The proxy needed to "freeze" at a specific block to simulate a dormant node. My initial implementation used instance variables, but Python's HTTP server creates a new instance per request. After hours of debugging (between power outages), I realized I needed class-level variables for state persistence. Reliable Staleness Detection: The dormant node simulation wasn't falling behind fast enough for the freshness check to catch it. I solved this by having the saboteur return a header artificially set 30 blocks behind, guaranteeing detection regardless of network timing. RPC Timeouts: Public Polkadot RPC endpoints would timeout due to network instability on my end. I added retry logic, increased timeouts, and implemented graceful degradation.
Infrastructure Challenges:
Building this in Nigeria meant working around constant power outages. I will write code during the few hours of electricity, test during mobile hotspot sessions (carefully managing data costs), and debug by reviewing logs offline when the power went out.
Data subscription costs meant every npm install, every test run, and every API call had to be intentional. No wasteful requests. No unnecessary downloads. This constraint actually made me a better developer, every line of code had to count.
What might take someone a few hours to implement would stretch across days as I worked in fragments between power cycles. The frontend redesign alone took multiple sessions, each one a race against the next blackout.
Accomplishments that we're proud of
Successful Silent Failure Detection: The demo proves NCV can catch both dormant nodes (40 blocks behind) and data corruption (forged state roots), failures that traditional monitoring completely misses.
Clean, Modular Architecture: The proof system is designed for extensibility. Adding new verification types is as simple as creating a new proof class. Evidence Based Verification: Every failure generates a structured JSON proof that's both human readable and machine verifiable.
UI/UX: The dashboard doesn't look like a hackathon project, it looks like production infrastructure software with glassmorphism, smooth animations, and thoughtful design.
Built Under Adversity: This project represents not just code, but persistence. It's proof that great infrastructure can be built anywhere, even when the infrastructure around you is unreliable.
What we learned
Technical Skills: Deep understanding of Polkadot's RPC API, state roots, and consensus mechanisms Building resilient systems that handle network failures gracefully The importance of class-level vs instance-level state in stateful HTTP servers React state management and real-time data visualization Designing proof systems that balance human readability with machine verifiability Problem-Solving:
How to simulate realistic failure scenarios for testing infrastructure software Breaking large problems into small, testable chunks that can be built incrementally The value of offline planning when you can't always be online Resilience:
How to maintain focus and momentum despite infrastructure challenges Working in fragments while preserving architectural coherence The discipline of intentional development when resources are constrained
What's next for NODE CORRECTNESS VERIFICATION (NCV) Sentinel
NCV is just the beginning. The modular architecture is designed for expansion:
Short-term:
Multi-chain Support: Extend beyond Polkadot to Ethereum, Solana, Cosmos, and other chains Advanced Proofs: Runtime verification (WASM version checks), trustless storage proofs, Byzantine behavior detection Alert System: Webhook integrations for Slack, Discord, PagerDuty when failures are detected
Medium-term:
Distributed Verification: Multiple challenger nodes running verification in parallel for redundancy Historical Analysis: Track node health over time, identify degradation patterns Custom Proof Plugins: Allow operators to define custom verification logic for their specific use cases
Long-term:
Decentralized Verification Network: Enable light clients and community nodes to participate in verification, creating a trustless monitoring layer Automated Remediation: A "Healer" module that can automatically restart degraded nodes, switch traffic to healthy replicas, or trigger failover procedures Slashing Integration: Direct integration with validator slashing mechanisms, providing cryptographic evidence for on-chain penalties
The Vision:
NCV should become the standard for blockchain node health verification, a layer of active, cryptographic assurance that sits between passive monitoring and blind trust. Every validator, every infrastructure provider, every dApp should be able to prove their nodes are correct, not just online.
Built solo and debugged in fragments.
Log in or sign up for Devpost to join the conversation.