Open hats-bug-reporter[bot] opened 1 month ago
Thank you for your report on the data type mismatch for the expiry parameter in the _trust function event emission. After review, we've determined this is not an issue.
The use of uint256 in the event emission, despite storing expiry time as uint96, is intentional. This approach doesn't increase gas costs, as event logs use a fixed-gas-cost (of 375 gas - if I'm not wrong) per topic of fixed 256 bits each (irrespective of the ABI definition).
We appreciate your attention to data type consistency in our contract. Thank you for your contribution to this security review.
Github username: -- Twitter username: -- Submission hash (on-chain): 0x2050c4cfefe8a4b50024a9c6509b99d632fee769ea8c6962b828e0121133730f Severity: low
Description: Description\ During the analysis of the
_trust
function within theHub
contract, I found a discrepancy between the data type of the_expiry
parameter used in the function and theexpiryTime
parameter emitted in the corresponding Trust event._expiry
, is defined asuint96
.expiryTime
, is defined asuint256
.This discrepancy occurs when the event is emitted:
Here, the
uint96
value_expiry
is implicitly cast touint256
for the event, which could result in inconsistencies between the data stored in the contract and the data logged in the event.Impact\ The
uint96
value will be expanded into auint256
during event emission, with the upper 160 bits filled with zeros. While this won't necessarily cause an immediate failure, it introduces a risk of inaccurate event logs, which could cause confusion for users or developers relying on off-chain event data.Recommendation\ Change the event parameter from
uint256
touint96
can resolve the type mismatch without altering the function's logic.