CLMM network identifier mismatch (short name vs chain-network)

[VeXHarbinger]

Describe the bug

Summary

While I've been working with my re-mapping of the PancakeSwap CLMM endpoints I went in circles until I noticed that there is an issue in the Gateway CLMM flow where client code and the Gateway/connector disagree about the expected format for the network/network id parameter. Some clients send a short network name (for example bsc) while connectors or internal routing expect a chain-network style identifier (for example bsc-mainnet). This mismatch leads to connector route resolution problems and unexpected 404 responses for CLMM endpoints such as clmm/quote-position. This allowed me to create a position in the pool and then could not find it when requesting it's data.

Why this matters

• Network id ambiguity leads to route 404s (e.g., connector clmm/quote-position missing) and inconsistencies between client and connector expectations.
• Automation and scripts that rely on deterministic Gateway routing fail when their network value doesn't match what the connector expects.

Concrete example (observed during testing)

When the autorun script submits a CLMM payload with "network": "bsc", Gateway responded with 404 for the clmm/quote-position route in some cases. Normalizing the network identifier to the expected chain-network format resolved route discovery in our environment.

Reproduction steps

1. Run Gateway (example in this repo: docker compose up -d).
2. Submit a CLMM payload using the short network name (e.g., network: bsc) to /connectors/pancakeswap/clmm/quote-position or via the client helper.
3. Observe a 404 or connector-route not found error. Then retry using network: bsc-mainnet (or the connector's expected id) and observe successful route resolution.

Expected behavior

• The Gateway REST schema and docs should clearly state whether connectors expect a short network id (e.g., bsc) or a chain-network id (e.g., bsc-mainnet).
• The client libraries and routers should validate and normalize the network parameter before calling connector routes so that either bsc or bsc-mainnet will work consistently.

Suggested fixes (minimal, high-impact)

1. Gateway client / router normalization

   • Add validation/normalization in services/gateway_client.py and in routers (e.g., routers/gateway_clmm.py) so that clients using network='bsc' or network='bsc-mainnet' will be normalized to the connector's expected format.
   • Update API docs and OpenAPI schema to document the exact expected network identifier format.

2. Tests and docs

   • Add a test that submits requests with both bsc and bsc-mainnet and asserts that the router resolves to the correct connector route.

Severity and impact

• Severity: Medium — causes convenience/automation failures (404s) but is straightforward to normalize and fix.
• Affects: Any client or automated script that supplies network in a format different from the connector expectation.

Suggested issue labels

• bug
• clmm
• gateway

Additional notes / references

• Gateway client call originates from services/gateway_client.py::clmm_open_position in the local repo.
• If you'd like, I can prepare a minimal patch that normalizes network values and add a test demonstrating both formats resolve to the same connector route.

Steps to reproduce

1. I'm working with a PancakeSwap CLMM on bsc when I noticed this behavior
2. Enable CLMM add/remove liquidity endpoints hummingbot-api#105 have the api side of the endpoints
3. I haven't completed the pr for gateway yet, once I do I can list exact steps. However, without the endpoints you'll just have to query the mapping to see the issue.

Release version

0

Type of installation

Docker

[fengtality]

I agree this is annoying, but the chain concept in Gateway is needed since there are other blockchain architectures that may be supported in the future. There's still some necessary integration work (esp with node providers and wallets) that's needed to better support Ethereum and Solana-based chains, but doing them in a chain-agnostic way will enable Gateway to support other chain architectures like Sui, Near, Starknet etc that are not EVM and SVM compatible.

The higher-level /trading/clmm routes in Gateway specify chain-network as the param, while the lower-level connector routes specify network since we assume that a connector belongs to a parent chain architecture.

[VeXHarbinger]

I agree this is annoying, ...

I agree with your agreement. My mindset is that when you see something, document it. As long as it's here someone else will know they aren't going crazy and one day will sic an AI on it to make it as dynamic/extendable as needed with route replacement for special cases