prematurata Poor

What this is. Turboflakes grades each para-validator per era. A para-validator is a validator picked by the relay chain each session to verify parachain blocks - assignment rotates so every active validator takes turns.

The 9 bands (best to worst): A+, A, B+, B, C+, C, D+, D, F. The grade is computed from your vote ratio (75%) and bitfield ratio (25%) - see MVR and BAR tiles for the inputs.

Yours: F - Likely a problem on your node - see possible causes.

Calculated by Turboflakes from on-chain parachain backing data for era 9279.

What this is. When you back a parachain block as a para-validator, you cast one of three votes:

• Explicit - you ran the block yourself and signed off. (0 this era)
• Implicit - you trusted another validator's signed vote. (0 this era)
• Missed - you cast neither. (437 this era - these hurt your grade)

Formula filled with your numbers:

Bands:

• < 5% - excellent
• 5–10% - healthy
• 10–20% - slightly elevated
• > 20% - flagged with ✗ glyph by Turboflakes

Network median this era: 0.0% - yours is significantly above median - likely a node-side problem.

Likely causes (in order of frequency, with diagnostic commands):

1. Node out-of-sync - even a few seconds behind misses votes. Check: curl -s -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"system_health","id":1}' localhost:9933 isSyncing must be false.
2. CPU/disk under-resourced - para-validation runs WASM in ~2s. Check: htop # sustained CPU > 80% on validator process is a red flag iostat -x 1 # await > 20ms on the data disk is bad
3. Slow network to other validators in your group - your "group" is the ~5 para-validators backing the same parachain as you this session. Check libp2p peer count and ping to your peers.
4. Crashes or restarts during the era - parachains produce a block every ~6s, so even brief downtime misses many votes: journalctl -u polkadot-validator --since '6 hours ago' | grep -iE 'panic|restart|killed'

Calculated by Turboflakes from on-chain parachain backing data for era 9279.

What this is. Separately from voting, every validator (not just para-validators) signs a small message each block - called a bitfield - declaring which parachain blocks they currently have the data for. This is how the network knows a parachain block is safe to finalise.

Formula filled with your numbers:

Bands:

• > 99% - healthy
• 95–99% - mild lag, usually transient
• < 95% - node not keeping up with relay-chain block production

Likely causes (relay-chain side, not parachain-side):

1. Relay-chain sync lag - different from parachain sync. Verify the relay-chain client is current: curl -s localhost:9933 -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"chain_getBlock","id":1}' | jq -r '.result.block.header.number'
2. Network partition - you can produce votes but can't gossip bitfields. Verify libp2p listening port is reachable from outside.
3. Clock skew - bitfields are time-bounded; NTP drift can invalidate them: chronyc tracking | grep 'System time' # offset should be < 100ms

Calculated by Turboflakes from relay-chain block data for era 9279.