Was comparing the balance and price submission paths and noticed an inconsistency.
RocketNetworkBalances.submitBalances checks the submit frequency from getSubmitBalancesFrequency() before allowing an update:
https://github.com/rocket-pool/rocketpool/blob/master/contracts/contract/network/RocketNetworkBalances.sol#L138-L140
But RocketNetworkPrices.submitPrices doesn't check getSubmitPricesFrequency() at all the only guard is the block number comparison:
https://github.com/rocket-pool/rocketpool/blob/master/contracts/contract/network/RocketNetworkPrices.sol#L84-L88
The frequency setting itself exists (network.submit.prices.frequency, defaults to 1 day) and is exposed through the settings interface at RocketDAOProtocolSettingsNetwork.sol:166, it's just never enforced in the submit function. So oracles could push price updates as fast as the consensus threshold allows regardless of what the frequency setting says.
In practice this is mitigated by the oracle consensus requirement (need >=50% of trusted nodes to agree), so it's not something an attacker can exploit unilaterally. But the setting is misleading anyone configuring it expects it to be enforced.
The fix would be adding the same frequency check pattern from _updateBalances into submitPrices before allowing the update to go through.
Was comparing the balance and price submission paths and noticed an inconsistency.
RocketNetworkBalances.submitBalanceschecks the submit frequency fromgetSubmitBalancesFrequency()before allowing an update:https://github.com/rocket-pool/rocketpool/blob/master/contracts/contract/network/RocketNetworkBalances.sol#L138-L140
But
RocketNetworkPrices.submitPricesdoesn't checkgetSubmitPricesFrequency()at all the only guard is the block number comparison:https://github.com/rocket-pool/rocketpool/blob/master/contracts/contract/network/RocketNetworkPrices.sol#L84-L88
The frequency setting itself exists (
network.submit.prices.frequency, defaults to 1 day) and is exposed through the settings interface atRocketDAOProtocolSettingsNetwork.sol:166, it's just never enforced in the submit function. So oracles could push price updates as fast as the consensus threshold allows regardless of what the frequency setting says.In practice this is mitigated by the oracle consensus requirement (need >=50% of trusted nodes to agree), so it's not something an attacker can exploit unilaterally. But the setting is misleading anyone configuring it expects it to be enforced.
The fix would be adding the same frequency check pattern from
_updateBalancesintosubmitPricesbefore allowing the update to go through.