Solana: Add some mechanism to allow redemption or meaningful rejection for an incorrectly configured transfer VAA

[barnjamin]

Description and context

The Solana Token Bridge requires the recipient of an inbound transfer to be the Associated Token Address (ATA) for the receiver + mint address.

Without knowing this detail ahead of time, it is easy to include either the wallet address or an incorrect ATA as the receiver from the transfer origin chain.

The VAAs including an incorrect receiver cannot be redeemed or refunded since the Solana Token Bridge cannot validate the accounts in the VAA.

Proposal

Add some instruction to the Solana Token Bridge that allows the EOA (either as recipient or as the owner of the ATA that is the recipient) to submit the VAA for some valid action.

With the signature from the EOA, we can be confident that the owner of the account for the recipient set in the VAA is approving the action.

If the recipient of the VAA is the public key of the EOA or an incorrect ATA (but owned by EOA), the logic in the new instruction should be able to allow either redemption or produce some reject message that allows the tokens to be redeemed back on the origin chain.

Definition of done

The code is written, tested, audited and deployed.

[evan-gray]

I would be in favor of an instruction that would allow the owner (of the token account / or if it is their account on the VAA), as the signer, to redeem but specify a new token account to redeem it. I think that is far less complex than initiating another transfer, and likely what they intended anyway.

[barnjamin]

Definitely more complex to try to issue a transfer back to origin 👍

Could this instruction allow for redemption of a transfer that was sent to the wrong ATA? That is, the receiver is set to an ATA (controlled by the EOA attempting to redeem) but it doesn't match the derived mint address for the EOA+Mint?

[nullbitx8]

Thank you for creating this issue @barnjamin ! As someone who has been bit by this issue, I support this change and am happy to help wherever I can to make it happen.

Pasting some previous issues/discussions that I could find below. leoluk supporting the reversion of a VAA when the wrong ATA was provided by the EOA, and guardians signing off on it. The justification was that it is provable that the EOA won't be able to claim the funds on the destination chain.

hendrikhofstadt pointing out issues with a rescue function. But I believe in this case the wrong token was sent to the wrong ATA. So it may be a different problem.

I would be in favor of an instruction that would allow the owner (of the token account / or if it is their account on the VAA), as the signer, to redeem but specify a new token account to redeem it. I think that is far less complex than initiating another transfer, and likely what they intended anyway.

This does seem simpler and would resolve my problem. I transferred funds to the wrong recipient (my EOA) instead of my ATA.

[obumnwabude]

I fully agree.

The average Solana user doesn't really know about ATAs until they are a developer or have to do some developer stuff.

I think the safest we should do is to have a cascade.

Given that the current default with the Solana Token Bridge at redemption point is that it expects the ATA to have been the specified recipient from the source chain, we could add a cascade that will first check if the specified recipient is an ATA and then complete the transfer; otherwise, we check if the specified recipient is an EOA (if it's owned by System Program or if it's not owned by Associated Token Program) then we simply send the funds to the ATA of the recipient (it should have been initialised and provided in the transaction).