At the moment the majority of our solvers will settle trades one by one. Since we wait 30 seconds between batches and mining the solution tx takes some time, we can effectively handle about 0.5-1 individual trades per minute.
This has become noticable in today's testing challenge (worsened by the fact that we were stuck 5 minutes without a solution submission) when multiple people tried to trade non-overlapping tokens at the same time, some trades got very delayed.
This might be important to address, before we get real traffic which might be spiky (e.g. around tweets, etc).
A simple approach would be to make the solver trade return a list of solutions, which we could batch up into a single settlement (or multiple parallel txs). However, this bears the risk of one solution effecting e.g. the uniswap state of another solution and might therefore be invalid by the time the first is mined (maybe we can base all our queries on the pending block which could already have the first solution applied).
We should at least skip the 30s pause when there has been a solution submission in the current run loop.
At the moment the majority of our solvers will settle trades one by one. Since we wait 30 seconds between batches and mining the solution tx takes some time, we can effectively handle about 0.5-1 individual trades per minute.
This has become noticable in today's testing challenge (worsened by the fact that we were stuck 5 minutes without a solution submission) when multiple people tried to trade non-overlapping tokens at the same time, some trades got very delayed.
This might be important to address, before we get real traffic which might be spiky (e.g. around tweets, etc).
A simple approach would be to make the solver trade return a list of solutions, which we could batch up into a single settlement (or multiple parallel txs). However, this bears the risk of one solution effecting e.g. the uniswap state of another solution and might therefore be invalid by the time the first is mined (maybe we can base all our queries on the pending block which could already have the first solution applied).
We should at least skip the 30s pause when there has been a solution submission in the current run loop.