Core Contracts

Summary

The setBoostParameters function in the BaseGauge contract is designed to update the boost state—specifically, the maximum boost, minimum boost, and boost window parameters—that are used to calculate reward multipliers for gauge participants. However, the function does not emit any event after updating these critical storage variables. Without event emission, off-chain monitoring, logging, and audit trails cannot capture these state changes, which diminishes transparency and makes debugging and tracking governance parameter updates more difficult. This issue does not directly alter on-chain behavior, but it reduces the system's overall observability and can hinder effective monitoring and governance oversight.

Vulnerability Details

Function Overview

The problematic function is defined as follows:

Key Points:

• State Update Without Notification:
  The function correctly updates the boost state storage variables (maxBoost, minBoost, boostWindow) but fails to emit an event indicating that the parameters have been changed.

• Importance of Event Emission:
  Emitting an event is a best practice in smart contract development because events serve as an immutable log that external services, off-chain systems, and auditors rely upon to verify state changes. Without such an event, the update is not easily observable, which can lead to:

  • Reduced transparency

  • Difficulties in debugging and auditing

  • Challenges in tracking parameter changes over time

• Impact on Governance and Monitoring:
  Since boost parameters directly affect reward calculations and governance multipliers, it is critical that any change to these parameters is publicly logged. The lack of event emission could obscure important changes and potentially allow for unnoticed manipulations.

Proof of Concept

Scenario Walkthrough

1. Parameter Update Without Event:
   An authorized controller calls setBoostParameters with new values for the boost state. For example, setting _maxBoost = 2e18, _minBoost = 10000, and _boostWindow = 7 days. The boost state variables are updated on-chain, but no event is emitted.

2. Off-Chain Monitoring Impact:
   Monitoring services or auditors expecting an event (e.g., BoostParametersUpdated) will not capture any log for this update. This results in a gap in the audit trail, making it difficult to verify when and how the boost parameters were changed.

Example Test Case (Pseudocode)

Below is an example (hypothetical) test case using Foundry that demonstrates the absence of an event after calling setBoostParameters:

Note: In the current implementation, no event is emitted, so the test would fail if it expects an event. This demonstrates the vulnerability.

Impact

• Reduced Transparency:
  The absence of an event hampers off-chain monitoring systems from tracking changes to boost parameters, reducing the overall transparency of the protocol.

• Auditability Challenges:
  Without events, auditors and developers have no easy way to verify when boost parameters were updated, which can complicate debugging and historical analysis of protocol behavior.

• Governance Oversight:
  Boost parameters are critical to reward multipliers and governance power distribution. Undocumented changes could lead to misaligned incentives, and any malicious or inadvertent changes may go unnoticed.

• System Integrity Risk:
  Over time, the inability to track key parameter updates can undermine trust in the protocol, as stakeholders may not be confident that governance decisions are based on transparent, auditable data.

Tools Used

• Manual Review

• Foundry

Recommendations

To remediate this issue, the setBoostParameters function should be updated to emit an event after the boost state is updated. This event should include the new values of the boost parameters.

Proposed Diff for setBoostParameters

Define the Event

If not already defined, add an event declaration to the contract: