The team [claims to have a solution][1] that works for their DEX.

> The solution uses an intra-block slot auction system to process multiple transactions simultaneously, which is essential for a fully functional and high-volume DEX.

Looking forward to learning more about that approach.


Another solution I've thought about is introducing an off-chain service provider called a "batcher" who is incentivized to batch a bunch of concurrent transactions.

Take a DEX for example. If many people are trying to provide liquidity to a pool at the same time, instead of them all trying to access the "liquidity total" datum at the same time, each actor could lock their liquidity + a batching fee in a separate escrow script that requires a minimum amount of liquidity tokens to unlock. They then submit a "batching request" datum to the DEX. The off-chain batcher can filter all the request datums and execute as many as they can simultaneously. 

The minimum liquidity token requirement on the escrow script prevents the liquidity providers from being screwed over--they set the terms-- and it also allows some flexibility in a volatile market, but there is still a level of centralization of the batcher. My biggest worry would be regulatory intervention, as the batchers could be seen as [MSBs][2]. You could theoretically solve this with federalization of the batching responsibility.


All-in-all, I think there are many ways to solve the concurrency problem. Charles talked about additional side-chain solutions in [this video][3]. I think we just need to be comfortable with the idea that the solutions might just look different from what we see on Ethereum, and that's okay. Ethereum has it's own set of problems that needed creative solutions as well.