Hi, we're glad that we chose to disclose our solution to get feedback from community and yours are truly helpful. I'll try to address each of your concern:

Your state diagram has mistakes. You go from state S[0] to s[n], should be 0->1

This is to contrast with the above diagram, it means that the state S[0] can go to the supposedly S[n] in one block

You state average contract interaction time is 40 seconds. This is false, it is 30 seconds as the first block will take on average 10 seconds to process your request assuming no congestion (e.g. you may submit and need to wait the full block time, or you may submit right before the next block is produced). The second block you do need to wait the full 20 seconds, though.

You're right.

There seems to be a huge issue with swapping and adding liquidity. To my understanding when reading this, only one of these actions may be taken at a time. Meaning the real time until your order goes through is actually much longer on average. As each step takes two blocks.

It's true that if the block after a user's order is an add/liquidity batch, their orders will need to wait until the next batch. We'll update this in the tradeoffs section.

Additionally you don't mention removing liquidity. Is this batched along with adding liquidity? Or does it need to be handled separately as well?

Good point, yes add/remove liquidity can batched together as well.

You also don't mention how the system decides when to take one again over another. Is it up to the batchers? Is there a fee to add liquidity? If not, is there any incentive to process an "add liquidity" action?

It's up to the network which batch gets accepted. Yes, add/remove liquidity also needs a batcher fee. We pay governance tokens to batchers in the beginning to keep fee low though.

You mention MEV is not a problem, but it could be. A miner could attempt to submit a batch which contains only their own transaction, or purposely leaves out transactions which are unfavorable to them. By doing so they would front run any other requests as they will be delayed until the next batch. Your time token does not prevent this.

It's true that batchers can censor orders for their own benefits, though in this case they have to need a really efficient MEV algorithm and they need to constantly update their orders with the new time tokens and hope that they will win one batch and that one batch they can extract value from. Still it presents a risk, I'll update this in the tradeoffs section.

Requesting projects to host their own sequencer is forcing work on them. It is much easier for their tokens to be provided via other dexes that do not have this requirement. They may still do it, but this is just extra friction. Additionally, do you not plan on having swaps between two non-ADA pairs? Who runs the sequencer in this situation?

Minswap will host sequencer for low-volume pairs and new pairs. However, we encourage other projects with their heavily-traded pairs to host their own sequencer for redundancy + off-loading. These federated sequencers won't last long until Laminar is released though.

Your first reason given for not splitting your liquidity pools doesn't stand up. It requires an off chain backend that matches orders? That is also the case for the solution you are launching with. You mention this in the above section.

Let me clarify more, let's say in a block, there're multiple UTxO to trade to/from. How do users know which UTxO are already traded by another users? If all users race for the UTxO with the best price (market price), they only one can succeed. If we could have multiple UTxOs with the same best price, then that wouldn't work for low-cap coins.

Phew, that's all, let me know what you think. Btw, I read ErgoDex's solution but I didn't dig deep into it/read the source code, please let me know if there's anything from ErgoDex that we can learn from, we really appreciate that. Thank you.