Skip to main content

settlement_compatibility

Function settlement_compatibility 

Source
pub const fn settlement_compatibility(
    client_version: u32,
) -> SettlementCompatibility
Expand description

Can a storer on this build safely quote a client settling under client_version?

Unversioned clients never reach this: they send the legacy request variants and are handled by policy in the storer, not here.

§Why both ends are bounded

An earlier revision accepted everything at or above MIN_SUPPORTED_SETTLEMENT_VERSION, on the reasoning that a storer verifies whatever payment actually arrives so letting a newer client through weakens nothing. That is only true when a settlement change raises what is paid: ADR-0008’s 3x cleared an old node’s 1x minimum, so old nodes accepted new clients for free. It is not true in general. A change that redefines the median rule, or which field the contract pays from, produces a payment an older verifier rejects, and by then the client has already settled on-chain and cannot be refunded. That is the exact failure this mechanism exists to prevent, so an unknown-newer version is refused rather than assumed compatible.

The two refusals are kept apart because they need opposite handling. SettlementCompatibility::ClientTooOld is terminal and the user must upgrade. SettlementCompatibility::NodeTooOld says nothing about the client, which should simply use a different storer. Collapsing them would either tell up-to-date users to upgrade, or strand new clients whenever the node fleet lags, which is the normal state during a client-first rollout.