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

Wallets using Account Abstraction Cant Use `TempleGold::send` for Crosschain Bridging

4rdiii

Vulnerability Details

Account abstraction wallets have been on the rise for quite a time now and have a lot of users. and users with account abstraction wallets have a different address across different chains for same account, since the templeGold is nontransfarable there is a check stopping users from bridging to other addresses, as a result of this these users will be unable to use this feature.

function send(
SendParam calldata _sendParam,
MessagingFee calldata _fee,
address _refundAddress
)
external
payable
virtual
override(IOFT, OFTCore)
returns (MessagingReceipt memory msgReceipt, OFTReceipt memory oftReceipt)
{
if (_sendParam.composeMsg.length > 0) {
revert CannotCompose();
}
/// cast bytes32 to address
address _to = _sendParam.to.bytes32ToAddress();
/// @dev user can cross-chain transfer to self
@> if (msg.sender != _to) {
@> revert ITempleGold.NonTransferrable(msg.sender, _to);
@> }
.
.
.
}
​

Impact

The primary impact of this vulnerability is the inability of users with account abstraction wallets to utilize the TempleGold::send function for crosschain bridging. This limitation excludes a growing segment of the user base from participating in crosschain activities, potentially isolating them from the broader ecosystem benefits and limiting the utility of their tokens.

Tools Used

Manual Review

Recommendations

To address this issue and accommodate users with account abstraction wallets, consider implementing a mechanism that allows for crosschain transfers without violating the non-transferable nature of the tokens. One approach could involve introducing a mapping system that recognizes the equivalence of addresses across different chains for the same underlying account. simmilar to authorized mapping which is used to allow transfers for whitelisted users there can be something simillar for these kind of wallets.

function send(
SendParam calldata _sendParam,
MessagingFee calldata _fee,
address _refundAddress
)
external
payable
virtual
override(IOFT, OFTCore)
returns (MessagingReceipt memory msgReceipt, OFTReceipt memory oftReceipt)
{
if (_sendParam.composeMsg.length > 0) {
revert CannotCompose();
}
/// cast bytes32 to address
address _to = _sendParam.to.bytes32ToAddress();
/// @dev user can cross-chain transfer to self
- if (msg.sender != _to) {
+ if (msg.sender != _to && bridgeWhitelisted[msg.sender] == false ){
revert ITempleGold.NonTransferrable(msg.sender, _to);
}
.
.
.
}
​
Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year 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.