Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[10 mBTC Bounty] General metadata improvements #1544
I've just tried executing a trade on the BTC/LTC market on hitbtc which failed with the message 'Rounding necessary'. Now it seems that LTC and BTC are represented on the 8 exchange with 8 decimal places, as is the price on the BTC/LTC exchange. However, the quantity that is tradable on that market is rounded to just 1 decimal place. Is there a common place in this API (like the .json metadata files) to specify that value?
I was thinking something like:
I'm quite new to this project, so my ideas might not be quite thought out enough yet...
It feels like in order to trade on any exchange, each needs some common metadata. Specifically, so far I've come across:
currency scale - for use when getting your wallet data
And I think these should be present in the exchange metadata for all exchanges.
fees - these vary from exchange to exchange. Some have taker v's maker fees, some have none at all (coin floor for example). They are usually expressed as a percentage of trade size. But some exchange have more complex models, with discounts for example. Some have funding fees, as well as trade fees. And sometimes fees vary based on what's being traded (as well as the trade size).
I think maybe the fees are a bit trickier to model and perhaps should be removed from the static data al together?
I would be very useful if all trades returned by
In addition, we also may have:
rate limits - to prevent a client spamming the exchange with requests. I think these are typically easy to model and probably belong in the static data.
I've discovered that each sub-module has a
I wonder if the static data, which seems to change quite frequently might be best kept in a separate repository? That way they could be updated frequently by this community and users would have to wait for a release.
Just some thoughts... feel free to ignore me :)
Yes a separate repo with the json files in sounds like a good idea. As they are loaded from the classpath it shouldn't require any changes other than moving the files around in git and adding a mvn module.
Maker/taker fees could be done by splitting
Deposit/withdraw fees are on the currency rather than the currencypair and are usually a fixed amount (e.g. 0.0001 BTC). Maybe for some currencies there's a percentage-based fee too but I can't remember seeing one other than for fiat... which gets quite complex with different payment providers (OKPay etc.) and so might be easier to leave out at least initially.
Public and private rate limits are I think already modelled fully in
I don't know what any of the 'scaling' values mean or are/should be used for, please could I have a quick description? :-)
WRT the fees modelling...
I agree that funding (deposit and withdrawal fees) are probably best ignored by this project, at least for now.
And I think to model the fees better then separating taker from maker would be a good step forward. In addition I think we need per currency-pair fees as some exchanges have different fees in different markets.
And... the fees are sometimes issued in the base currency, and sometimes the counter currency. Sometimes the user can choose which (and it's a port of your account settings).
@molexx the 'scaling' parameters are really important. If you don't scale your values properly the exchanges will reject your api calls. The error messages will say something like "needs rounding" or "price too accurate". Basically if you send a value at the wrong precision the exchange will either round it or reject it - I think its common practice to reject it.
So we have
See section on metadata. I should probably add an easy-to-see link in the README.
Please contribute your changes, as that's the only way we can hope to keep things updated.
In all cases I've seen the dynamic data is used to supplement the static data. Where the dynamic data can be accessed it's considered to me more accurate than the static data and would override it, yes.
Maker, taker and tiered fees would be a great addition to the metadata as it would help inform bots/algos/people before placing an order. Additionally, I think in many cases the fees charged are given with the user trades, which can be used for book keeping. A breaking change is fine.
Those are there already.
Those are there already. mostly I suppose.
yes, complicated. But could be done.
Definitely could be added.