TempleGold

Summary

TempleGold::send() is having if (msg.sender != _to) { revert ITempleGold.NonTransferrable(msg.sender, _to); } to prevent the indirect way of people transferring or selling TGLD in Pre markets like behavior, but the problem is that this would lead to potential loss of funds to people using smart wallets

Vulnerability Details

Temple Gold token is OFT implementation that doesn't allow transfers and the underlying value of it comes from the fact that Holders can bid using TGLD tokens and at the end of the auction, everyone will receive TGLD (THIS SHOULD BE ) pro rata relative to the final TGLD price for the lot.

Having in Mind that (almost) all the upcoming airdrops won't be on other Chains (New protocols building on new Blockchains)

First, to understand the underlying risk we need to know that there are nearly 10M Safe wallets deployed across chains according to this Dune analytic here

in Line #290 we see check that msg.sender != _to which will always be the case as msg.sender here is the safe contract and not the user that the tx originated from
in addition to that

• safe wallets are smart contracts that will have different addresses on different chains

Now the problem here came from the following

• Protocol didn't prevent users using safe from interacting with them using checks like .isContract() or other methods during bidding in DaiGoldAuction or during staking in TempleGoldStaking contracts

• Token doesn't allow transfers (this disallow user to transfer tokens to other address and bridge it to work around this problem)

• Nearly Almost the highly valuable anticipated Airdrops that the user want to participate in their SpiceAuction would need them Bridging from arbitrium (critical functionality to users)

For those Users, Loss of utility of their TGLD tokens means loss of funds (they bought it with DAI)

Impact

High

Users will be Stuck with TempleGold tokens and wouldn't be able to participate in any airdrop that will require cross chain

Loss of opportunity of Any airdrop Cross chain -> loss of funds

Probability -> high -> 10M users using safe implementations, some may even use other implementations and the error will always occur to them

Tools Used

Manual Review

Recommendations

The following

• prevent users using safe from interacting with protocol using checks like .isContract() or other methods during bidding in DaiGoldAuction or during staking in TempleGoldStaking contracts

• I think any work around would lead to the violation of the msg.sender != to and for the design of the current protocol and its underlying intent it would be better and easier to prevent those users from interaction with the protocol for the start