Enhancements/evm and uniswap-like_connectors #540

vic-en · 2025-10-28T22:04:58Z

Before submitting this PR, please make sure:

Your code builds clean without any errors or warnings
You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:

1. Slippage Parameter Inconsistency

Issue: Certain endpoints in the Swagger documentation have the slippage parameter, but the connector ignores them and uses the slippage specified in the config file instead
Recommendation: Either remove slippage from Swagger docs for endpoints that don't use it, or implement proper slippage parameter handling
Solution: implemented proper slippage parameter handling. Slippage from endpoint will always be used when provided, otherwise, slippage defaults to what's in the config for the connector being used.

2. Pool/Pair Address Derivation Inconsistency

Issue: Inconsistent approach to pool/pair address derivation across different endpoint types
- Router endpoints compute pool addresses dynamically
- AMM endpoints retrieve addresses from the pool config file
Recommendation: Standardize the approach - either compute addresses consistently or use config file consistently
Solution: WIP

3. sqrtPriceLimit Not Enforced in CLMM Swap

Issue: The sqrtPriceLimit parameter isn't enforced in CLMM swap operations - only the expected output amount is specified
Impact: Price protection mechanisms may not work as expected
Recommendation: Document this behavior or consider implementing proper price limit enforcement
Solution: implemented proper price limit enforcement. Price from the quoted trade is used as the price limit, that way, users won't be susceptible to MEV attacks

4. Transaction Receipt Waiting Pattern

Issue: Most endpoints still use tx.wait() for receipt and set status to 1 in responses
Recommendation: Consider making this configurable or documenting the behavior
Solution: Standardized tx execution handling in all etherum connectors and introduced configurable transactionExecutionTimeoutMs parameter in config for each evm chain.

Tests performed by the developer:
WIP

Tips for QA testing:

…d Uniswap connectors - Set default slippage percentage to be fetched from respective configuration files in addLiquidity, executeSwap, and quoteSwap functions. - Remove redundant slippage percentage checks and ensure consistent handling across all swap and liquidity functions. - Clean up unused imports and commented-out code in schemas and routes.

…ClmmSwap

- Removed the waitForTransactionWithTimeout utility function and replaced its usage with handleTransactionExecution across various routes and connectors. - Updated transaction confirmation logic to utilize the new handleExecuteQuoteTransactionConfirmation method in the 0x and Uniswap connectors. - Introduced transactionExecutionTimeoutMs configuration in chain templates for better timeout management. - Adjusted transaction status handling to ensure accurate reporting of transaction outcomes.

fengtality · 2025-10-28T23:17:13Z

