The depositTokens()
function in Bridge.sol includes a useAutoBurn
parameter, suggesting that tokens will be burned on L1 after a successful deposit. However, the contract lacks an actual burning mechanism. Instead, tokens are held in escrow, creating a discrepancy between the implied and actual functionality. This misalignment poses security risks and trust issues, as the contract owner becomes the custodian of all deposited tokens on L1.
The useAutoBurn
parameter in depositTokens()
implies a token burning mechanism that doesn't exist in the contract implementation.
Tokens are stored in an escrow within the contract instead of being burned.
The contract lacks safeguards or mechanisms to ensure tokens are handled as users might expect based on the useAutoBurn
parameter.
There is no clear documentation or user notification about the actual handling of tokens when useAutoBurn
is set to true.
Security Risk: If the contract is compromised, an attacker could potentially access all tokens held in escrow.
Trust Issues: Users may believe their tokens are being burned when they are actually being held by the contract, leading to a loss of trust in the platform.
Misleading Functionality: Users making decisions based on the useAutoBurn
parameter may be operating under false assumptions about the fate of their tokens.
Centralization Concerns: The contract owner becomes a central point of custody for all deposited tokens, contrary to decentralization principles.
Manual review
Implement Burning Mechanism: If token burning is intended, implement a secure burning mechanism that's triggered when useAutoBurn
is true.
Remove Misleading Parameter: If burning is not intended, remove the useAutoBurn
parameter to avoid confusion.
Enhance Transparency: Clearly document the token handling process in the contract and user interface.
Implement Security Measures: Add multi-signature control or time-locked withdrawals for escrowed tokens.
Add Events: Emit detailed events for token deposits, clearly indicating whether tokens are burned or held in escrow.
User Notifications: Implement a mechanism to notify users about the actual status of their tokens post-deposit.
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
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.