fix(svm): H-01 optimize claiming relayer refunds

[Reinis-FRP]

OZ identified following issue:

When a relayer within a transaction leaf cannot receive direct refunds, such as due to a failed token transfer caused by blacklisting, the protocol uses claim account PDAs to handle the refund. However, this fallback mechanism imposes limitations on other relayers within the same transaction, forcing all of them to claim refunds via a ClaimAccount PDA, even if direct refunds are possible for them. This leads to the following issues:

• Risk of Hitting Compute Budget: The accrue_relayer_refunds process involves find_program_address, which can be computationally expensive as it iteratively attempts to validate a valid bump. Since this process can be used for several accounts, there is a high likelihood that the transaction will revert. Consequently, relayers and users may not be able to retrieve their refunds from that leaf.
• Refund Delays: A relayer might claim their refund from its ClaimAccount PDA right before the execution of a leaf, reducing the vault’s total available funds. This could delay refunds for other users as the protocol might lack sufficient liquidity at the time of execution.
• Increased Execution Overhead: Executors are responsible for ensuring that all relayers have initialized claim accounts and are incurring additional computational and financial overhead, including the cost of covering rent exemption fees.
• Liquidity-Related Reverts: Relayers can attempt to claim refunds when the spoke pool lacks sufficient liquidity. This scenario might result in transaction reversion without providing a meaningful error message, as the hub pool does not track outstanding spoke pool debts.
• Prone to misuse: Since the function can be invoked by anyone, malicious actors could front-run the data worker, unnecessarily deferring refunds even when direct refund mechanisms are operational. In addition, a malicious relayer might force the use of claim accounts and delay its refund claim until just before the execution of a leaf, deliberately triggering a revert to disrupt system operations.

Consider implementing logic to route refunds only through ClaimAccount PDAs for relayers that are explicitly unable to receive direct transfers. This would optimize operations, prevent errors, and reduce overhead. Moreover, consider enhancing error messaging to clearly indicate insufficient liquidity in the spoke pool during claim attempts. This change would ensure smoother operations and improved clarity for users.

We have opted to apply only a limited fix by optimizing the way how relayer refund claim instructions are composed by moving its parameters to account data.

[linear]

ACX-3579 H-01 Forced Use of Claim Accounts for All Relayers in Certain Scenarios

[md0x]

Out of curiosity, why do we simulate the first relayer being blacklisted?

[Reinis-FRP]

agree, this was rather arbitrary. now simplified the tests by claiming to all accounts

[md0x]

Looks good!

[md0x]

Nice improvement!

[md0x]

ThisclaimRelayerRefundFor is remaining