horizon
horizon copied to clipboard
stellar-deprecated
Return for /order_book is inconsistent
For example: https://www.stellar.org/laboratory/#explorer?resource=order_book&endpoint=details&values=eyJidXlpbmdfYXNzZXQiOnsidHlwZSI6ImNyZWRpdF9hbHBoYW51bTQiLCJpc3N1ZXIiOiJHQlVZVUFJNzVYWFdEWkVLTFk2NkNGWUtRUEVUNUpSNEVFTlhaQlVaM1lYWjdEUzU2WjRPS09GVSIsImNvZGUiOiJGVU5UIn0sInNlbGxpbmdfYXNzZXQiOnsidHlwZSI6Im5hdGl2ZSJ9fQ%3D%3D&network=test
Amounts for one side are in XLM and amounts for the other are in FUNT.
Also I think prices are inverted. Price should be amount of selling asset needed to buy one unit of buying asset. For example if you are buying bread it costs $3 not .33 bread.
also: Purely semantics but if the order book API asked for an "asset" and a "base" then it would be clearer to me that when asset=USD and base=ZAR then I want both sides of the order book for USD in terms of ZAR
Most in slack agree with changing the 'amount' field of bids to be in the base asset (currently they are in counter, as that is what each bid is selling and what is being pulled from the DB). The prices are OK since we are displaying the 'base' and 'counter' assets in the response. Selling=USD and Buying=AUD turns into the USD/AUD orderbook, and prices displayed as AUD per USD, which is what you'd expect from a forex currency pair (i.e. the amount of AUD I get if I sell 1 USD).
I would rather invert the price on the bids (leave asks), which would leave it as a 'sell' price. To me this represents the intent of the bidder more clearly, but either method would be better than the current.
Additionally, something that may help to self-document is to change amount to 'base_asset-amount' & 'counter_asset_amount' or something along those lines.
Can confirm. I spent about 15 hours of fumbling around and writing scripts before I was 100% confident that I got the prices correct. I believe that Horizon and js-stellar-sdk have some things flipped (I have notes).
I think it's really hard to get things flipped right without a good reference point.
What I have found to work best for me is to frame things in the perspective of base and counter currency. Once things are in base and counter, then the prices for orderbook is unambiguous.
As for offers for accounts (which don't have reference to the orderbook base/counter), what sean suggested (showing two amounts each relative to base) would be very useful. Right now, in my client, I have code specifically for rectifying a client, and it can get confusing.
@jedmccaleb can you give me another example order book to work from so we're on the same page? I'll work on a test scenario but I'd love to have some illustrative real world data
