As per OpenZeppelin's Smart Contract Guidelines, all critical state-changing operations should emit events. This enables external consumers, such as dApps or monitoring services, to track the contract’s state and activity. However, in the current implementation, no events are emitted during critical state-modifying operations within the addRoute
function. The absence of these events can lead to difficulties in monitoring state changes, affecting transparency and potentially complicating contract management.
This function alters multiple contract states:
The routes
mapping
The swapParams
mapping
The pools
mapping
The incrementing of nRoutes
However, no event is emitted to record these important changes.
To improve transparency and comply with OpenZeppelin guidelines, we recommend emitting an event upon successfully adding a new route. This would allow external services to capture when a new route is added and track the associated parameters. Below is the suggested change:
Transparency: External systems can track route changes and associated parameters.
Auditability: Events provide a clear historical record of changes to the contract state.
Security: Event emissions serve as an important tool in post-deployment monitoring, ensuring that the contract behaves as expected.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.