You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.
I just noticed (while working on it) that the withdraw method is not standardized. Normally, withdrawing crypto is quite a standard operation that every crypto exchange is offering (I've only noticed one exchange that doesn't implement this method: cex.io). So I think it would make a lot of sense to standardize this.
Every exchange needs some different parameters called differently, but it doesn't matter, in the end to withdraw crypto you just need these following details:
amount
currency
address (destination address)
address tag (optional, for ripple, stellar and I think also monero -payment id-)
So I'd use the 3 parameters as mandatory (should be enough for most of the exchanges) + address tag set to None by default, the rest (optional and additional exchange parameters) leave in the kwargs.
In the implementation the thing to do is to map these 4 parameters correctly in the kwargs or endpoint, depending on the exchange.
The reason for this, is that I don't see any advantage (in the actual implementation) in leaving everything in the kwargs, as like that the end user still needs to consult every exchange API documentation to see how these 4 parameters are called in their exchange.
Also, I'd implement a formatted response. Mostly for a withdrawal the response is the withdrawal ID.
While working on bitex, I noticed the same for other methods.
E.g. if you do your own accounting you may call those methods:
trade history
withdraw history
deposit history
Also this method is quite common:
deposit address (to get your wallet address on the exchange)
In the end I only see benefits in standardizing all these common methods. Also, while implementing a new exchange a dev must check the documentation anyway, so I don't think it's too much work to map some standardized parameters to the proper exchange specific variable name to be passed in the request (in most cases you just add it to the kwargs... easy).
What do you think?
The text was updated successfully, but these errors were encountered:
firepol
changed the title
Standardize also withdraw method?
Extend standardized methods (trade history, withdraw, withdraw history, deposit history, deposit address)
May 28, 2018
Hi,
I just noticed (while working on it) that the withdraw method is not standardized. Normally, withdrawing crypto is quite a standard operation that every crypto exchange is offering (I've only noticed one exchange that doesn't implement this method: cex.io). So I think it would make a lot of sense to standardize this.
Every exchange needs some different parameters called differently, but it doesn't matter, in the end to withdraw crypto you just need these following details:
So I'd use the 3 parameters as mandatory (should be enough for most of the exchanges) + address tag set to None by default, the rest (optional and additional exchange parameters) leave in the kwargs.
In the implementation the thing to do is to map these 4 parameters correctly in the kwargs or endpoint, depending on the exchange.
The reason for this, is that I don't see any advantage (in the actual implementation) in leaving everything in the kwargs, as like that the end user still needs to consult every exchange API documentation to see how these 4 parameters are called in their exchange.
Also, I'd implement a formatted response. Mostly for a withdrawal the response is the withdrawal ID.
While working on bitex, I noticed the same for other methods.
E.g. if you do your own accounting you may call those methods:
Also this method is quite common:
In the end I only see benefits in standardizing all these common methods. Also, while implementing a new exchange a dev must check the documentation anyway, so I don't think it's too much work to map some standardized parameters to the proper exchange specific variable name to be passed in the request (in most cases you just add it to the kwargs... easy).
What do you think?
The text was updated successfully, but these errors were encountered: