Overpay squidrouter transaction value.

[gianfra-t]

Changes:

• Increases the value amount pre-signed into the squidrouter transaction for resilience against price fluctuations.
• Wait 180 minutes vs 15 minutes to execute the main Moonbeam cleanup transaction. This will give more Axelar more time to refund the excess fee payed, and avoid the need to execute a backup cleanup.

Closes #653

[netlify]

✅ Deploy Preview for pendulum-pay canceled.

Name	Link
🔨 Latest commit	7203258
🔍 Latest deploy log	https://app.netlify.com/projects/pendulum-pay/deploys/682caead8ae8c3000851e613

[ebma]

Isn't 50% a bit much? How about we do 10 to 20 percent? Also, you need to check if the amount would exceed what is provided by the funding account to the Ephemeral. It could be that this extra margin exceeds the amount of GLMR that will be sent to it.

[gianfra-t]

That's a good point regarding the the funding account. I added the safe factor multiplication also into that check such that it is taken into account.

But about the amount itself, it may be a bit too much, but 20% may be a little too small to actually have a noticeable effect. It is true we should also increase the funding amount to keep the same level of coverage we have right now. What about 30%?

[ebma]

How about we choose the middle ground and go for 25% as the factor.
I wouldn't further increase the funding amount. I would imagine some check like

const overpaidFee = Math.min((new Big(route.transactionRequest.value)).mul(1 + SQUIDROUTER_FEE_OVERPAY),FUNDING_AMOUNT_GLMR - 1);

or similar, not sure how that constant is called anymore. Math.min or Math.max are not available on Big numbers IIRC so we need to implement something for that. But that's the gist.

[gianfra-t]

I Reduced it!

About the last part, I didn't understand. You mean capping the overpay fee to the max funding possible, instead of this? But then, for quotes that are right on the limit of what we support, the overpay will essentially be 0, which gets us in the same place as we started.

[ebma]

You mean capping the overpay fee to the max funding possible, instead of this? But then, for quotes that are right on the limit of what we support, the overpay will essentially be 0, which gets us in the same place as we started.

No, it would still be an improvement. Let's make an example.

• We are always funding the ephemeral with 150 GLMR for Ethereum.
• The squidrouter transaction for that particular ramp at that time denotes a gas/network fee of 40 GLMR.
• We scale that 40 GLMR by the overpay percentage and end up with a squidrouter transaction that pays 50 GLMR to the network.

If we are at a time when the network fees are high, we would have the following

• We are always funding the ephemeral with 150 GLMR for Ethereum.
• The squidrouter transaction for that particular ramp at that time denotes a gas/network fee of 140 GLMR.
• We scale that 140 GLMR by the overpay percentage but with a Math.min check so that it doesn't exceed the funding amount. The resulting amount would be 150 GLMR (though we should probably in the Math.min check do 'FUNDING_AMOUNT_GLMR' - 1 to ensure we still have some GLMR to pay for the transaction itself on Moonbeam).

We could also do it the way you want, ie. not hard-code a max funding amount but derive the funding amount from the required squidrouter gas fee + the overpay. But we don't really know how large this can get and we would possibly spend a lot on these transactions.

[gianfra-t]

Mmm yes I understand with the behavior you were describing, I was saying it doesn't change much but of course that is for the cases where the fee is close to the funding cap. My rationale was that exactly at those moments the fees become more volatile, this is just an assumption of course.

Let's not delve into too much detail since this is already a temporary fix, and we don't quite know the problem enough to derive a perfect solution. I'll change it to the initial suggestion.