Monoscan Validator Metrics

Monoscan provides detailed validator performance metrics on the Validators page. This guide explains how to interpret the statistics and what they mean for validator operators.

Key Metrics

Proposed vs Signed

These are two distinct metrics that measure different aspects of validator participation:

Metric	Definition	Expected Behavior
Proposed	Blocks where this validator was the block proposer	Varies based on voting power
Signed	Blocks where this validator signed the commit	Should be ~100% for active validators

Important distinction:

• Proposed counts only blocks where the validator was selected as the proposer by LythiumBFT consensus
• Signed counts blocks where the validator participated in the commit by signing the block

A validator with 5% voting power should propose approximately 5% of blocks over a large enough window, but should sign nearly 100% of all blocks (unless offline).

Expected vs Actual Proposals

The Expected Proposed column shows how many blocks a validator should statistically propose based on their voting share:

Expected Proposed = round(voting_power_percentage × window_blocks / 100)

Example: A validator with 10% voting power over a 1000-block window:

Expected = round(10.0 × 1000 / 100) = 100 blocks

Proposer Delta (Δ)

The delta shows the difference between actual and expected proposals:

Δ = Proposed - Expected

Delta	Meaning	Color
Positive (+)	Over-proposed (more than expected)	Green
Negative (-)	Under-proposed (fewer than expected)	Yellow
Zero (0)	Exactly as expected	Gray

Note: Small deviations are normal. The proposer selection algorithm includes some randomness.

Signing Rate

The signing percentage shows what fraction of blocks in the window the validator signed:

Sign % = (signed_count / window_blocks) × 100

A healthy active validator should maintain 95%+ signing rate. Validators below this threshold are marked as Degraded.

Window Selection

Monoscan offers three window sizes for metrics calculation:

Window	Blocks	Use Case
200	~6-7 minutes	Quick check, recent activity
1000	~30 minutes	Medium-term performance
5000	~2.5 hours	Long-term convergence

Why Short Windows Show Variance

Block production in LythiumBFT follows a probabilistic model. Short windows can show significant variance from expected values due to:

1. Statistical fluctuation: With 200 blocks, a 5% validator expects only 10 proposals - variance is high
2. Network conditions: Temporary connectivity issues affect both proposals and signatures
3. Timing: Proposals happen sequentially, so recent windows may catch streaks

Recommendation: Use 1000 or 5000 block windows to assess true validator performance.

Validator Status

Status	Description
Active	Bonded and signing normally
Degraded	Active but signing below 95%
Jailed	Slashed and temporarily excluded from consensus
Tombstoned	Permanently excluded (double-sign violation)
Inactive	Unbonded or unbonding

Degraded Status

A validator is marked Degraded when:

• Status is Active (bonded)
• Signing rate is below 95%

Degraded validators are still producing blocks but may be experiencing:

• Network connectivity issues
• High system load
• Configuration problems

API Reference

The validator statistics are available via the API:

GET /api/validators/activity?network=sprintnet&window=200

Response Fields

Field	Type	Description
proposed_count	int	Blocks proposed in window
expected_proposed	int	Expected proposals based on voting share
proposer_delta	int	proposed_count - expected_proposed
signed_count	int	Blocks signed in window
missed_count	int	Blocks missed in window
signer_rate	float	signed_count / window_blocks (0-1)
last_proposed_height	int	Last block proposed
last_signed_height	int	Last block signed

Best Practices for Operators

1. Monitor signing rate: Keep above 95% to avoid degraded status
2. Use longer windows: 1000+ blocks gives more reliable metrics
3. Don't panic over short-term delta: Proposer variance is normal
4. Check last_signed_height: If this is far behind, check node connectivity
5. Compare with peers: Similar-sized validators should have similar metrics

Troubleshooting

Low Signing Rate

If your validator's signing rate drops below 95%:

1. Check node connectivity: curl localhost:26657/net_info
2. Verify peer count: Should have 5+ connected peers
3. Check system resources: CPU, memory, disk I/O
4. Review logs for errors: journalctl -u monod-sprintnet -f

Missing Proposals

If your validator has fewer proposals than expected:

1. This is often normal statistical variance
2. Check over a longer window (5000 blocks)
3. Verify your node is not falling behind on block sync
4. Ensure your validator key is properly configured