TempleGold

Summary

In the TempleTeleporter contract's teleport function and TempleGold contract's send function. The current implementation burns tokens on the source chain before ensuring they are minted on the destination chain, potentially leading to permanent loss of user funds if the cross-chain message fails to execute properly.

Vulnerability Details

The teleport function in TempleTeleporter.sol contains a flawed sequence of operations:

The vulnerability arises from the following sequence:

1. Tokens are burned on the source chain.

2. A cross-chain message is sent via LayerZero.

3. There is no mechanism to ensure the successful minting of tokens on the destination chain.

4. If the cross-chain message fails, the burned tokens are irretrievably lost.

The _lzSend function does not provide guarantees of message delivery or execution on the destination chain. It only ensures that the message has been accepted by the local LayerZero endpoint.

Impact

The impact of this vulnerability is severe:

1. Users can permanently lose their tokens if the cross-chain message fails to execute properly on the destination chain.

2. There is no recovery mechanism for users in case of failed transfers.

3. This vulnerability undermines trust in the protocol and could lead to significant financial losses for users.

4. The issue could be exploited by malicious actors to intentionally cause token loss by manipulating network conditions or gas prices on the destination chain.

Given the potential for direct and irreversible loss of user funds, this vulnerability should be classified as HIGH.

Tools Used

This vulnerability was identified through manual code review and analysis of the cross-chain token transfer mechanism. No specific automated tools were required to identify this issue.

Recommendations

We recommend following the ABA chain patterns from layer zero, ABA pattern:

1. Implement a lock-and-mint pattern instead of the current burn-and-mint approach:

   function teleport(uint32 dstEid, address to, uint256 amount, bytes calldata options) external payable {

   // Lock tokens instead of burning

   temple.transferFrom(msg.sender, address(this), amount);

   // Send cross-chain message

   bytes memory payload = abi.encode(msg.sender, to, amount);

   _lzSend(dstEid, payload, options, MessagingFee(msg.value, 0), payable(msg.sender));

   emit TokensLocked(msg.sender, amount, dstEid);

   }

2. Implement a confirmation mechanism on the destination chain:

   function _lzReceive(

   Origin calldata _origin,

   bytes32 _guid,

   bytes calldata _payload,

   address _executor,

   bytes calldata _extraData

   ) internal override {

   (address from, address to, uint256 amount) = abi.decode(_payload, (address, address, uint256));

   temple.mint(to, amount);

   // Send confirmation back to source chain

   _lzSend(_origin.srcEid, abi.encode(_guid, true), "", MessagingFee(0, 0), payable(address(this)));

   }

3. Add a function to finalize the transfer on the source chain:

   function finalizeTransfer(bytes32 _guid) external {

   require(confirmedTransfers[_guid], "Transfer not confirmed");

   address from = pendingTransfers[_guid].from;

   uint256 amount = pendingTransfers[_guid].amount;

   temple.burn(address(this), amount);

   delete pendingTransfers[_guid];

   emit TransferFinalized(_guid, from, amount);

   }

   The last function need extra implementation to handle the confirmation mechanism (e.g., confirmedTransfers mapping).

4. Implement a timeout mechanism allowing users to reclaim locked tokens if the transfer doesn't complete within a specified timeframe.

5. Add comprehensive event emissions and status tracking for all stages of the cross-chain transfer process.

By implementing these recommendations, the protocol can significantly reduce the risk of permanent token loss and provide a more robust and trustworthy cross-chain transfer mechanism.