From time to time there are issues with the settlement of transactions on the linear exchange. These issues can be observed, when transactions were executed on the exchange but there is no receive or revert of the traded tokens for an increased amount of time (>10 minutes). This can be very frustrating in situations when it’s essential to react to rough market situations or in case of needed actions on pratio issues. Sometimes it needs half a day to fix these issues by the linear team. No offense, everybody needs to sleep from time to time but I think this is no stable condition for traders using the platform. Every trader should expect their trades to be executed in a specific time window.
The reason for the issue is relatively simple. I heard a lot of explanations in the discord channel by the supporters. Most of the time it was bashing on BSC (BSC is congested, please kindly wait). But most of the time this is not the primary reason for the outage.
First of all I will have to explain one thing about the function of the exchange smart contract. There is the possibility to frontrun exchanges depending on delaying oracle pricefeeds like Chainlink or Band Protocol. The Linear-Exchange-Contract has a simple solution to prevent those attacks. It simply adds a two minute delay to all transactions. This means by trading on exchange the contract gives us the promise to execute the trade in two minutes instead of excuting it instantly. This makes it difficult for price frontrunners, because they cannot predict price move in this two minute time frame and frontrunning becomes unattractive.
Some infos about, how big of a problem those frontrunning attacks are, can be found here:
With the mentioned security feature comes a big problem. It is not possible to execute delayed transactions on blockchain level. This means there have to be an executer for the settlement or revert of the user initiated trading transactions. In case of our exchange this executor is a wallet which is held by the linear team. With normal operation, this wallet executes the contract settle method after two minutes of delay. if there were issues for 10 minutes (defined by the contract) the settlement is not possible anymore and the transaction has to be reverted. This revert transaction will also be done by the same wallet.
This means there is an automated bot connected to this wallet listening on trading events on the smart contract and executing the described methods from above after the given delay. If the bot is not running or out of funds there is no settlement and even no reverts of the user trades, which is the explanation for our issue until the linear team resolves the bot issue.
Sure the congestion of the BSC Network could be the reason for the bot to collapse in the first place and therefore it could be the secondary level reason for the issue, but the primary reason is that the bot is currently not transacting on chain.
THE (temporary) SOLUTION:
I want to propose to add a button to the exchange dApp, where the user can settle / revert her / his transaction by her- / himself in case of an outage like described above. It is technically possible to execute these transactions by any wallet. The smart contract is not restrictive in this case. I tested it by manully settle my transactions a lot of times in the described situations. This possibility should be given to all users of the Linear Exchange by a simple button click.
It could be automated, that the frontend gives the user this possibility after a defined timeout without settlement by the linear settlement wallet. The user can then decide if she / he will execute this transaction or wait for the linear bot to come up again. It costs a little gas fee, but this is not too high in contrast with possible losses which may occur by not settling the trade.
I think the long term goal should be the instant execution of the trades with another frontrunning prevention mechanism instead of this delay. But for now this should be an appropiate workaround for the described issue.
I would like to hear your thoughts and concerns about it.