Summary

The TempleGold token (TGLD) is meant to be omni-chain transferrable through LayerZero only to the same user, thus for example Alice cannot transfer her funds from Arbitrum directly to Bob on ETH mainnet. However the logic enforcing this invariant enforces an error for users/entities interacting with the protocol through account abstraction wallets (AAWs) since, as smart contracts, they retain different addresses across the different EVM chains.

Vulnerability Details

https://cointelegraph.com/learn/account-abstraction-guide-to-ethereums-erc-4337-standard

The ERC-4337, also known as Account Abstraction, is a new paradigm to allow for a more user-friendly experience when interacting with Dapps. Account abstraction within blockchain systems allows for assets to be exclusively held by smart contracts rather than being controlled by EOAs.

However, these wallets being contracts means that their addresses will be different throughout the EVM chains, since contract addresses are derived from the nonce of the deployer per chain. This could lead to the scenario where:

1. Alice uses an AAW and interacts with TGLD, wishing to transfer funds from Polygon to Arb

2. However her AAW's address is different on the 2 chains

3. By enforcing the receiver on the destination chain to have the same address as the sender on the source chain, the funds could end up stuck in an identical address on the destination, which is not controlled by Alice, leading to her losing her tokens

Some previous example omni-chain dapps with the same issue:

https://solodit.xyz/issues/m-02-all-bridged-funds-will-be-lost-for-the-users-using-the-account-abstraction-wallet-code4rena-ondo-finance-ondo-finance-git

https://solodit.xyz/issues/h-01-user-can-lose-tokens-during-deposit-fallback-bridging-pashov-none-reyanetwork-markdown

Impact

User funds could be lost on the destination chain if they end up on an inactive or malicious address

Tools Used

Manual Review

Recommendations

It would be easier to implement checks that enforce only EOA ownership of the TGLD token, but I am not sure if excluding smart contract wallets is beneficial.

Allow the specification of a receiver address and enforce it to be a smart contract containing a hook, for e.g onTGLDReceived.

This way you enforce people to either transfer the tokens to their own EOA or to a smart contract that's verified via possessing said interface