Summary
Recently, a medium-severity vulnerability was identified in Tranchess’s smart contract, specifically within the veChessCrossChain
function of the VotingEscrowV4
contract. This issue allowed attackers to exploit the contract's mechanics, resulting in a griefing attack where despite no profits for the attacker, victims were unable to release their lock on the current chain after cross-chain transactions. We have thoroughly investigated this issue and have implemented measures to ensure the security of our protocol.
Description of the Issue
The vulnerability arose from the combination of two mechanisms in the VotingEscrowV4
contract:
- Resetting Unlock Time: In the
veChessCrossChain
function, if a user'slockedBalance
is reduced to 0, theunlockTime
is reset to 0. This allows the user to lock any amount for any duration on this chain again. - Increasing Lock Amount: The
increaseAmount
function allows any user to increase thelockAmount
for a target user, provided the current lock has not expired. There is no restriction to limit this function only to themsg.sender
.
Attackers could exploit these mechanisms by front-running a user’s transaction in the mempool, executing increaseAmount
to add a minimal amount (e.g., 1 wei) to the user's lockedBalance
just before the user transfers all their locked balance through veChessCrossChain
to another chain. As a result, the user would be left with a minimal lock amount that must wait to be unlocked, preventing the user from initiating a new lock with a shorter duration.
Impact
This vulnerability allowed attackers to prevent victims from releasing their lock on the current chain after cross-chain transactions, effectively restricting the victims’ ability to re-lock their assets for a shorter duration than the current lock. The attack could be executed at a very low cost, posing a griefing risk to protocol users.
Remediation
Upon receiving the ImmuneFi report, our team promptly reviewed the findings and confirmed the existence of the issue. We explored several approaches to address the vulnerability and decided to implement a solution that maintains the existing interface while ensuring the security of the protocol.
We are updating the VotingEscrowV4
contract to include a check that ensures the newAmount
resulting from a cross-chain lock is non-zero. This measure will prevent attackers from exploiting the mechanism to leave users with a minimal lock amount.