I was wondering what the transactions per second (TPS) capability of the Nash Exchange is when it comes to trading. I know we’ve all heard that Nash is non-custodial without sacrificing the performance of a centralised exchange. In the recent blog post it was mentioned that ‘Nash processes thousands of trades per second’, and I recall @canesin saying in the most recent quarterly report that Nash can handle much more volume than they currently have. In December 2018 Binance stated in a blog post that they were able to process ‘1,400,000 transactions per second’. I’m well aware that the type of infrastructure required to to process 1.4 million TPS may be unnecessary at this point in time but would it be possible to get a ball park figure of the type of throughput that Nash can currently handle?
This is a useless vanity metrics that we will not indulge. We are today 2X faster than Binance in what matters and on our route to be 10X faster. Latency of true order placement.
PS: 1.4M for a centralized exchange is a shame. There is faster open source stuff for that.
[edit]
Let me explain this better (long and borring ) since this is our amazing community!
The rate of inserts is certainly important up to a level: enough to sustain the volume. But is not a important metrics to speed at all. In a system like Nash for example each market has its own independent process, so all you need to say Nash has infinite speed is create a bunch of markets. Can you follow how this makes no sense? I have to take the hat off to Binance for marketing this to people that don’t trade - they did a good job at it.
Now why is order placement and cancellation latency so important? Because when you focus now on a individual market, let’s say BTC-USDC, you want to act as fast as possible in market opportunities, if your latency is say 200ms that means someone watching that market can only at maximum do 5 price improvements per second. And this is Binance right now. Nash is around 100ms so 2X faster and a trader can act upon market data 10 times per second, we are finalizing work to bring us to 20ms. So traders will be able to act 50 times per second in new data on each individual market, 10X better than Binance.
Thank you for your response and edit. After your initial reply I started looking at Little’s Law in order to try to understand it better. Would you say that is the right direction to research for a better understanding of this topic?
I don’t know if it’s any different for futures, but is the speed of the API but one constituent of the overall speed of order placement? - https://youtu.be/O0pqegq2jpM?t=898
I don’t understand this. You mean to say, as an algorithmic trader, I cannot trigger an order before the promise of the previous one has resolved?
Don’t get me wrong, I do think latency is paramount, much like in video games where your ping must be as low as possible to enable you to react as fact as possible. Just trying to understand the full explanation.
That data would be non public on a CEX so there is no way to prove it unless some whistleblower comes out, but it’s entirely possible and completely likely that it’s happening. With Nash we don’t have to worry about that and it’s not a possibility as Nash can provide proof the matching engine is fair.
@NashItUp Little’s Law is about how many consumers a serial queue can service, this is not the case here. My comment is from the perpective of the costumer not of the queue, you can have many people issuing orders at the same time.
@Vaugrin yes, it is one component. I am referring to true placement, which is: “seeing your order on the market subscription”. The difference would be conceptually:
trader —> API gateway —> trader
(API gateway reply with acknowledgement of the order)
trader —> API gateway —> matching engine —> subscription manager —> trader
(market data distributor gives back to the user his order)
(1) is much faster than (2). We actually have both options but (1) is not a differential, is just a vanity metric in practice as well, since it is much more a function of how close you get your servers to the exchange servers.
@Oldsport no, you can trigger several, including batching - which is very interesting to increase throughput. My example is basically how fast you can react to things you observe in the market while observing the side effect of your own actions.
All the blatant scams out there in crypto make frontrunning look pretty tame.
As @Moon said it is impossible to know as CEXs are a black box, however given the amount of front-running that happens on crappy ETH DEXs for all to see, one can be almost certain it’s happening on most CEXs. https://arxiv.org/pdf/1904.05234.pdf
True enough, but personally I don’t like it when ambassadors make claims which they can’t back up by fact. We’re on the official community page, not the pub
Thanks for the explanation. However we see the market maker bots leaving the spread wide open upto 6% sometimes in the BTC-USDC pair. May be the bots have to be tuned further ?
Actually i don’t name any CEX but believing the opposite would be naive ambassador or not.
Also, i was blocked two years ago from some Cexes twitter accounts that they unblocked me same day after the ambassador program announcement here so yes it’s a nice place to say this.
Okay, if you like to stir up the pot with speculation that’s on you. I don’t like it and think it’s a bad look on the project if ambassadors speculate in this manner.
Feels like you’re overreacting a bit… @greekscreamer was stating something that made the news more than once and though it is often hard to prove, I don’t think it’s a wild accusation to say some if not most CEXes are taking liberties with their orderbooks. Just take a look at the latest scandals involving Bitmex and Coinbase.
) since this is our amazing community!
