SoulmateAreReunited event emits wrong information
Summary
soulmate2 in the emitted event is always address(0)
Vulnerability Details
The SoulmateAreReunited event is emitted within the mintSoulmateToken function when the second soulmate is being matched. At this point, soulmate2 has not yet been assigned a value, and thus defaults to address(0). This is a logical error in the contract, as the event should only be emitted after both soulmates have been successfully matched and the token has been minted.
Impact
The SoulmateAreReunited event, as currently emitted within the mintSoulmateToken function, contains incorrect information regarding the second soulmate. Specifically, the soulmate2 parameter is always address(0), which does not accurately represent the actual address of the second soulmate. Consequently, any off-chain applications or services that rely on this event data will operate with incorrect information about the second soulmate, leading to potential errors or misinterpretations in their functionality.
Tools Used
Manual review
Recommendations
Adding below before the event is emitted can solve the issue
Lead Judging Commences
finding-mintSoulmateToken-wrong-emit-soulmate2
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.
Rewards breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.