Aggregator partners parameter revision
Problem
Aggregators like LiFi, Metamask, Bungee seem to be setting up the parameters of the transaction wrong. The main issue is that the slippage tolerance is set too low (0.5%) and when users get their transactions stuck, they aren't able to bump the slippage themselves, because the delegate is the aggregator (this seems to happen a lot with Metamask/Bungee transactions coming through Socket).
Impact
Users believe its our fault when a transaction gets stuck and they can't do anything about it.
Proposed Solution
We need to go through every partner and examine their integration with us and how the parameters are set for user transactions.
Acceptance Criteria
Users need to be able to control their transactions by themselves without relying on us or our partners (other than for customer support/help)
Adding another protocol that seems to have this problem: Gnosis Pay
Is it correct to set the delegate to be the receiver address? We should definitely make this clearer in our documentation and to our integrators. Basically what I think is that if you set it to the sender, that address might not exist or be able to make transactions on the receiving chain. But if you set it to the receiver, that address might be a CEX deposit address (problem pointed out here: https://github.com/connext/monorepo/issues/2476)