You may not be getting the best route from the pair by default. Try specifyingroute toget_price_input. See#93 and related discussion for discussion about automating how to find the ~best pair.

EDIT: I wonder if it's a gas fee? Can we calculate this/extract this value?

You can get the current gas price from theuniswap_exchange.web3 instance. Check the Web3.py docs.

Note that neither this wrapper nor the Uniswap interface takes gas costs into account when quoted.

EDIT 2: Looking at another issue I've seen this as a possible solution, could someone explain the exponent work (10** etc) and where these values are obtained from?

The decimals are retrieved from the ERC20 contracts, they are needed to scale the traded amount into their base (non-decimal) unit (1 ETH = 10**18 WEI).

You may not be getting the best route from the pair by default. Try specifyingroute toget_price_input. See#93 and related discussion for discussion about automating how to find the ~best pair.

EDIT: I wonder if it's a gas fee? Can we calculate this/extract this value?

You can get the current gas price from theuniswap_exchange.web3 instance. Check the Web3.py docs.

Note that neither this wrapper nor the Uniswap interface takes gas costs into account when quoted.

EDIT 2: Looking at another issue I've seen this as a possible solution, could someone explain the exponent work (10** etc) and where these values are obtained from?

The decimals are retrieved from the ERC20 contracts, they are needed to scale the traded amount into their base (non-decimal) unit (1 ETH = 10**18 WEI).

Thanks for getting back to me. Comparing with uniswap v3, with multihops disabled, so we're looking at TOKEN->TOKEN directly there's still this discrepancy. Does uniswap do anything off chain perhaps or could the infrua node be lagging in some capacity?

could the infrua node be lagging

Yes. Just set up the local node; you can use light-mode for syncing so it requires like 700Mb of the disc space.