ccxt: Min_Size inconsistencies
MUST READ THIS BEFORE SUBMITTING ISSUES (read the links, then delete this message before submitting):
- https://github.com/ccxt/ccxt/wiki/FAQ
- https://github.com/ccxt/ccxt/blob/master/CONTRIBUTING.md#how-to-submit-an-issue
Make sure your local version of CCXT is up to date. Check by comparing the output of ccxt.version to https://github.com/ccxt/ccxt/blob/master/package.json#L3
- OS:
- Programming Language version:
- CCXT version:
handler = ccxt.ftx(keys)
handler.create_limit_buy_order('BTC-PERP', 0.00048, 60000, {"postOnly": True, 'reduceOnly' : True})
returns {"success":false,"error":"Size too small for provide"}
The minimum size on FTX is 0.0001 btc for BTC-PERP
It happens to me on many pairs…
How could I work around this limitation?
Thanks!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 16 (8 by maintainers)
Commits related to this issue
- ftx revert minProvideSize #10503 — committed to ccxt/ccxt by kroitor 3 years ago
I believe this would seem to be the case, not just with ftx, but many exchanges. The only rationale that I can see in terms of the differences that I have actually seen through testing, is that the API has a slower channel of communication compared to what the application may use as a direct channel. I personally believe it is not something out of the ordinary that they would prioritize Communications with their own applications over third party API requests.
This type of practice is common within the market and does help promote usage of the application.
I believe a clear visual example of this is the Kraken app versus the Kraken API. The API has some very strong rate limits on it, whereas the app does not.
I have run to this a few times with finance where the API and their website differ on values.
With respect to FTX, in using their application I have gotten different values for testing than what their API reports. My experience has been that the API reports slightly higher than what the actual application wants. My guess is this is probably some sort of a defensive hedge against a rapid market slips since the variance between what the API reports any application is extremely minimal.