Backrun bounder incorrectly assumes Arbitrum's block time

[bsamuels453]

Severity: Undetermined
Difficulty: Medium

Overlay uses the underlying chain's average block time as a risk parameter in the protocol's backrun protection, as seen below:

v1-core/contracts/libraries/Risk.sol

Lines 18 to 21 in 40e416c

	MinCollateral, // minimum ov collateral to open position
	PriceDriftUpperLimit, // upper limit for feed price changes since last update
	AverageBlockTime // average block time of the respective chain

v1-core/contracts/OverlayV1Market.sol

Lines 641 to 648 in 40e416c

	/// @dev bid price given oracle data and recent volume
	function bid(Oracle.Data memory data, uint256 volume) public view returns (uint256 bid_) {
	bid_ = Math.min(data.priceOverMicroWindow, data.priceOverMacroWindow);
	// add static spread (delta) and market impact (lmbda * volume)
	uint256 delta = params.get(Risk.Parameters.Delta);
	uint256 lmbda = params.get(Risk.Parameters.Lmbda);
	uint256 pow = delta + lmbda.mulUp(volume);

However, Arbitrum does not have any specified block time, and sequences transactions as they are received by the sequencer. Over time, an average block time can be measured, however this value can be manipulated by an attacker to increase the average block time or reduce it.

This would allow the attacker to bypass the backrun-protection macro window, causing an undetermined impact.

Recommendation

For networks with non-deterministic block times, consider using the block timestamp for measuring the size of the macro window.

[TomasCImach]

As highlighted here, the inverse relationship between the averageBlockTime parameter and the backRunBound cap implies that a higher averageBlockTime leads to a lower backRunBound cap.

Saying that, we should choose the highest avg block time of the current Network deployed with a certain confidence level.

In the context of the exploit scenario targeted by the backRunBound function, potential attackers may execute multiple transactions during the loger TWAP window. Should the average block time of Arbitrum decrease due to heightened transaction demand from malicious actors, maintaining the existing averageBlockTime parameter becomes advantageous for bolstering the security of the protocol.

PR #181 adds a new role named RISK_MANAGER that is able to change any Risk Parameter. This introduces the potential for an automated or semi-automated method to adjust the risk parameters.