thanks @vic-en. can you provide more details on this change (why it's needed, the solution implemented, etc):

Transaction Receipt Waiting Pattern
Issue: Most endpoints still use tx.wait() for receipt and set status to 1 in responses
Recommendation: Consider making this configurable or documenting the behavior
Solution: Standardized tx execution handling in all etherum connectors and introduced configurable transactionExecutionTimeoutMs parameter in config for each evm chain.

@rapcmia @nikspz This PR should be slated for the following release (v.2.11)

…ions

vic-en · 2025-10-28T23:46:28Z

thanks @vic-en. can you provide more details on this change (why it's needed, the solution implemented, etc):

Transaction Receipt Waiting Pattern
Issue: Most endpoints still use tx.wait() for receipt and set status to 1 in responses
Recommendation: Consider making this configurable or documenting the behavior
Solution: Standardized tx execution handling in all etherum connectors and introduced configurable transactionExecutionTimeoutMs parameter in config for each evm chain.

@rapcmia @nikspz This PR should be slated for the following release (v.2.11)

@fengtality
There were initially 3 approaches for getting tx receipts:

waitForTransactionWithTimeout waits for receipt using provided timeout or hardcoded one and used randomly
handleTransactionConfirmation factorized function used in the executeQuote endpoint in connectors
tx.wait used all over the codebase. This obviously isn't timed and was the original reason for this refactor

My solution:

Introduced configurable transactionExecutionTimeoutMs in all evm chains which will be the source of truth for how long each chain waits on a tx to be mined
handleTransactionExecution funtion is basically a replacement for waitForTransactionWithTimeout and all tx.wait but uses transactionExecutionTimeoutMs of the chain being used. Refactored all tx.wait and waitForTransactionWithTimeout to use it and also use the receipt status from the returned receipt. -1 is default status in handleTransactionExecution if it timeouts which implies the tx is pending or yet to be confirmed
Renamed handleTransactionConfirmation to handleExecuteQuoteTransactionConfirmation to make it less ambiguous

…ereum chain YAML files

…chema

vic-en · 2025-10-29T00:44:25Z

@fengtality For Pool/Pair Address Derivation Inconsistency, my plan is to replace findDefaultPool with getV3Pool, getV2Pool in clmm-routes and amm-routes respectively.
I'll add that I think it's ok to leave findDefaultPool as it's used now that I've had a second look since I worked on the Pancakeswap connector. However, let me know if you want me to proceed with my suggested changes.

fengtality

One change requested, but otherwise PGTM

fengtality · 2025-10-30T04:27:33Z

src/chains/ethereum/ethereum.ts

      return {
        signature: '',
-        status: 0, // PENDING
+        status: -1, // PENDING


Use -1 for failed and 0 for pending.

This is what Hummingbot expects:

class TransactionStatus(Enum): """Transaction status constants for gateway operations.""" CONFIRMED = 1 PENDING = 0 FAILED = -1

you can also just use -1 and never 0 since I don't think we're handling a pending state

I changed -1 to 0 and 0 to -1 to make it work with Hummingbot.

However, defaulting to -1 (i.e. FAILED) will cause issues on the client. Orders would be reported as failed and dropped from the in-flight tracker - https://github.com/hummingbot/hummingbot/blob/5f447fe56a777c84ab7a9e5e9879dc9e922b751b/hummingbot/connector/gateway/gateway_base.py#L591

please use 0 for pending and -1 for failed

@fengtality I think I did already

fengtality · 2025-10-31T04:20:56Z

I'll add that I think it's ok to leave findDefaultPool as it's used now that I've had a second look since I worked on the Pancakeswap connector. However, let me know if you want me to proceed with my suggested changes.\

Note that findDefaultPool is only needed for the quote-swap and execute-swap endpoints in the CLMM and AMM connectors since they allow user to enter baseToken and quoteToken if poolAddress isn't provided. This is b/c the swap endpoints are supported by the generalized swap routes.

However, for the liquidity routes, they should all have poolAddress (without tokens) in the param, so no call to findDefaultPool is needed.

Note that I'm working some improvements in #543. I'll ask QA to review both branches separately, and I'll handle any conflicts upon merge.

nikspz · 2025-11-07T14:42:28Z

commit 11a47f9

steps:

Clone PR540
- pnpm install && pnpm build

Actual:

Found 2 errors in the same file, starting at: src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:65
ELIFECYCLE Command failed with exit code 2.


> gateway@dev-2.11.0 prebuild /home/etozhe/gw540
> rimraf dist && mkdir dist


> gateway@dev-2.11.0 build /home/etozhe/gw540
> tsc --project tsconfig.build.json && tsc-alias -p tsconfig.build.json && pnpm run copy-files

src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:65:27 - error TS2304: Cannot find name 'utils'.

65     const baseAmountRaw = utils.parseUnits(
                             ~~~~~

src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:78:28 - error TS2304: Cannot find name 'utils'.

78     const quoteAmountRaw = utils.parseUnits(
                              ~~~~~


Found 2 errors in the same file, starting at: src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:65

 ELIFECYCLE  Command failed with exit code 2.

fengtality · 2025-11-07T15:04:51Z

@nikspz Here's the branch with the fix https://github.com/hummingbot/gateway/tree/enhancements/uniswap-like_connectors

nikspz · 2025-11-07T15:21:57Z

@nikspz Here's the branch with the fix https://github.com/hummingbot/gateway/tree/enhancements/uniswap-like_connectors

I got same error using enhancements/uniswap-like_connectors https://github.com/hummingbot/gateway.git

src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:65:27 - error TS2304: Cannot find name 'utils'.

65 const baseAmountRaw = utils.parseUnits(
~~~~~

src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:78:28 - error TS2304: Cannot find name 'utils'.

78 const quoteAmountRaw = utils.parseUnits(
~~~~~

Found 2 errors in the same file, starting at: src/connectors/pancakeswap/clmm-routes/addLiquidity.ts:65

nikspz · 2025-11-07T15:22:21Z

@vic-en could you please review

…d Uniswap connectors - Set default slippage percentage to be fetched from respective configuration files in addLiquidity, executeSwap, and quoteSwap functions. - Remove redundant slippage percentage checks and ensure consistent handling across all swap and liquidity functions. - Clean up unused imports and commented-out code in schemas and routes.

- Removed the waitForTransactionWithTimeout utility function and replaced its usage with handleTransactionExecution across various routes and connectors. - Updated transaction confirmation logic to utilize the new handleExecuteQuoteTransactionConfirmation method in the 0x and Uniswap connectors. - Introduced transactionExecutionTimeoutMs configuration in chain templates for better timeout management. - Adjusted transaction status handling to ensure accurate reporting of transaction outcomes.

vic-en · 2025-11-07T22:21:55Z

@nikspz It's updated now

nikspz · 2025-11-10T21:09:55Z

commit 7e697a2
- Test performed:
  - Cloned latest development + gw540
  - gateway connect ethereum / solana: ok ✅
  - gateway balance: ok
  - ethereum
    - uniswap/clmm
      - gateway swap uniswap/clmm: ok ✅
      - gateway lp uniswap/clmm add-liquidity: ok, added ✅
      - gateway lp uniswap/clmm remove-liquidity: removed ✅
      - POST /connectors/uniswap/clmm/open-position ✅
      - POST /connectors/uniswap/clmm/remove-liquidity ✅
    - uniswap/amm
      - gateway lp uniswap/amm add-liquidity: ok, added ✅
      - gateway lp uniswap/amm remove-liquidity: removed ✅
  - solana
    - GET /trading/swap/quote: ok ✅
    - POST /trading/swap/execute: ok ✅
      - https://solscan.io/tx/ECsLYw5vM89L6z1F1tMENgjBbM7XMvpySLZzkgth9UUS9K1y8qbfJZE1EX99pYdrZSei87Qp4oJ1p6dvWEZZszz
    - meteora/clmm
      - gateway lp meteora/clmm add-liquidity: added successfully ✅
      - gateway lp meteora/clmm remove-liquidity: removed successfully
    - pancake-sol/clmm
      - POST /connectors/pancakeswap-sol/clmm/open-position:
        
        Transaction 4wR9zfPcmyZRMzffdUtXjuwbH6T5DrQimDyq6qTPprzxQ4Urd1x5ULUdsyoh6tsqMcYRdrhN4bw4rfbtkQxokHM2 not confirmed after 30 attempts ❌
      - another attempt POST /connectors/pancakeswap-sol/clmm/open-position ❌ "slippagePct": 5
        
        { "statusCode": 400, "error": "Error", "message": "Position/Swap failed: Price slippage check failed. The calculated price from ticks does not match expected values. This can happen if: (1) price moved significantly since quote was calculated, (2) token amounts don't match the price range, or (3) tick spacing constraints are not met. Try: increasing slippage tolerance, adjusting token amounts to better match current price, or using a wider price range." }
      - added "slippagePct": 10
        
        executed ✅
        
        "lowerPrice": 160,
        "upperPrice": 172,
        "baseTokenAmount": 0.005,
        "quoteTokenAmount": 8.3,
      - gateway lp pancakeswap-sol/clmm remove-liquidity ❌
        
        03:25:17 - GatewayLp - Transaction monitoring timed out for order range-SOL-USDC-1762806191612274, transaction 4mZ21bAEW96gt2fXDxYYyB3XXEif6LqnhSabVistGWMdHcBc54eTtSXpayjMxcBQWULoYNqpErdVCu1bgvZWvkKJ
      - POST /connectors/pancakeswap-sol/clmm/remove-liquidity ❌
        
        not removed
      - removed manually

logs.zip

fengtality · 2025-11-10T22:54:19Z

@nikspz please test the fixes that Victor made in this PR. Pancakeswap-SOL is not related to his changes.

Especially #1 and #4 below:

Slippage Parameter Inconsistency
Issue: Certain endpoints in the Swagger documentation have the slippage parameter, but the connector ignores them and uses the slippage specified in the config file instead
Recommendation: Either remove slippage from Swagger docs for endpoints that don't use it, or implement proper slippage parameter handling
Solution: implemented proper slippage parameter handling. Slippage from endpoint will always be used when provided, otherwise, slippage defaults to what's in the config for the connector being used.

Pool/Pair Address Derivation Inconsistency
Issue: Inconsistent approach to pool/pair address derivation across different endpoint types
Router endpoints compute pool addresses dynamically
AMM endpoints retrieve addresses from the pool config file
Recommendation: Standardize the approach - either compute addresses consistently or use config file consistently
Solution: WIP
sqrtPriceLimit Not Enforced in CLMM Swap
Issue: The sqrtPriceLimit parameter isn't enforced in CLMM swap operations - only the expected output amount is specified
Impact: Price protection mechanisms may not work as expected
Recommendation: Document this behavior or consider implementing proper price limit enforcement
Solution: implemented proper price limit enforcement. Price from the quoted trade is used as the price limit, that way, users won't be susceptible to MEV attacks
Transaction Receipt Waiting Pattern
Issue: Most endpoints still use tx.wait() for receipt and set status to 1 in responses
Recommendation: Consider making this configurable or documenting the behavior
Solution: Standardized tx execution handling in all etherum connectors and introduced configurable transactionExecutionTimeoutMs parameter in config for each evm chain.

nikspz

Test performed:
- Pool/Pair Address Derivation Inconsistency: created tx successfully without using pool address and using pool address for uniswap/amm
  - uniswap/amm
    - POST /connectors/uniswap/amm/execute-swap with "poolAddress": "" empty field: ok ✅
    - POST /connectors/uniswap/amm/execute-swap using "poolAddress": "0x88A43bbDF9D098eEC7bCEda4e2494615dfD9bB9C”: ok ✅
      - https://basescan.org/tx/0x581a907641cd798236115da451d680a349671337f9c0504634cd24b60421513e
  - uniswap/router
    - POST /connectors/uniswap/router/execute-swap: ok ✅
      - https://basescan.org/tx/0xf72f72a2b977355563dbacd5d3f884ebcf4fb95fd892ccd2bd0695d9b7a9df35
- Slippage Parameter Handling
  - set connector config slippage config/uniswap.yml slippagePct: 2 ✅
  - GET /connectors/uniswap/amm/quote-swap
    - request’s slippage 5
    - - Response body - **`"slippagePct": 5`** ✅
    - request’s slippage Empty field
      - Response body
        
        "slippagePct": 2 (Default slippage) ✅
    - request’s slippage 1
      - Response body
        
        "slippagePct": 1 ✅
  - /connectors/uniswap/amm/swap
    - "slippagePct": 3: success ✅
      - Response: "slippagePct": 3
    - "slippagePct": null: success ✅
    - "slippagePct": 1: success ✅
      - 2025-11-11 08:11:07 | info | Transaction sent: 0xc6027a115162a79e9a0eca8c6e54cd61bd7b89da6e8b2c2ab3222ac31069b9b0
      - 2025-11-11 08:11:17 | warn | Transaction 0xc6027a115162a79e9a0eca8c6e54cd61bd7b89da6e8b2c2ab3222ac31069b9b0 is still pending after timeout
      - https://basescan.org/tx/0xc6027a115162a79e9a0eca8c6e54cd61bd7b89da6e8b2c2ab3222ac31069b9b0
  - GET /connectors/uniswap/amm/quote-liquidity: ok
  - POST /connectors/uniswap/amm/add-liquidity
    - "slippagePct": 5: ok
      - https://basescan.org/tx/0x9e58aee8d8f142a82e171e5b837ba4a01406ee0c4ce378837e2e7f2195a37298
    - "slippagePct": 1: ok
- sqrtPriceLimit Not Enforced in CLMM Swap
  - GET /connectors/uniswap/clmm/quote-swap: ok
  - POST /connectors/uniswap/clmm/execute-swap: ok
    - "slippagePct": 1: ok
    - "slippagePct": null: ok
- Transaction Receipt Waiting Pattern
  - default transactionExecutionTimeoutMs: 10000: ok ✅ (no timeout)
  - transactionExecutionTimeoutMs: 1000:
    - 2025-11-11 08:19:44 | info | Transaction sent: ✅0x74b70d95e29fc7aeea7d176f1f9825e21f0e945c5a81336dd55357653bb1f242
    - 2025-11-11 08:19:45 | warn | Transaction 0x74b70d95e29fc7aeea7d176f1f9825e21f0e945c5a81336dd55357653bb1f242 is still pending after timeout ✅
    - 2025-11-11 08:19:45 | error | Transaction failed on-chain. Receipt: {"transactionHash":"0x74b70d95e29fc7aeea7d176f1f9825e21f0e945c5a81336dd55357653bb1f242","blockHash":"","blockNumber":null,"transactionIndex":null,"from":"0x08940dc9B5a19FAb9319b77C61DDA7B8067E6843","to":"0x4752ba5DBc23f44D87826276BF6Fd6b1C372aD24","cumulativeGasUsed":{"type":"BigNumber","hex":"0x00"},"gasUsed":{"type":"BigNumber","hex":"0x00"},"contractAddress":null,"logs":[],"logsBloom":"","status":0,"effectiveGasPrice":{"type":"BigNumber","hex":"0x00"}}
    - 2025-11-11 08:19:45 | error | Swap execution error: Transaction reverted on-chain. This could be due to slippage, insufficient funds, or other blockchain issues.
    - 2025-11-11 08:19:48 | info | Transaction 0x74b70d95e29fc7aeea7d176f1f9825e21f0e945c5a81336dd55357653bb1f242 confirmed in block 38044320 ✅
  - transactionExecutionTimeoutMs: 5000 ✅
    - same behavior after 5s

vic-en added 4 commits October 27, 2025 17:41

Add sqrtPriceLimitX96 calculation using encodeSqrtRatioX96 in execute…

24b7ea6

…ClmmSwap

Fix typo in transaction execution timeout configuration

8363488

vic-en changed the base branch from main to development October 28, 2025 22:06

vic-en added 2 commits October 28, 2025 17:47

Merge branch 'development' into enhancements/uniswap-like_connectors

2d684aa

Refactor slippage percentage handling across liquidity and swap funct…

16390f3

…ions

vic-en added 3 commits October 28, 2025 18:52

Remove duplicate transaction execution timeout configuration from Eth…

dc52075

…ereum chain YAML files

Remove transaction execution timeout property from Ethereum network s…

38f1994

…chema

Remove unused import from approve.ts

0710f6d

Add transaction execution handling in executeQuote tests

0b7f2a4

rapcmia requested review from fengtality and nikspz October 29, 2025 13:53

rapcmia added this to Pull Request Board Oct 29, 2025

rapcmia moved this to Backlog in Pull Request Board Oct 29, 2025

fengtality requested changes Oct 30, 2025

View reviewed changes

nikspz mentioned this pull request Oct 30, 2025

Uniswap connector improvements and inconsistencies #510

Open

5 tasks

revert status to comply with Hummingbot TransactionStatus

3dd3fa5

Merge branch 'development' into enhancements/uniswap-like_connectors

11a47f9

vic-en added 2 commits November 7, 2025 15:55

vic-en added 3 commits November 7, 2025 16:11

Import utils from ethers for enhanced functionality in addLiquidity

e9eea57

Update transaction status from -1 to 0 for pending transactions

207bd10

Update transaction status to -1 for failed transactions

698432c

rapcmia moved this from Backlog to Under Review in Pull Request Board Nov 10, 2025

Merge branch 'development' into enhancements/uniswap-like_connectors

7e697a2

nikspz approved these changes Nov 11, 2025

View reviewed changes

fengtality approved these changes Nov 12, 2025

View reviewed changes

fengtality merged commit ed5ad71 into hummingbot:development Nov 12, 2025
2 checks passed

rapcmia moved this from Under Review to Development v2.11.0 in Pull Request Board Nov 12, 2025

Uh oh!

Enhancements/evm and uniswap-like_connectors #540

Enhancements/evm and uniswap-like_connectors #540

Uh oh!

Conversation

vic-en commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

1. Slippage Parameter Inconsistency

2. Pool/Pair Address Derivation Inconsistency

3. sqrtPriceLimit Not Enforced in CLMM Swap

4. Transaction Receipt Waiting Pattern

Uh oh!

fengtality commented Oct 28, 2025

Uh oh!

vic-en commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vic-en commented Oct 29, 2025

Uh oh!

fengtality left a comment

Choose a reason for hiding this comment

Uh oh!

fengtality Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

fengtality Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

vic-en Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fengtality Oct 31, 2025

Choose a reason for hiding this comment

Uh oh!

vic-en Nov 7, 2025

Choose a reason for hiding this comment

Uh oh!

fengtality commented Oct 31, 2025

Uh oh!

nikspz commented Nov 7, 2025

Uh oh!

fengtality commented Nov 7, 2025

Uh oh!

nikspz commented Nov 7, 2025

Uh oh!

nikspz commented Nov 7, 2025

Uh oh!

vic-en commented Nov 7, 2025

Uh oh!

nikspz commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fengtality commented Nov 10, 2025

Uh oh!

nikspz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vic-en commented Oct 28, 2025 •

edited

Loading

vic-en commented Oct 28, 2025 •

edited

Loading

vic-en Oct 30, 2025 •

edited

Loading

nikspz commented Nov 10, 2025 •

edited

Loading