fix(svm): M-01 Deposit Tokens Transferred from Depositor Token Account Instead of Signer

[md0x]

OZ identified the followin issue:

A deposit action to the SpokePool program is meant to [pull tokens from the caller](https://github.com/across-protocol/contracts/blob/71e990b3f908ecf994be8723e041b584c7d49318/programs/svm-spoke/src/lib.rs#L213) (i.e., the [signer](https://github.com/across-protocol/contracts/blob/71e990b3f908ecf994be8723e041b584c7d49318/programs/svm-spoke/src/instructions/deposit.rs#L30)) which may be deposited on behalf of any depositor account. However, when the signer is not the depositor, a transfer_from operation is performed with the [depositor token account as the source address](https://github.com/across-protocol/contracts/blob/71e990b3f908ecf994be8723e041b584c7d49318/programs/svm-spoke/src/instructions/deposit.rs#L105). Such an operation would fail unless the depositor had delegated at least the input amount to the state PDA. This presents two consequences:

The signer will not be able to deposit for another account, disabling the intended feature of an [account being able to deposit on behalf of someone else](https://github.com/across-protocol/contracts/blob/71e990b3f908ecf994be8723e041b584c7d49318/programs/svm-spoke/src/lib.rs#L210).

If any token account delegates to the state PDA, then it is possible for anyone to call the deposit function, passing the victim's account as the [depositor_token_account](https://github.com/across-protocol/contracts/blob/71e990b3f908ecf994be8723e041b584c7d49318/programs/svm-spoke/src/instructions/deposit.rs#L45) and performing a successful deposit with arbitrary arguments other than the input token and amount. A malicious user could then submit a deposit with their own recipient address to steal depositor funds. This is possible due to the state PDA being passed as the [authority and signer seed](https://github.com/across-protocol/contracts/blob/71e990b3f908ecf994be8723e041b584c7d49318/programs/svm-spoke/src/utils/transfer_utils.rs#L19-L28) to the transfer_checked call, which, when delegated to, will pass [the transfer validation logic](https://docs.rs/spl-token/latest/src/spl_token/processor.rs.html#274). Note that this scenario is mitigated by the fact that native instruction batching in Solana transactions would typically involve delegation and transferring in one operation, making such a front-running scenario less likely but still possible.

Consider validating the signer token account in the same way as depositor_token_account, and performing the transfer from the signer token account.

We replaced the one “state” PDA with two distinct PDAs—one for deposit and one for fill_relay. Now users must explicitly delegate to the correct PDA before anyone can pull their tokens, restoring safe third‑party deposits and eliminating the risk of a single authority being misused to steal funds.

[linear]

ACX-4021 M-01 Deposit Tokens Transferred from Depositor Token Account Instead of Signer

[Reinis-FRP]

Suggested change

	// Relayer must have delegated output_amount to the delegate PDA
	// Depositor must have delegated input_amount to the delegate PDA

[Reinis-FRP]

It might be cleaner to move seed derivation back in the transfer_from helper, just pass additional delegate hash and bump to it

[Reinis-FRP]

do tests depend on this? if not, we better drop the state seed here as its 0 on public networks

[Reinis-FRP]

this still would allow someone to steal delegation from separate tx by replacing recipient and message. I think it would be safer and more consistent if we hashed all deposit parameters

[Reinis-FRP]

this still would allow someone to steal delegation from separate tx by replacing repayment address and chain. I think it would be safer and more consistent if we hashed all fill_relay parameters. maybe except for relay_data as that is already represented by relay_hash

[Reinis-FRP]

do tests depend on state.seed? if not, we better drop the state seed here as its 0 on public networks

[Reinis-FRP]

consider moving seed derivation in transfer_from helper

[Reinis-FRP]

maybe use AnchorSerialize::serialize or try_to_vec, so that we don't need to be explicit on individual field encoding