Alpaca Adapter - Questions for implementation

[SeverinJB]

Hi everybody,

I am currently working on implementing an adapter for Alpaca. I have made good progress by mimicking how the FTX adapter works. However, I'd appreciate your help with the points below.

1. generate_order_status_reports and reconciliation
   I am currently missing an understanding of what generate_order_status_reports should return (i.e. pre-select) to ensure an accurate reconciliation.
   Currently, my generate_order_status_reports function returns List[OrderStatusReport], whereby the list contains a maximum of 50 orders (Alpaca limit). However, when the list is used for reconciliation, I run into an issue if the list of order status reports does not contain all historical orders for a given instrument.
   For instance, if my orders for AAPL were 5, -5 and 10 and my list of order status reports contains only the orders -5 and 10 (due to the limit of 50 orders per call), the reconciliation will falsely calculate a position of 5. I could work around the Alpaca limit of 50 orders. However, it doesn't seem efficient to return all the orders ever made to ensure correct reconciliation.
   Could you clarify what is the best approach here?

2. Default max # of reports returned by generate_X_reports functions
   Related to the above, I wonder if there is a default max for the number of reports expected as return for report functions. For instance, if start=None and end=None, should the functions return all historical reports or is there a default cap (e.g. 100)?

3. generate_order_filled - commission value for commission free brokers
   The generate_order_filled correctly requires a value for the commission. Is it a convention to set the commission to Money(0, currency of instrument) for commission-free brokers?

4. Known shortcomings with FTX adapter
   Is there anything I should keep in mind when mimicking the FTX adapter? In other words, are you aware of any known shortcomings that the FTX adapter has and what shouldn't be adopted?

Thank you for any help that you can provide. Please let me know if you have any other tips as well!

Best,
Severin

[cjdsellers]

Hi @SeverinJB

1- If Alpaca have a limit of 50 per request, then you could make requests until you have received all order status? then continue

2- Its expected that as many order status reports will be generated as is necessary to accurately form the state of the system

3- Yes, that would be the convention because it looks like commission Money can't be None for the OrderFilled event

4- Good question, their trigger order API is extremely obtuse and hard to work with, we still haven't developed a complete solution for dealing with it. I don't think this would be an issue when working with Alpaca though. Also, refer to the Binance adapters and the use of msgspec for better typing of HTTP responses and WebSocket messages. The intention is that we'll move in this direction for FTX also

[SeverinJB]

Thank you, @cjdsellers! This was very clear and put me on the right path.

[drew2323]

@SeverinJB HI, is there any update on alpaca adapter?

[SeverinJB]

Hi @drew2323,

Good question!

I got various pieces done but didn't have the time to finish, polish and test it due to a new project at work. However, I have recently implemented changes so that it should be working with 1.166.0. I have yet to test if the last three releases contain any breaking changes which would affect the adapter. That said, I dumbed the current state of the code in the repository nautilus_alpaca_adapter for you.

If I am not mistaken, the current version of the code should not be using any libraries which aren't used by Nautilus anyway. Thus, it should be enough to install Nautilus in the environment. Afterwards, you can enter your Alpaca secret and key in the file minimal_example_adapter.py and run the same file to see it working.

I would of course appreciate it if you share any improvements, tests, or reports of any bugs which you might encounter.

Cheers,
Sev