XChange
XChange copied to clipboard
knowm
Support for Futures markets
Currently the central key point of the XChange API is the CurrencyPair, which is passed as parameter for almost all methods. This works fine so far for spot markets. But if we want to support futures markets the CurrencyPair is not enough, for example see Deribit Instruments, there we have three "products" with the same pair BTC/USD.
To support this we would need to replace the CurrencyPair by Product class, which could look like this:
public class Product {
private String base;
private String counter;
private String symbol; // this can be null, ie for spot products
private ProductType productType;
}
public enum ProductType {
spot, perpetual, future;
}
To stay with the deribit example, we would have three instances for products:
{base: BTC, counter: USD, symbol: BTC-27SEP19, productType: future}
{base: BTC, counter: USD, symbol: BTC-27DEC19, productType: future}
{base: BTC, counter: USD, symbol: BTC-PERPETUAL, productType: perpetual}
So like already said, inside the interface methods we could replace the CurrencyPair by Product (or Instrument or what ever name). The old methods could actually stay for a while and be marked as deprecated. This way we would be still compatible with older versions.
if the majority thinks it could make sense, i will create a PR
I like the idea. Maybe we can add options support also. They just need expiration date field and strike price i believe.We can create a second constructor for option support. What do you thing?
futures also have expiration date, i do not mind to add an optional Date field, which would be null for 'spot' and 'perpetual' products
Great.
On Tue, 13 Aug 2019, 11:40 André Reiter, [email protected] wrote:
futures also have expiration date, i do not mind to add an optional Date field, which would be null for 'spot' and 'perpetual' products
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/knowm/XChange/issues/3171?email_source=notifications&email_token=AHIWQ7YH5XMMRK7CMZLGXCDQEJXPFA5CNFSM4ILH5FDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4E63VQ#issuecomment-520744406, or mute the thread https://github.com/notifications/unsubscribe-auth/AHIWQ747P7NWYHQWS2AD7YDQEJXPFANCNFSM4ILH5FDA .
@andre77 wondered if you had any thoughts on the product PR idea, just I was going to look at implementing TFX which would need a simliar solution, I was going to approach it a bit different but may be your way is better.
https://github.com/knowm/XChange/issues/3258
Maybe we can add options support also. They just need expiration date field and strike price i believe.We can create a second constructor for option support.
Vanilla options can be covered this way, but any Complex option will need more (for instance, is it American, European or Asian style (multiple expiry dates)), and there are Binary options etc... It may be better to add a hashMap to the Product to support all the permutations than can be populated from ExchangeMetaData (local or downloaded).
I am not sure we want to build a normalized product database here, but allowing products to have un-restricted properties would be a great halfway house.
see Month Codes, for instance Z for December might be useful for sorting. These codes refer to the 3rd Friday in the month, but I see from the data above BTC-27DEC19 and that is the 4th Friday, expiry date needs to be kept.
https://www.cmegroup.com/education/courses/introduction-to-futures/understanding-contract-trading-codes.html
how about we introduce an abstract instrument class, which the existing Currency pair extends, then each exchange implentation can extend the instrument class as they needed for any particular exchange implentation weather that be using month codes, strikes, option types, expiration date. just think this would reduce the amount of refactoring.
@andre77 @makarid @timmolter @walec51 looking at this a bit more may be abstract classes say 'Instrument' with two concrete classes of 'CurrencyPair' and 'Contract' might create more hassle in the JSON serialisers that using concrete classes. To avoid a large refactoring what are the thoughts of creating a 'Contract' class that extends 'CurrencyPair'. This approach implicitly assumes any derivative/contract would be FX style with a base and quote currency?
I would avoid extending CurrencyPair, and wrap it instead. Because some contract will be defined by multiple CurrencyPair objects.
Sure, so may be I will take @andre77 original suggestion and introduce a new concrete class say called 'instrument' that wraps currency pair and update all the interfaces to use new instrument class.
Sure, so may be I will take @andre77 original suggestion and introduce a new concrete class say called 'instrument' that wraps currency pair and update all the interfaces to use new instrument class.
We could first create a new interface Future.class and sub divide it to FutureAccountService,FutureTradingService,FutureMarketDataService and implement these to the exchanges that support futures. That way we could create the Instrument.class and only add it the methods of these interfaces. That way we don't need to modify the existing classes. What do you think?
'Instrument' with two concrete classes of 'CurrencyPair' and 'Contract' might create more hassle in the JSON serialisers that using concrete classes
Jackson can handle far more complex class hierarchies then this - you just have to know how to configure it via annotations - this is not a problem
FutureAccountService,FutureTradingService,FutureMarketDataService
would those interfaces be any different from the normal interfaces other then from the fact that they accept Future instead of CurrencyPair?
what future specific methods would there be in a FutureAccountService?
what future specific methods would there be in a FutureMarketDataService?
do exchanges expose totally different APIs for futures?
do exchanges expose totally different APIs for futures?
Yes, frequently (and they often replicate the spot API which changes for Futures) for instance https://support.kraken.com/hc/en-us/categories/360001806372-Futures-API
Also, they can use different endpoints
what future specific methods would there be in a FutureAccountService?
what future specific methods would there be in a FutureMarketDataService?
I don't know the exact methods yet. We could add them when we will try to implement at least one Future exchange in order to see what we will need. I was just posting about an idea of how we could solve the issue of adding Future support but without break things from the spot market exchanges. Definitely we would need at least the following methods which there aren't in existing Xchange implementation(we can change the names of course):
getOpenPositions getCurrentMarginUsed
Where would leverage go? on the trade and position rather than the Instrument? Maybe on the instrument to if leverage is fixed for that symbol.
Also, how to handle generic futures (March,June,September,December) vs dated contracts expiry (2020-03-27)? Send in a trade for March-2020 get back executions for 2020-03-27?
Where would leverage go? on the trade and position rather than the Instrument? Maybe on the instrument to if leverage is fixed for that symbol.
Also, how to handle generic futures (March,June,September,December) vs dated contracts expiry (2020-03-27)? Send in a trade for March-2020 get back executions for 2020-03-27?
There are 2 types of leverage. The instrument leverage(maximum leverage supported) and the openPosition leverage that is a real-time metric in order to see how much leverage your position is using.
I didn't understand the second question
The question that i would like to ask. Do we need to create a Position.class that extends Order.class or it is better to not extend Order.class? I am asking this because a Position is very different than an Order. A position's metrics(margin,value) changing overtime but this is not true with an Order. Also, i believe that we should make this issue top priority because it opens the "world" for more exchange implementations which are not possible right now. What do you think?
So, as i see it right now:
FutureAccountService.interface : contains { getAccountUsedLeverage() } FutureTradingService.interface : contains { getOpenPositions(), getOpenPositions(CurrencyPair currencyPair, getFundingHistory(CurrencyPair currencyPair} Also we need to add an OpenPosition.class.
What do you think? I will start the implementation when we all agreed on something.
I would not recommend extending the Order Class, I think it has already been overused (Trades and OrderBook) and the LimitOrder MarketOrder, StopOrder structure is not ideal.
There are so many ways this could be done, which makes it hard to decide. We could add new DTOs, Services and methods. We could add new DTOs and methods to existing services. We could add new and/or extended DTOs to existing Services and existing methods.
I always tried to lean towards making it easy for the end user (a programmer using the library, not the developers of the library) to understand the API so if we continue with this goal in mind, adding new DTOs and methods would make the most sense. Otherwise newbies will have to deal with complex "wrapper" classes for method arguments and return values. If someone comes and just want to place a limit order for a plain old "spot", they can easily find it by searching the methods and it is relatively easy then to understand what arguments are required and what is returned. As a compromise we could forgo adding new service classes but add more methods within the existing ones. By default the new methods will just throw a NotImplementedYetException as it always has worked.
I think this would warrant a version bump to 4.5.0.
As far as extending Order or CurrencyPair or not I'd say yes if there is significant overlap of class members, but I'd say no if the members were completely or mostly orthogonal. Just take it by a case to case basis.
@mdvx If you think extending the Order class is not ideal, in which way do you think things could be improved?
Thank you @timmolter for your input.Indeed, you propose the simplest and easier solution.Much better, in my opinion. So, i will just add new DTOs and new methods to existing services.
Here are some different concepts for Order class...
-
Order -> OrderRequest The Order class does not allow for enough parameters, flags was added to extend the functionality, but things like GTD need fields. A MyExchangeOrder class can be created, but a lot of these are common across exchanges, and it would need to be applied to LimitOrder and StopOrder too. An interface for GTD might be a solution. Another possibility is to add a Map to the base Order object for extra the fields, then GTD could go in the map. GTD is just one such field, others might include LocateReqd flag, SettlCurrency, QuoteID, SettlType
-
Order -> OrderState of private Trade We are missing an error status here for rejected Orders, whereas this is not required when placing synchronous REST calls, asynchronous calls need a place to report this. REST are generally synchronous, but there is no reason an exchange would not reject an order further down its processing pipeline, maybe even after it is partially executed (risk limit hit after price moves)
-
Order -> public Trade This assumes a fully executed order, sometimes with maker and taker ids.
-
LimitOrder -> OrderBookEntry Problem here is the orderbook can combine many Orders for a single Entry (n<-1)
-
Order -> Position Well I thinks that is a lot to ask from one class
My tuppence.
With regards to extending the currency pair, I thought it might make sense as some derivatives will have a base/quote and a prompt month such as BTC.USD.PERPETUAL, even FTX's BTC-MOVE-1116 is really BTC.USD volatility plus a prompt, (i.e BTC.USD.MOVE.1116) so it has an additional symbol MOVE, where other derivatives such as TRUMP-2020 https://ftx.com/trade/TRUMP or SHIT-PERP don't have an underlying currency pair. So may be it makes more sense to have a new type instryment that has an underlying that can be anything, most cases it will be an CurrencyPair but could be something else like TRUMP or SHIT (shitcoin index)
On Wed, Mar 4, 2020 at 4:41 PM Tim Molter [email protected] wrote:
There are so many ways this could be done, which makes it hard to decide. We could add new DTOs, Services and methods. We could add new DTOs and methods to existing services. We could add new and/or extended DTOs to existing Services and existing methods.
I always tried to lean towards making it easy for the end user (a programmer using the library, not the developers of the library) to understand the API so if we continue with this goal in mind, adding new DTOs and methods would make the most sense. Otherwise newbies will have to deal with complex "wrapper" classes for method arguments and return values. If someone comes and just want to place a limit order for a plain old "spot", they can easily find it by searching the methods and it is relatively easy then to understand what arguments are required and what is returned. As a compromise we could forgo adding new service classes but add more methods within the existing ones. By default the new methods will just throw a NotImplementedYetException as it always has worked.
I think this would warrant a version bump to 4.5.0.
As far as extending Order or CurrencyPair or not I'd say yes if there is significant overlap of class members, but I'd say no if the members were completely or mostly orthogonal. Just take it by a case to case basis.
@mdvx https://github.com/mdvx If you think extending the Order class is not ideal, in which way do you think things could be improved?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/knowm/XChange/issues/3171?email_source=notifications&email_token=ABBUO2RV7AFUFG6IMQ74DGTRF2AD5A5CNFSM4ILH5FDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENY2QSY#issuecomment-594651211, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBUO2TGV5ZI2GTNCUJG45DRF2AD5ANCNFSM4ILH5FDA .
Here are the 4 near (+1 prior) month CME contracts BTC.G20 | Feb 2020 | 8825 | 8905 | 8430 | 8890 | -85 | -0.98% | 10:33 BTC.H20 | Mar 2020 | 8830 | 8910 | 8700 | 8775 | -25 | -0.28% | 17:28 BTC.J20 | Apr 2020 | 8940 | 8970 | 8795 | 8840 | -30 | -0.33% | 17:28 BTC.K20 | May 2020 | 9030 | 9070 | 8970 | 8970 | -20 | -0.22% | 17:28 BTC.M20 | Jun 2020 | 9150 | 9215 | 9035 | 9075 | -55 | -0.60% | 17:28
But we also have contracts on the spreads between two futures (J,K, are six week codes) BTC.G20:H20 | Feb 2020/Mar 2020 Spread | 41 | 80 | 41 | 77 | +35 | +51.47% | 10:33 BTC.H20:J20 | Mar 2020/Apr 2020 Spread | 85 | 90 | 80 | 80 | -12 | -17.65% | 17:28 BTC.H20:K20 | Mar 2020/May 2020 Spread | 201 | 201 | 190 | 190 | -12 | -5.97% | 17:28 BTC.H20:M20 | Mar 2020/Jun 2020 Spread | 314 | 314 | 300 | 300 | -25 | -7.96% | 17:28 BTC.J20:K20 | Apr 2020/May 2020 Spread | 103 | 111 | 101 | 108 | +2 | +1.82% | 17:28 BTC.J20:M20 | Apr 2020/Jun 2020 Spread | 199 | 252 | 199 | 225 | +55 | +27.64% | 17:28 BTC.K20:M20 | May 2020/Jun 2020 Spread | 103 | 105 | 103 | 105 | -14 | -13.59% | 17:28
https://quotes.ino.com/exchanges/contracts.html?r=CME_BTC
here is one with 3 currencies Litecoin (BITCOIN:LTCUSD)
https://quotes.ino.com/exchanges/category.html?c=cryptocurrencies