Jump to content
rippledigital

Tick size amendment #1922

Recommended Posts

Just to make things clear, are we talking about significant digits here? Suppose gateway has asset AAA which currently has price against XRP of AAA/XRP = 0.001. Then after setting TickSize = 5 the highest precision price would look like 0.0010000 (i.e. five significant digits)?

Edited by culminator

Share this post


Link to post
Share on other sites
1 hour ago, culminator said:

Just to make things clear, are we talking about significant digits here? Suppose gateway has asset AAA which currently has price against XRP of AAA/XRP = 0.001. Then after setting TickSize = 5 the highest precision price would look like 0.0010000 (i.e. five significant digits)?

It says:

Quote

AccountSet transactions may set a "TickSize" parameter. Legal values are 0 and 3-15 inclusive. Zero removes the setting. 3-15 allow that many decimal digits of precision in the pricing of offers for assets issued by this account.

So... if Gatehub issue EUR, they could set it to, say, three decimal digits precision. Which means, I think, no one can make an offer of e.g. 1.00123 EUR specifically, only 1.001, 1.002, 1.003, etc? Correct me if I'm wrong!

Obviously three isn't very much for advanced trading, I expect most gateways will choose a higher precision setting but not so high that only bots can effectively place orders with their ridiculous micro-adjustments.

Edited by rippledigital

Share this post


Link to post
Share on other sites

Based on this test, it seems like it will be significant digits as expected. Although for some reason this test seems to expect not rounding, as the function there is called, but it just trims the digits off the end of that number. Did not look into this much, just found it a bit odd.

Share this post


Link to post
Share on other sites

What's the problem of offer spam? Ripple can handle 10k TPS or more...

If they really want to see price changes (i.e. a reduced spread) they should give some incentive to MM or incentive to gateway to reduce they ENORMOUS transfer fees.

Share this post


Link to post
Share on other sites

It's not constraining the digits of the amounts, it's constraining the digits of the "quality" aka the ratio between the prices of the two currencies to be traded.

 

If I offer to sell 100 EUR.SomeGateway for 1000 XRP, that's a quality of 0.1 in the XRP:EUR.SomeGateway market. If David offers to sell 3.333333 EUR for 33.3333 XRP, that's still a quality of 0.1 even though the absolute amounts have different significant digits. If his offer comes after mine, it gets placed below mine.

If Nik offers to sell 100.00001 EUR.SomeGateway for 1000 XRP, that's a quality of 0.10000001 in the same market. Since Nik's offer is of higher quality, it's ranked above David's and mine even if our offers were on the books first.

The problem is, even though Nik's offer is technically better, the amount you get if you consume part of Nik's offer is essentially the same because that extra few fragments of a cent isn't likely to add up to anything that can be redeemed for real value. So basically Nik got to cut in the line by offering nothing of value.

Then if Nik's order-sniping bot and someone else's start fighting over the top of the XRP:EUR.SomeGateway market, they can go back and forth for quite a while, placing bids that are microscopically better than each other without ever adding up to being better enough that any real person would care which offer they took. This occupies a bunch of disk space (all transactions are in the history forever!) and means processing a bunch of transactions that aren't valuable. Even though Ripple can handle that traffic (as it does today!), it's wasteful to conduct business that way.

Enter tick sizes. If EUR.SomeGateway sets their tick size to 3, then Nik's offer  is rounded down to 0.100 quality, same as mine and David's, which means Nik's offer gets placed after ours. If he wants to actually claim first place in the order-book line, he's going to have to outbid us by an amount that's at least sort of significant. If he's content with the price where it is, he can let his offer sit in line.

 

It's not solving a really big problem, but it does make life easier for traders and network nodes.

Share this post


Link to post
Share on other sites

@mDuo13 Unless there has been new stuff published in the last 6 months, I believe that I have reviewed all the material on Quality (in/out) but something is still not quite concrete in my mind.

This is an important concept/topic, so is it possible for you guys to put up some material focused specifically on Quality, and the thinking about why it is an important metric and aspect of a TX, and then link over to the implementation materials?

Share this post


Link to post
Share on other sites

Also this TickSize feature could have not only pros but some cons as well, like increased complexity while handling price for placing orders in bots which e.g. could lead to possibility that some bot could fail to realize that TickSize is set to some value and expecting some specific order price, but not getting this desired price (or seeing that it failed to outbid) resubmit this order thus getting stuck in a cycle.

Share this post


Link to post
Share on other sites
2 minutes ago, culminator said:

Also this TickSize feature could have not only pros but some cons as well, like increased complexity while handling price for placing orders in bots which e.g. could lead to possibility that some bot could fail to realize that TickSize is set to some value and expecting some specific order price, but not getting this desired price (or seeing that it failed to outbid) resubmit this order thus getting stuck in a cycle.

This argument fails to convince me...

Share this post


Link to post
Share on other sites
2 hours ago, KarmaCoverage said:

@mDuo13 Unless there has been new stuff published in the last 6 months, I believe that I have reviewed all the material on Quality (in/out) but something is still not quite concrete in my mind.

This is an important concept/topic, so is it possible for you guys to put up some material focused specifically on Quality, and the thinking about why it is an important metric and aspect of a TX, and then link over to the implementation materials?

There hasn't been anything published on this recently. (I've been too busy on ILP-related stuff to do much more than tread water on new RCL featuers, not getting to the backlog of complicated RCL concepts that have been around a while.) But one thing that might help you with the understanding is that there are two things called "quality" in the RCL:

  1. Offer quality is basically just the rate of exchange, used to rank orders for the same currency pair. It's literally just TakerPays divided by TakerGets. This is what tick size limits.
  2. Trust line quality, aka "quality in/out", lets you personally value issuances at more or less than face value, which is mostly useful if you allow rippling, but the math on it gets confusing very quickly. There's not much client support for trust line quality (Ripple Trade never supported it) and the documentation for it sucks because I still can't keep them straight in my head no matter how many times I ask @JoelKatz to refresh my memory.

In all likelihood, the docs for trust line quality will continue to be extremely low on the priority list because trust line quality is kind of a perfect storm of unimportant: it relates to issued currencies and rippling, both of which we think are less and less important in the post-ILP RCL, and it's not widely used or understood so there's no demand for it.

Share this post


Link to post
Share on other sites
3 hours ago, mDuo13 said:

Offer quality is basically just the rate of exchange, used to rank orders for the same currency pair. It's literally just TakerPays divided by TakerGets. This is what tick size limits.

Great! What are the tie breakers?

Share this post


Link to post
Share on other sites
20 minutes ago, RafOlP said:

Great! What are the tie breakers?

Tie breakers for what? The order book is sorted by quality first, and by execution order second, so orders at better quality are placed ahead of orders of worse quality, and orders of the same quality get sorted so that earlier offers come before later offers.

Given two offers, A and B, at the same quality for the same currency pair, then WLOG,  let A get executed first in some validated ledger; this means that B will be executed after it. If both offers are added on the book, then A will be placed "higher" up in the book, so that it will execute first.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×