The initVault function in the LoveToken contract emits both the AirdropInitialized and StakingInitialized events with incorrect data. The event data indicates that the parameters passed should be airdropContract and stakingContract, respectively. Still, the function emits both events with the parameter managerContract, resulting in inaccurate event logs.
Both the AirdropInitialized and StakingInitialized events are expected to log the addresses of the corresponding contracts (airdropContract and stakingContract). However, the initVault function incorrectly emits both events with the parameter managerContract, leading to a discrepancy between the event's data and the actual initialized contracts.
The incorrect event data poses a challenge for developers and external systems relying on event logs, as the information provided does not accurately reflect the initialized contracts. This discrepancy may result in confusion and hinder proper tracking of contract initialization events.
Manual review.
Correct Event Data: Update the initVault function to emit both the AirdropInitialized and StakingInitialized events with the correct parameters, reflecting the addresses of the corresponding contracts (airdropContract and stakingContract).
Low severity, inconsistencies in event emission Sidenote: Separating all event findings given root causes are different with different functions involved. There could be alot of debate on whether wrong emit events consitute low severity, but I believe, - There are direct inconsistencies in the code logic - Codehawks [low severity categorization guidelines](https://docs.codehawks.com/hawks-auditors/how-to-evaluate-a-finding-severity#low-severity-findings) supports its severity as seen below, especially noting the term `Minimal to no impact` > - Minimal to no impact on the funds or the protocol's main functionality.
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.