ℓPIP: transaction settlement fallback button for linear service downtimes

The X-files
1

THE ISSUE:
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:
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.

WHY TEMPORARY
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.

Best regards!

4 Likes
2

Hi Pho, nice proposal here.
I agree this is definitely a bug bear, even the 2 minute time elapse is frustrating if you are impatient like me!
But agreed, when things are critical, like when market conditions are ripe/volatile or if liquidation is imminent delays on the exchange are really unwelcome.
As you say, the end goal should be seamless function.
What are your thoughts on the sythetix solutions as per the article you attached, out of interest?

3

Hey @JPR,

thanks for your response. For me it’s also preferable to trade without delay, because non frontrunning users should get the price they traded the liquid for. But as the article states frontrunners could cause serious damage to dept pool holders. It’s hard to prevent those attacks without annoying trade offs.

The solution they presented is very similar to the mechanism the Linear protocol is using as far I understand. Additionally they added a second onchain price data feed to select the worst price of both. But honestly I don’t like this approach at all. It should technically prevent frontrunning but it also prevents a user friendly handling of the exchange. Additionaly they hope that the usage of faster OE (optimistic ethereum L2) will reduce the Chainlink oracle delay, which is true, but far from a solution for the problem.

For me, a solution could look like the following:

Every trade should be executed immediately for the oracle price. There must be a fee in place which is high enough to make 99.9% of the frontrunning attemps unprofitable. Some off chain workers collect off chain price feeds and calculates the necessary fee level. The fee will be repayed to each trader who is in a defined standard deviation of the chainlink to real world price data after a certain amount of time. The fees which are not repayed will be distributed to all deptpool users as rewards. There could be more rules to make the decision on repaying the fee.

I’m currently trying to build a prototype of such an approach to prove it’s working, but my spare time is very limited atm. For the meantime, the additional button for settling your own transactions after the 2min timeout should help to reduce the frustration to use the exchange in the described situations.

Hope to hear some more feedback!
Best regards!

1 Like
4

Excellent, would be good to see such a prototype.
Regarding this lpip, I am just checking with core team the feasibility, it looks doable but we want to double check with the devs and get some more concrete timeframes etc.
Once I hear back I’ll revert back to you here so that we can push this to snapshot.

All the best, and thanks again for such thoughtful input.

1 Like
5

It’s been almost a week since your reply. Counted 3 settlement outages in critical situations when I had to settle the transactions by myself in the meantime. I think this would be a much appreciated solution for the exchange users until the issues finally get fixed.

It’s really not hard to implement and should be possible to implement it in MAX 100 lines of javascript. Could provide working example code if devs have issues or doubt about it.

best regards!

1 Like
6

Hi Pho, good news we have a green light on this one so we can push to snapshot when you are ready.
Let me know if you need any assistance in moving to snapshot or if you prefer the LC to post.

Best, JP

1 Like
7

Will do it ASAP. I’m currently on the road.

1 Like
8

@pho I love your pragmatism and initiative to solve this. I completely support it! Thank you

1 Like
9

The Vote on Snapshot can be found here:

https://snapshot.org/#/lineardao.eth/proposal/0x54e96ffef5f7ee375de9faa1124cd52afb8ee08c5e9f202a47b5326bba9c77e8

Best regards!

2 Likes