You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some niche scenarios it may be possible that a user does not have ownership over their associated token account (for example, after a phishing attack).
A nice UX for these unlucky users would be to allow them to specify an alternate token account where they can claim transfers.
The logic of the release_inbound function could be modified to do an explicit owner check on the primary account and, if there is account owner does not match, transfer the funds instead to the alternate account.
Added ABI label because I think adding the alternate account would change the function signature and thus the IDL as well. Not sure if this is correct or if there are alternate designs we could consider.
In some niche scenarios it may be possible that a user does not have ownership over their associated token account (for example, after a phishing attack).
A nice UX for these unlucky users would be to allow them to specify an alternate token account where they can claim transfers.
The logic of the
release_inbound
function could be modified to do an explicit owner check on the primary account and, if there is account owner does not match, transfer the funds instead to the alternate account.Similar example from Mango:
https://github.com/blockworks-foundation/mango-v4/blob/f54bb6f0b00f4674f7177b3b1484ae5d615b0805/programs/mango-v4/src/accounts_ix/token_force_withdraw.rs
The text was updated successfully, but these errors were encountered: