Purpose

To determine, as a way to reliably estimate the scope and resource estimates for developing a new connector for the Hummingbot Gateway repository:

1. The stability of the client DEX SDK.
2. The degree of compatibility with the exiting Hummingbot architecture.
   1. Hummingbot Gateway
   2. Hummingbot Client
   3. Hummingbot Strategies

Method

1. Review & Analysis of client SDK
   1. Clone SDK & Run
   2. Test basic CLI commands
   3. Test API & Review Swagger
2. Identify Potential Missing Functionalities
   1. Compare Gateway codebase to client SDK
   2. Compare Interfaces, Routes, & End-Points
   3. Locally Test Functions Required for Gateway (Requests/Responses)
3. Review client SDK Documentation
   1. Review Docs Relevant to Connector functionality
   2. Review Docs Relevant to Strategies functionality

Deliverable

<aside> ✅ A report which includes, but is not limited to:

• List of requests/responses and their feasibility. Please see next section.
• Is MS2a needed? Cannot be determined given the changes initiated by MOGA. The connector can be done either through Gateway or directly within the Client.
  • How likely (and how many) Hummingbot Client changes are needed? Some Client changes are always needed, but numerous and/or technically complex features, such as custom commands, are the primary factor in whether such changes become a milestone. Until the new post-MOGA DEX is completed, there is no basis to provide an accurate decision whether MS2a is needed or not.
• Is MS2b needed?
  • How likely is it that a custom strategy is needed? Hummingbot provides basic strategies for many types of DEXs, so the approach will depend entirely on how Onomy proceeds with its new DEX. A custom strategy might be desirable, requiring engagement with the Onomy community.
  • If a custom strategy is needed, what are parameters and reasons? The extent to which the DEX proposed by MOGA diverges from a standard Cosmos SDK-based DEX—such as through unique or experimental features, or deviations from ecosystem norms—will directly impact development needs.
• How compatible is the client SDK with existing connectors? Due to the changes initiated by MOGA, the research here was made largely exploratory, as ONEX is being deprecated. However, during the research, the ONEX-related repositories were considerably out-of-date and none of the relevant tests could be performed. See further details in the sections below.
  • How will this impact development needed for connector project? Development of a connector will be impossible until the MOGA roadmap is fully implemented and the new DEX reaches a stable release. A re-review can occur once the DEX is functional.
• Does a new Chain need to be added to Gateway? This can be revisited at the time of development, as the connector can be implemented in either the Gateway or the Client. Changes to the Hummingbot repository, along with the ongoing development of the Onomy DEX, may influence which option is best suited for both Onomy and Hummingbot. </aside>

List of requests/responses and their feasibility:

None of the repositories explored were developed to the point of usability. While focusing on onomyprotocol/onex, onomyprotocol/onomy-sdk, and the onomyprotocol/documentation repositories, we went so far as to clone and attempt to run each (if they contained runnable code).

onomyprotocol/onex specifically has zero endpoints completed, as noted directly in their readme.

This implies that the primary functionality of the project is the ability to use Onomy itself to generate new layer-2 chains onto the Onex testnet chain. Thus, all request/responses will be need to be completed with Onex before Onex could be used via chain/connector with Hummingbot.

Note, there is another repository, onomyprotocol/Onex-Rebuild, but it seems to simply be a blockchain made with a newer version of Ignite (formerly Starport) and lacks most of the non-cosmos-sdk commits that were present on onomyprotocol/onex itself.