As designed, MEV-Boost-relay records the timestamp of validator's first regitration, and only updates this entry if the gas_limit or fee_recipient is changed. It does NOT update a pre existing entry when a validator re-registers. It's difficult for a relay to determine what proportion of the validator set that has previously registered on a relay remains active, without looking at other methods. It's also possible to have situations where it appears a validator has two active registrations using different gas_limits or fee_recipients on two competing relays. We can't think of a reason why validators would actually do this - it's far more than likely that the validator actually only remains active on one of these relays, and other registration is stale. This kind of scenario also creates a challenge for the builders - who would strongly prefer to only build one set of bids per slot in their latency senstitive builder pipelines. But the variation in gaslimit for a single validator between relays pushes them to build multiple versions of the same bid. To get around this challenge, some builders have started to ask relays to ignore the gas-limit preference of the validator entirely so they can avoid the problem. If relays dropped stale registrations, it would be much clearer for builders which relays they should be using for a given slot. Alternatively, we could consider exposing a validator registration last_updated_time, which would allow the builder to determine this themselves with some confidence, without forcing the relay to drop a registration entirely.