Problem

preferHighestValueFor picks the numerically highest value across upstreams for configured methods/fields, gated only by agreementThreshold (how many upstreams must report the same value). It has no check on how far a value sits from the rest of the pack: one upstream returning a wildly larger number (stale cache, corrupted state, bug) can win outright as long as it independently satisfies agreementThreshold — even with agreementThreshold: 1, unconditionally.

Change

Adds an opt-in, per-method preferHighestValueForMaxDeviationPct config. Before picking the highest value among threshold-qualifying candidates, candidates whose primary field deviates from the median of the other qualifying candidates by more than the configured percent are filtered out first.

consensus:
  preferHighestValueFor:
    eth_getTransactionCount: ["result"]
  preferHighestValueForMaxDeviationPct:
    eth_getTransactionCount: 50

• Keyed per-method (same shape as preferHighestValueFor) since natural spread differs by method — a nonce should track tightly across synced nodes, a fee estimate may legitimately vary more.
• Unset (default) is a complete no-op — existing configs behave byte-for-byte identically. Covered by a regression test.
• Median/deviation math uses big.Int/big.Rat, not float64, to avoid precision loss on large values (balances, wei amounts).
• If every qualifying candidate is filtered out, falls through to the existing ErrConsensusDispute path — no new error type.
• Rejections are logged at debug level (method, rejected value, median, configured bound) for observability.
• Validation: a configured deviation percentage requires a corresponding preferHighestValueFor entry for the same method, and rejects negative percentages.

Testing

• New unit tests for the medianBigInt / withinMaxDeviation helpers (consensus/utils_test.go), covering odd/even-count medians, exact/at-bound/just-outside boundaries, nil/zero-median no-op, and large uint64 values.
• Extended the existing preferHighestValueFor integration table (erpc/networks_consensus_test.go) with cases for: outlier rejection, all-within-bound (unaffected), all-candidates-rejected (dispute), and an explicit regression case proving default (unset) behavior is unchanged.
• go build ./... and the full consensus/common packages plus the relevant erpc package tests pass locally.

Scope

This is intentionally the smaller of two approaches considered for guarding preferHighestValueFor against outliers: it keeps the existing design of trusting multiple upstreams' own reported values (rather than collapsing to a single source of truth) and makes no client-facing response-contract change. A distinct "flag without rejecting" mode was considered and dropped — flagging with no enforcement had no forcing use case, and rejection is already observable via the debug log line.