Closed in33dngrok closed 7 months ago
Thank you for raising this issue, I'll address it as a high priority item
hey, I've pushed a fix for this issue and it calculates executionFee dynamically now(the same way as gmx-interface) Could you try again after deploying the latest version?
It works well on my end
@junta thank you for looking into this, so far so good.
@junta after giving it some time to run, some transactions were successful, while some are not. it seems executionFee
is now 0.00116224119
ETH consistently and anytime it requires more than that the transaction is reverted. For instance, I just used the interface and had to send 0.0013956283
ETH.
thinking this could this be more lenient since the difference is returned at the end of the transaction.
I've seen code and warnings pointing out when the execution fee is ~10USD.
I think the minimums are referenced in https://github.com/gmx-io/gmx-interface/blob/30b808dba44ed241f8464f88e72cb4c2d700cd9d/src/config/chains.ts#L147-L150
Hey, I've fixed a bug and pushed a new code. Could you try again?
I've been testing this out since support for GMX was added, and so far it works, but there are more failed transactions than I am comfortable with.
I think it has something to do with the fact that
executionFee
is hard-coded:https://github.com/junta/tradingview-alert-connector/blob/f8b6d8323326b4cdd427eab4ad8d97efa298c571/src/services/gmx/createOrder.ts#L25
The main reason I believe this is that the failed transactions all returned revert at
OrderUtils.validateExecutionFee
The gmx-interface and GMX-SDK (which looks to be pulled from the interface) seem to use a little more logic when determining that value.