# Proposal
### Overview
Hummingbot is a strategy, order management, data aggregate and execution framework built for market making on Centralized and Decentralized platforms. It was originally developed as an in-house tool and has expanded to become an open source tool supporting many strategies and integrations. As such its implementation is diverse in its undertakings with much functionality unknown to those wishing to contribute or integrate. We propose developing a formal specification of the system that is Hummingbot and with that develop a formal specification outlining specifically the connectors interface, a stub connector with detailed explanation of functionality (as well as when, where and how its called), a dummy connector for example with implementation, and finally testing. This should showcase how and what people should be thinking about when implementing (vs a copy of something that is another's implementation).

We propose this to take 30 working days and a $21,375 commitment. We can expand scope beyond this to document the gateway and specifically DEX connectors, however we would imagine that having an initial scope of the core Python framework best.
The breakdown in cost and time, roughly, are as follows:
- Specification - 10 days $11,233
- Stub Connectors - 7 days $4,052
- Dummy Connectors - 7 days $3,050
- Test Cases - 6 days $3,040
### Background
When working with Hummingbot there are many functionalities which aren't apparent when constructing an integration. These nuances can make it challenging to debug or even understand what is happening when and where, when building a connector. As a new developer having some understanding of the flow and the key aspects of what needs to be adapted for given the nuances of the 3rd party implementation, would accelerate the ability for development. That and leveraging Hummingbot to its fullest, if it handles something, let it handle it. Some key areas of challenge are:
- Exception / Error handling
- Indeterminate functions for override
- Opinionated vs unopinionated functionality
- Undeterminate return values

Working off of example connectors, the details of implementation can be sparse, why one exchange needs to handle retries vs another, or why fetching all data even when only one request is necessary can be complicated to decipher.
### Implementation
This proposal would undertake the following to produce the desired result. This would be d one for exchange and derivative connectors, in the primary Python library.

**Specification** - We would formally spec out the connector and it's interactions with the base system. While not the entire base system would be included in the spec, there exists an opportunity to increase scope. For example the spec would include:
- Connector
- Exchange
- Derivative
- Order Book Tracker
- In Flight Orders
- Event Handler (Trade / Order Update)
- Order Life Cycle

**Sub Connector** - To supplement this specification, we would construct a stub connector outlining the function and details required to implement it, common error handling techniques.

**Dummy Connector** - Unlike the stub connector, this would implement data structure and response handling for people to be able to understand what is going on while referencing the stub.

**Testing** - The target would be if you follow the spec, stub and dummy connector, there would be a base which should cover at least 90% of core code when constructing an exchange connector.
### Risks
This is a large task which may take time with the team and original developers to accurately spec and ensure correct functioning is well documented. The result is ambiguous in that many different protocols and exchanges handle this information drastically different, such it may be untenable to execute a generic interface and would require more examples.
### References
https://hummingbot.com/