$\begingroup$

The LMSR has a number of parameters which governs its function, but the LS-LMSR focuses, in particular, on the sensitivity function, AKA parameter b. This parameter determines how sensitive the market maker is to incoming orders. The higher the value, the less sensitive the market maker is, and the slower the price will change, because it requires more liquidity to increment the price.

It's up to market operators to set b appropriately, taking into account the amount of liquidity that's expected. However, this can be difficult to manage, as traders enter and leave the market. LS-LMSR outlines a programatic way to dynamically asses conditions and change the LS-LMSR accordingly, setting the value higher as the market thickens, and vice versa. Parameter b can be changed by the operator whenever the need arises, but LS-LMSR alleviates some of that management burden.

It probably would be a good idea for Augur and Gnosis to implement a dynamic way to manage liquidity, since relying on manual edits impedes scaling to large numbers of markets.

The LS-LMSR also describes a way to run the market maker at a profit. In many instances, operating at a loss isn't such a bad thing, at least to a pre-determined degree, since the initial liquidity is what attracts traders to enter the market. As with b, you can also edit this in time and bound losses to your liking (LMSR already supports this), but this paper provides a way to run profitably, or at least break-even.

As for whether to implement, this is a business model question. Exchanges will have to weigh the cost/benefit of sacrificing some money upfront to get participants to trade, with the desire to generate transaction revenue as the market intermediary. Both approaches are valid, but dependent what outcome you're trying to achieve.