Description
A discrepancy has been identified between the stated intent and the actual implementation of token handling in the GrantSharesBridgeAdapter contract. The verify() method explicitly states that
"This contract is not intended to hold any tokens in between two transactions"
and that the tokens received are
"forwarded immediately."
However, the contract lacks mechanisms to ensure compliance with this policy.
This inconsistency presents several risks to the contract's operation.
• First, although the contract implements an onNEP17Payment mechanism for receiving tokens, there is no robust system to ensure the immediate withdrawal of these funds, creating a discrepancy between the documentation and actual functionality.
• Second, calls to external methods such as bridgeContract.depositNative, bridgeContract.depositGas, and bridgeContract.depositToken could fail for various reasons (errors in the destination contract, banned addresses, etc.), leaving tokens trapped in the contract without a clear recovery mechanism.
The absence of a fallback or emergency recovery system for these scenarios directly contradicts the stated intention of not holding tokens and exposes the project to the risk of permanent loss of funds or attacks that exploit this inconsistency.
Recommendations
• Implement a verification system that ensures all received tokens are effectively resent in the same transaction, aborting the transaction if this condition cannot be met.
• Develop emergency recovery mechanisms that allow the extraction of funds trapped in the contract in the event of resending operations failures, assigning this capability to specific administrative roles.
• Modify the verify() method to include actual validations of the contract state, rejecting transactions that could result in token hoarding, rather than simply returning true without performing any checks.