search

knowm / XChange

XChange is a Java library providing a streamlined API for interacting with 60+ Bitcoin and Altcoin exchanges providing a consistent interface for trading and accessing market data.
http://knowm.org/open-source/xchange/
MIT License
3.81k stars 1.93k forks source link

CexIO "Get my fee" api endpoint is not implemented #2289

Open Arshaku opened 6 years ago

Arshaku commented 6 years ago

CexIO private API has "Get my fee" ( https://cex.io/rest-api#get-my-fee ) endpoint which returns user's current trading fees. The endpoint is not implemented so there is no way to get user's current fees based on current trading volume.

brilliantnut commented 6 years ago

I was thinking about the same thing when I implemented the https://cex.io/rest-api#currency-limits endpoint for a CEX.io remoteInit() in this pull request.

Unfortunately, it seems like the remoteInit() is only called once during initial initialization, and not regularly. This means that if you're an active trader, then you might have to restart / refresh your Exchange objects at least on a daily basis, if not more.

The other problem is that Xchange does not correctly recognize the maker / taker fees differential. So the question would be whether you want the maker fee or the taker fee when you look up ExchangeMetadata. I'm personally in the favour of getting the taker fee (so your code is somewhat conservative), but the existing static metadata actually lists the default maker fee (so your code will be somewhat more aggressive if you take the fee into account when making your trades.

@timmolter any thoughts on separating the maker / taker fees in the CurrencyMetadata construct? Also, what are the recommended ways to refresh the remoteInit()?

Arshaku commented 6 years ago

@brilliantnut Thanks for the reply! Supporting the idea of introducing maker / taker fees in the unified interface, as seems most of exchanges have that separation in trading fees. But in the meanwhile I would suggest to still implement the "Get my fee" endpoint as a part of Raw service. If we can't use the unified interface to get those fees yet, at least we could get them by casting to Raw service of the exchange (as I'm currently getting the dynamic fees for my account for example from Kraken and Bitstamp using KrakenAccountServiceRaw and BitstampAccountService classes accordingly). Then when the unified interface is ready those implementations would be used for it. What do you think?

timmolter commented 6 years ago

@brilliantnut I agree that the metadata should be improved to allow differentiation between maker and taker fees. We should probably just add the two new fee types and leave the existing one.

I believe you can just call remoteinit() whenever you want, no? But why would you want to? Would the fees be changing often enough?

Arshaku commented 6 years ago

@timmolter for most of exchanges I have seen, the fees are not fixed (e.g. in Bitstamp, Kraken, CexIO, etc). They change depending on the trader's total volume of trades in 30 days moving window. So if you do more trading, fees decrease for you. and for example if the trader is approaching a new level of fees by doing lots of trading, it can go back and forth to the old and new level a lot depending on your volume in 30 days moving window. So yes, it can change often and makes sense to request the fee values periodically without a need to restart the application.

brilliantnut commented 6 years ago

But in the meanwhile I would suggest to still implement the "Get my fee" endpoint as a part of Raw service.

A good idea. This isn't high enough on my list (as I've actually overriden / hardcoded fees in my code), but I'll likely get around to it sometime in the next two weeks (unless someone else picks it up).

@brilliantnut I agree that the metadata should be improved to allow differentiation between maker and taker fees. We should probably just add the two new fee types and leave the existing one.

Yeah, that sounds like a plan - we could add default it to the trading_fee for implementations which don't recognize the difference.

I believe you can just call remoteinit() whenever you want, no?

Doh! I can't believe I didn't notice that remoteInit() was public! Even when I overrode this method last night, I kept considering it as implementation detail, and hence protected in my mind, so was wondering how we would refresh this information. You're right that we could just call it whenever we want, and it needs to be written in a fashion that it merges with the old metadata anyways, so shouldn't be an issue.

But why would you want to? Would the fees be changing often enough?

For CEX.io, fees are reset daily, based on your last 30 days trading volume in BTC. I'm sure similar rules apply in other exchanges having a volume based fee schedule. Now, it won't really matter so much to me right now, because my trading volume is somewhat stable (and low), but I'm sure it will matter to someone who does high volume of trades, with an aggressive strategy, so the 0.01% fee difference in different buckets might make a difference.

You really need to refresh your fee schedule in that case. But, it is likely something that could (and should) be handled by client applications (since remoteInit() is anyways public).

brilliantnut commented 6 years ago

@Arshaku See above pull request #2296 I implemented get_myfee in the Raw account service. Still haven't integrated into ExchangeMetaData, but would appreciate your views.