NFTBridge
60,000 USDC
View results
Submission Details
Severity: low
Invalid

Misleading 'useAutoBurn' Parameter in depositTokens() Function Without Actual Burning Mechanism

Summary

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.

Vulnerability Details

  1. The useAutoBurn parameter in depositTokens() implies a token burning mechanism that doesn't exist in the contract implementation.

  2. Tokens are stored in an escrow within the contract instead of being burned.

  3. The contract lacks safeguards or mechanisms to ensure tokens are handled as users might expect based on the useAutoBurn parameter.

  4. There is no clear documentation or user notification about the actual handling of tokens when useAutoBurn is set to true.

Impact

  1. Security Risk: If the contract is compromised, an attacker could potentially access all tokens held in escrow.

  2. 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.

  3. Misleading Functionality: Users making decisions based on the useAutoBurn parameter may be operating under false assumptions about the fate of their tokens.

  4. Centralization Concerns: The contract owner becomes a central point of custody for all deposited tokens, contrary to decentralization principles.

Tools Used

Manual review

Recommendations

  1. Implement Burning Mechanism: If token burning is intended, implement a secure burning mechanism that's triggered when useAutoBurn is true.

  2. Remove Misleading Parameter: If burning is not intended, remove the useAutoBurn parameter to avoid confusion.

  3. Enhance Transparency: Clearly document the token handling process in the contract and user interface.

  4. Implement Security Measures: Add multi-signature control or time-locked withdrawals for escrowed tokens.

  5. Add Events: Emit detailed events for token deposits, clearly indicating whether tokens are burned or held in escrow.

  6. User Notifications: Implement a mechanism to notify users about the actual status of their tokens post-deposit.

Updates

Lead Judging Commences

n0kto Lead Judge 12 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational / Gas

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.