Add an amendment to allow gateways to set a "tick size"
for assets they issue. There are no changes unless the
amendment is enabled (since the tick size option cannot
be set).
With the amendment enabled:
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.
For asset pairs with XRP, the tick size imposed, if any,
is the tick size of the issuer of the non-XRP asset. For
asset pairs without XRP, the tick size imposed, if any,
is the smaller of the two issuer's configured tick sizes.
The tick size is imposed by rounding the offer quality
down to nearest tick and recomputing the non-critical
side of the offer. For a buy, the amount offered is
rounded down. For a sell, the amount charged is rounded up.
Gateways must enable a TickSize on their account for this
feature to benefit them.
The primary expected benefit is the elimination of bots
fighting over the tip of the order book. This means:
- Quicker price discovery as outpricing someone by a
microscopic amount is made impossible. Currently
bots can spend hours outbidding each other with no
significant price movement.
- A reduction in offer creation and cancellation spam.
- More offers left on the books as priority means
something when you can't outbid by a microscopic amount.
* Force jtx to request/receive the 2.0 API
* Force the JSON and WebSocket tests to use 2.0 API
* This specifically allows the Websocket to create 2.0 json/ripple
and get back a 2.0 response.
* Add test for malformed json2
* Add check for parse failure
* Add check for params to be in array form.
* Correct type-o discovered in tests due to stricter checking.
* Add API version to the WSClient & JSONRPCClient test
* Update source.dox with more headers
Migrate tests in offer-test.js to cpp/jtx. Minimally reformat existing
test code. Augment self-cross test to include partner account as well as bridged and
direct crossing.
