In D17426#396257, @emack wrote:

No issues on a technical level, but philosophically, I feel this is overreaching on Cashtab's part. There are valid use cases where the seller is essentially setting this as a limit order, to be sold at their target price. I know scammers are leveraging this but implementing this diff means all etoken prices would only move in controlled increments, which goes against the DEX mantra. Also none of the mainstream DEXs do this either.

A better solution would be to use what cowswap or uniswap (I can't remember which one) did and simply pop up a warning if the user is buying more than 10x the current average spot price. If the user still gets tricked then that's on them and we've done our due diligence.

it's a good point, in general agora should be 100% laissez faire

the issue I have is with offers that are clearly fishing for someone making a mistake -- for example there are some XECX listings asking for 9 billion XEC for 95k XECX ... the "spot price" looks low / reasonable enough. The presence of these offers makes OrderBook less usable. They are also hugely asymmetric -- i.e. if only one person is tricked here, half the market cap of XECX just went to a scam.

How about this solution:

• We default to rendering only the offers within 20% of spot (20% is arbitary, open to changing this. 50% is probably more reasonable and useful for products like memecoins)
• We have a switch that allows the user to show all the offers
• We show warnings for any buys above spot

I think it's important to screen some of the orders out just to make the component more usable, esp as we often need to load 100s (soon thousands?) of these at once. While the above-spot orders are "hidden" on the front end -- they are still functionally limit orders. If the spot price orders are consumed, then spot changes, and these more expensive orders would eventually be rendered by default. The orders themselves also still exist on the chain. Anyone could still accept them with their own front end or programmatically. Cashtab being open source, anyone could fork it to show whatever.

In D17426#396302, @bytesofman wrote:

In D17426#396257, @emack wrote:

No issues on a technical level, but philosophically, I feel this is overreaching on Cashtab's part. There are valid use cases where the seller is essentially setting this as a limit order, to be sold at their target price. I know scammers are leveraging this but implementing this diff means all etoken prices would only move in controlled increments, which goes against the DEX mantra. Also none of the mainstream DEXs do this either.

A better solution would be to use what cowswap or uniswap (I can't remember which one) did and simply pop up a warning if the user is buying more than 10x the current average spot price. If the user still gets tricked then that's on them and we've done our due diligence.

it's a good point, in general agora should be 100% laissez faire

the issue I have is with offers that are clearly fishing for someone making a mistake -- for example there are some XECX listings asking for 9 billion XEC for 95k XECX ... the "spot price" looks low / reasonable enough. The presence of these offers makes OrderBook less usable. They are also hugely asymmetric -- i.e. if only one person is tricked here, half the market cap of XECX just went to a scam.

How about this solution:

• We default to rendering only the offers within 20% of spot (20% is arbitary, open to changing this. 50% is probably more reasonable and useful for products like memecoins)
• We have a switch that allows the user to show all the offers
• We show warnings for any buys above spot

I think it's important to screen some of the orders out just to make the component more usable, esp as we often need to load 100s (soon thousands?) of these at once. While the above-spot orders are "hidden" on the front end -- they are still functionally limit orders. If the spot price orders are consumed, then spot changes, and these more expensive orders would eventually be rendered by default. The orders themselves also still exist on the chain. Anyone could still accept them with their own front end or programmatically. Cashtab being open source, anyone could fork it to show whatever.

I'm late in this discussion but imo the issue lies in the order book itself. It's hard to reason about for a few reasons:

• Users barely care about listing quantities. If you want to buy 1000 tokens at a given price, then all you care as a buyer is that there is at =>1000 tokens available at that price. This is also how order books usually show the listings, it's cumulative. Also related: as a buyer, if I want to buy 1000 tokens and listing is like 100 for 1 XEC each and 5000 for 2 XEC each, I am OK to buy some at 2 XEC each but I also want to drain the 1 XEC ones in my buy.
• The meaning of the grey/green bars is very cryptic. In fact I don't know what the grey bar means at all, and I guess the green is the completion level ? But why is it on the right then, progress bars usually grow from left to right ?
• There is some de facto standard: green for buys, red for sells. Here it's all green which is confusing for buyers.
• If you want to quickly show price discrepancy, why not use e.g. a color scale (or another kind of scale) ?

These are good points but imo a lot gets beyond the scope of this diff. Indeed we do have many opportunities to improve OrderBook.

I'm late in this discussion but imo the issue lies in the order book itself. It's hard to reason about for a few reasons:

Users barely care about listing quantities. If you want to buy 1000 tokens at a given price, then all you care as a buyer is that there is at =>1000 tokens available at that price. This is also how order books usually show the listings, it's cumulative. Also related: as a buyer, if I want to buy 1000 tokens and listing is like 100 for 1 XEC each and 5000 for 2 XEC each, I am OK to buy some at 2 XEC each but I also want to drain the 1 XEC ones in my buy.

Technically possible but I think not impactful enough to justify the implementation. Requires 2 txs to accept two offers. So we would need to be chaining txs in the "back-end" of this front end app. We already do this for some cases, like listing SLP offers, so it's not impossible. But since fees are so low and accepting 1 offer still needs to be optimized, I don't think we are ready to add this yet. I could see supporting this after we add an option for text input of desired buy qty.

The meaning of the grey/green bars is very cryptic. In fact I don't know what the grey bar means at all, and I guess the green is the completion level ? But why is it on the right then, progress bars usually grow from left to right ?

The grey bars are depth charts. if there is only 1 order, it will show 100% width. If there is another (smaller) order, its width will be proportional to the largest order. It's confusing in OrderBook because, on traditional exchanges, this depth is cumulative. So yes, this should be reworked on OrderBook to match the traditional exchange UX.

There is some de facto standard: green for buys, red for sells. Here it's all green which is confusing for buyers.

Yes. I do still like the "fill the depth bar green to show the user how much of the offer they are about to accept". But this too can probably be optimized. I think if we fix the depth bar cumulative issue described above, this becomes more clear.

If you want to quickly show price discrepancy, why not use e.g. a color scale (or another kind of scale) ?

We could, but esp given the above two points -- we already have a problem that the UI is too confusing. Rendering fewer bars is the easiest way to solve this problem.

I think this kind of approach could work

• Finish this diff with some kind of agreed solution. I think rendering fewer bars, at least by default, is the way to go -- since these scam / phishing offers are actually quite common. We could even bump the value from say 20% or 50% to something like 500% to just get rid of these, tho that would prob just encourage these scammers to switch to 500% instead of 1000% scams.
• Patch the input so we support text input and not slider-only
• Make the depth bars cumulative
• ... other optimizations? would have to see "what's next" after we deal with the above

• Finish this diff with some kind of agreed solution. I think rendering fewer bars, at least by default, is the way to go -- since these scam / phishing offers are actually quite common. We could even bump the value from say 20% or 50% to something like 500% to just get rid of these, tho that would prob just encourage these scammers to switch to 500% instead of 1000% scams.

I'm ok with this approach if it brings immediate value to the UX.
If scrolling up shows a link-like button that says "load more expensive offers" and we limit to say 5 or 10 listings by default, this will improve the UI a bit on its own. Also no need to fight with %, just create enough listings to fill the default display area.

I understand that the order book improvements are much more work and seems to not belong to this diff, but if the root UI issue was fixed this diff would not exist to begin with.