|PURPLEIRIS

Hermes Methodology

How Hermes sources
and classifies data

Hermes is a Monad validator intelligence assistant. Every factual claim it returns carries a data-class label so you can immediately judge its reliability — whether it came directly from the chain, was computed by a stated formula, or involves an approximation with explicit caveats.

Hermes is non-advisory: it surfaces data and analysis, never tells you what to do. Two modes:

Delegator

Conversational discovery + comparison

Operator

Diagnostics + earnings

Data-class system

Three classes, always labeled

Every number in a Hermes response is tagged inline. You always know the epistemic status of what you're reading before you act on it.

Class 1

On-chain

Read directly from the Monad staking precompile or chain state. Deterministic — no formula applied.

Class 2

Derived

Computed from on-chain inputs via a versioned, stated formula. Reproducible given the same inputs.

Class 3

Estimated

Projections involving approximations. Always paired with a low/base/high range and a known-weakness statement.

Class 1

On-chain (deterministic)

Read directly from Monad or the staking precompile. No formula applied. Results are deterministic — anyone querying the same block gets the same answer.

  • ·Stake amounts — total delegated MON per validator
  • ·Commission rate — in basis points (e.g. 500 = 5%)
  • ·Jail status and active / inactive status
  • ·Block counts — proposed and missed, per epoch
  • ·Delegator count and voting power
  • ·Pending unclaimed commission — live balance, resets on claim
  • ·Cumulative staking rewards — indexed from on-chain proposer-reward events
  • ·Execution revenue — per-block transaction fee income, indexed on-chain

Staking rewards — two layers

Layer 1 — live pending commission. Read from getValidator() on the Monad staking precompile:

0x0000000000000000000000000000000000001000

Returns unclaimedRewards — the live pending balance, resets to zero when the validator claims.

Layer 2 — cumulative history. Indexed from per-block proposer-reward events (topic 0x3a420a01), aggregated daily. Commission earned per block = gross block reward × the validator's commission rate.

Execution revenue

Per-block transaction / priority fee income. Indexed on-chain and reported over 7-day and 24-hour windows with a daily breakdown, trend direction (up / flat / down), and rank versus the network median.

Class 2

Derived (formula-labeled)

Computed from on-chain inputs using stated formulas. Each formula carries a version label so results are reproducible and changes are traceable.

Shannon entropy — stake and diversification

Used to score delegation spread across validators, geographic regions, and infrastructure providers. Applied in diversification simulations.

H = −Σ pᵢ · log₂(pᵢ)

pi = stake share of each validator / region / infra bucket. Normalized 0–1 against the theoretical maximum (uniform distribution). Labeled formula v1.0.

Nakamoto coefficient

Minimum number of validators that together control more than 33% of total stake — the standard fault-tolerance threshold. Computed from live stake distribution on every query. Labeled nakamoto_coefficient v1.0.

30-day success rate

Block success rate over a rolling 30-day window, with epochs flagged as scheduled downtime excluded from the denominator:

success_rate = blocks_proposed / (blocks_proposed + blocks_missed)

Requires approximately 30 days of accumulated epoch snapshots to be fully populated. When the indexer window is shorter, Hermes flags the metric as partial rather than returning an incomplete average silently.

Validator health score

A composite per-validator signal (0–100) surfaced in get_validator output. Inputs: current-epoch success rate (heaviest weight), 30-day rolling success rate, VDP flagged weeks, consecutive block streak, and live node status (offline / jailed). Commission rate is not an input. The resulting band (Excellent / Good / Watch / At Risk / Critical) is capped so it never contradicts node status — an offline or jailed node cannot show Excellent or Good.

Class 3

Estimated (uncertainty-aware)

Projections and approximations. Always includes a low / base / high range and an explicit known-weakness statement. Not financial advice.

Projected APY

A three-point range (low / base / high) computed from:

APY ≈ network_reward_rate × (1 − commission_rate) × ±variance

Known weakness: the network reward rate is approximated, not read directly from chain. Actual rewards vary with total network participation and validator commission changes.

Reward simulations

Estimated MON earned for a given stake amount, duration in days, and validator commission rate. Monthly extrapolations are derived from a 7-day rolling average. Always labeled Class 3 with the known weakness cited.

Region and infrastructure provider

Region and infrastructure provider fields are self-reported by validators in the Monad community registry (github.com/monad-developers/validator-info). Hermes does not infer location from IP addresses or ASN data. Values reflect what each operator has declared in the registry — unverified and Class 3.

Tool reference

What PurpleIris can actually do

14 tools total. Delegator mode has 10; Operator mode extends that with 4 diagnostics and earnings tools.

Delegator — 10 tools

get_validatorFull validator profile: commission, stake, jail status, 7d/30d block metrics, health score
list_validatorsFilterable validator list — commission cap, min stake, region, infra provider, active-only, limit
find_underdogsHigh success-rate / low-stake-rank validators; ranked by 30-day average success rate
simulate_delegationClass 3 APY range + estimated MON reward for N MON staked with a validator over N days
simulate_diversificationClass 2 Shannon entropy scores for a proposed multi-validator stake split
estimate_stake_rewardQuick reward estimate from commission rate, stake amount, and duration — no DB query
get_recent_assignmentsEpoch-level block history for a validator — blocks proposed, blocks missed, and success rate per epoch, newest first
get_network_healthActive validator count, total stake, Nakamoto coefficient, network-wide success rate
get_network_overviewEpoch, Watchtower uptime, 30d aggregates, alert distribution, top validators by uptime
get_latest_monad_releaseLatest Monad protocol release tag, date, and summary — synced from GitHub

Operator adds — 4 tools

get_staking_rewardsPending unclaimed commission + cumulative 7d/24h staking commission history (Class 1)
get_execution_revenue7d + 24h block priority fee income; daily breakdown, trend, rank vs network median (Class 1)
get_assignment_predictorExpected vs actual round assignment frequency based on stake ratio; flags below / above expected
get_anomaly_checkScans a look-back window for operational anomalies: timeout clusters, rate drops, streak breaks, extended offline periods

Data pipeline

Honesty about data windows

Hermes indexes Monad mainnet continuously into a relational database. Time-windowed metrics — 7-day staking history, 30-day success rate — fill in as the indexer accumulates data. When a window is not yet fully populated, Hermes says so rather than returning an incomplete value silently or fabricating completeness.

All data that Hermes returns is read-only. It observes chain state; it does not submit transactions, hold keys, or take any on-chain action.

Spotted incorrect data or unexpected behaviour? Submit feedback →