TempleGold

TempleDAO
Foundry
25,000 USDC
View results
Submission Details
Severity: high
Valid

Using smart contract accounts and wallets with TempleGold can lead to loss of funds when executing cross-chain transfer to self via the TempleGold::send meto

Summary

Relevant link here

Funds sent across chains via TempleGold::send might be lost if the initiator of the send is a smart contract and potentially smart contract wallet.

Vulnerability Details

`TempleGold::send` expects that, funds can only be sent cross-chain to the same address as the message sender. In other words, I can bridge the funds to another chain as long as I'm bridging the funds to myself. This works just fine for EOA accounts but breaks for smart contract ( accounts ) that are created using the `create` keyword, as was the case for all contracts created before the Ethereum Byzantium hard fork. Nonetheless, there are still smart contracts created in 2024 with the create method and they defacto are not usable with TempleGold lest we send the funds to an address cross chain where they are lost. This issue can be made worst if the nonce of the EOA that was used to create the smart contract account on the origin chain is already used up in the destination chain for the creation of a completely different smart contract that was destined to be used for something else and not TempleGold.

One might want to think that, making TempleGold incompatible with smart contract accounts is done by design but if that's the case, it should have been mentioned in the docs or the repo's README.md, but nowhere is it mentioned that, TempleGold isn't intended to be used with smart contract accounts and by default anyone would expect an ERC20 to be compatible with smart contract accounts and it is explicitly mentioned that, TempleGold is an ERC20.

Impact

TempleGold is not compatible with Smart contracts created using the createkeyword and we run the risk of loosing funds if we try a cross-chain transfer using one such account.

Tools Used

manual observation

Recommendations

Given that the protocol wants to prevent transferring the tokens to a different address other than message sender's, the protocol should clearly document how the protocol is expected to work with smart contract accounts that are created using the createopcode.

Updates

Lead Judging Commences

inallhonesty Lead Judge 11 months ago
Submission Judgement Published
Validated
Assigned finding tags:

Account abstraction, Multisig, Any other contract based solution that doesn't share the same address across chains will lose it's TGLD in teleport.

Support

FAQs

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