Function effective_surb_reserve 

fn effective_surb_reserve(configured: u64, announced_target: u64) -> u64

The SURB reserve one Session’s fill actually respects.

PixFillConfig::min_surb_reserve is a ceiling rather than the value used, and it has to be, because the two sides of the comparison are chosen by different nodes. The reserve is measured against the Exit’s estimate of its own SURB buffer for the Session, and how deep that buffer is is the Entry’s decision — it announces its balancer target in the lower 32 bits of the options word in StartInitiation::additional_data. An operator sizing the reserve against a production buffer therefore also decides, unintentionally, that every Session whose Entry asks for a shallower one can never be filled at all: the estimate never reaches the reserve, every fill packet is withheld, and the funded cycle strands on max_recovery_time while the logs report only a backoff.

A quarter of the announced target is what the reserve is for expressed as a proportion: it leaves fill three quarters of whatever buffer the Entry chose and keeps the last quarter for the application, which is the side that has something waiting on it. The configured value still binds wherever it is the smaller of the two — at the shipped 500 against the worked profile’s 7 000-SURB target, a quarter is 1 750, so the derivation is inert on a production-sized Session and only engages on one whose Entry asked for less than four times the configured reserve.

Floored at one, for the same reason the constructor clamps: a zero reserve is fill spending the Session’s last SURB, and an Entry announcing a three-SURB buffer would otherwise produce exactly that.