Trustless uptime monitoring. No single point of failure.
Traditional monitoring relies on a single provider you have to trust. GenLayer replaces trust with cryptographic proof. Every health check is independently verified by multiple validators and stored permanently on-chain.
How It Compares
| Feature | Pingdom / UptimeRobot | GenLayer |
|---|---|---|
| Single point of failure | Yes | No, multiple validators |
| Tamper-proof results | No | Yes, consensus-verified |
| On-chain proof | No | Yes, immutable storage |
| Open source | No | Yes |
| Decentralized checking | No | Yes, geographic distribution |
| SLA disputes | Screenshots | Cryptographic evidence |
What does this monitor?
This system monitors 7 critical infrastructure services across the GenLayer ecosystem: RPC endpoints, block explorers, and the ZKSync bridge. Every hour, a cron job triggers the on-chain UptimeMonitor contract. The contract makes HTTP and JSON-RPC calls to each service, records whether it responded correctly, and stores the result on-chain as an immutable record.
The Consensus Process
How validators reach agreement on each check
Leader Proposes
A randomly selected validator executes the health check by pinging the service via HTTP or JSON-RPC, then proposes the result to the network.
Validators Verify
Other validators independently repeat the exact same check. They compare their result to the leader's using strict equality: the response must match exactly.
Majority Decides
If the majority agrees, the transaction is accepted and the check result is stored on-chain. If not, a new leader is rotated in and the process repeats.
Why strict equality? Health checks are factual: a service is either responding or it isn't. Unlike subjective tasks, there's no room for interpretation. This makes strict_eq the right consensus mode.
Why Trustless Monitoring?
What makes this different
Tamper-proof SLA proof
No single party can fake uptime data. Results are verified by independent validators and stored immutably on-chain.
Transparent & auditable
Anyone can read the smart contract directly and verify every historical check result. No black box.
Decentralized checking
Checks come from multiple geographic locations via independent validators, reducing false positives.
On-chain accountability
SLA violations are provable on-chain, useful for dispute resolution backed by cryptographic evidence.
Architecture
┌─────────────┐ cron ┌──────────────────┐ writeContract ┌─────────────────────┐
│ Vercel │ ────────► │ Next.js API │ ────────────────► │ UptimeMonitor.py │
│ Cron Job │ │ /api/cron/check │ │ (on-chain) │
└─────────────┘ └──────────────────┘ └─────────────────────┘
│ stores CheckResult
│ (after consensus)
▼
┌─────────────┐ reads ┌──────────────────┐ cache sync ┌─────────────────────┐
│ Dashboard │ ◄──────── │ Vercel KV │ ◄──────────────── │ Contract storage │
│ (React) │ │ (off-chain) │ incremental │ (source of truth) │
└─────────────┘ └──────────────────┘ └─────────────────────┘1. Cron trigger: A Vercel cron job calls /api/cron/check every hour, sending a run_checks() transaction to the contract.
2. Consensus: Multiple validators independently check all 7 services and vote on results using strict equality.
3. On-chain storage:Once consensus is reached, each CheckResult is stored in the contract's TreeMap storage.
4. Dashboard reads: The dashboard reads from on-chain state through a KV cache layer.
The Smart Contract
What is GenLayer?
GenLayer is a blockchain that runs Intelligent Contracts, smart contracts that can access the internet, call APIs, and use AI, all verified through decentralized consensus.
This uptime monitor is a real-world example: a decentralized application that reads live data from external services and stores verified results on-chain. Something impossible with traditional smart contracts.