uniswap-python: a Python client for Uniswap V2, V3 and V4

A wrapper over contracts, with a CLI on the side

uniswap-python is described as the unofficial Python client for Uniswap, and the functionality list defines what it actually is. It is a simple to use Python wrapper for all available contract functions and variables, a basic CLI to get prices and token metadata, and simple parsing of data returned from the Uniswap contract. That third item is the one worth pausing on, because parsing contract return values is where most of the work in a wrapper like this lives. The package itself is small in structure, with a `uniswap/` package directory, a `tests/` directory, a `docs/` directory for the Sphinx site, an `examples/` directory with a price impact example and a V4 examples file, a `metrics/` directory, a `scripts/` directory and the usual configuration files. The CLI is published as a console script named `unipy`, and the distribution is a Poetry project with the version field set to 0.9.0 and a comment that it is set automatically in CI on tagged releases before being pushed to PyPI.

Three protocol versions, and the caveats attached to each

The support table is the most useful part of the README for anyone planning to use the library, because it is precise about what is proven and what is not. Uniswap v4 support arrived with version 0.8.0 and is marked as beta, covering swaps, price quoting and liquidity management, plus pool discovery through a pool cache service. Uniswap v3 arrived with 0.5.0, and includes beta support for the Arbitrum and Optimism deployments as of 0.5.4. Uniswap v2 came with 0.4.0. Uniswap v1 is listed as deprecated, and the 0.9.0 changelog entry says V1 support was removed. Below that there is a list of various forks marked untested but expected to work, covering Honeyswap on xDai, Pancakeswap on BSC and Sushiswap on mainnet. So the library spans the versions you are likely to meet, with the caveat that the newest protocol is beta and the forks are a best guess, which is a reasonable trade for a client library rather than a production dependency.

The changelog records a lot of breaking change

The changelog in the README is long and is the best evidence about how the library has evolved. The 0.9.0 entry added async versions of Uniswap V2 through V4, added V2 and V3 custom routes marked untested, added an async pool cache service for V4, and removed V1 support. The 0.8.0 entry added V4 support with the pool cache service, full parameter customisation for V4 transactions, and V4 transaction replacement and cancelling. The 0.5.0 entry is the one to read if you are upgrading from an older line, because it added basic V3 support with new `get_price_input` and `get_price_output` methods, made a lot of previously public methods private, added the documentation site and removed ENS support, which the README describes as probably broken to begin with. The 0.4.0 entry is the era change, with a move from setup.py to pyproject.toml and Poetry, a move from Travis to GitHub Actions, type annotations across the codebase checked with mypy in CI, and black formatting applied to the whole tree. Several intermediate versions are marked as having an incomplete changelog, which is a fair signal about how carefully to read it.

Fee handling, where the surprises live

Two changelog entries describe behaviour that will bite you if you do not read them. The 0.7.2 entry says the default fee is not applied when using Uniswap V3, while the default fee for V1 and V2 is still 0.3 percent, and that an `InvalidFeeTier` exception is raised when a tier is not supported by the protocol version, with the supported tiers listed in the `uniswap.fee.FeeTier` module. The 0.5.4 entry says gas estimation is used instead of a fixed gas limit, to support Arbitrum, with a `use_estimate_gas` constructor argument used in testing, and that basic support was added for Arbitrum, Optimism, Polygon and Fantom, marked untested. The difference between a fixed gas limit and an estimate is not academic, since a chain where the default gas limit is wrong produces transactions that fail on submission, and a fee default that silently differs between protocol versions is the kind of thing that shows up as a small loss on a large trade.

Testing against a mainnet fork, and a CI secret you will need

The testing section is honest about where it stands, saying that unit tests are under development using the pytest framework and that contributions are welcome. The mechanism, though, is the interesting part, because the suite runs against a fork of mainnet using Anvil, which is part of Foundry, and the README gives the install commands for Foundry itself, the curl of the install script, the PATH export and `foundryup`. To run the full suite you set the `PROVIDER` environment variable to a mainnet provider URL and run `poetry install` and `make test`, with a variant that runs pytest with `--capture=no` so the output is not captured. The CI side of it is described in the 0.4.0 entry, which says that for CI to work in your repository you need to set the secret `MAINNET_PROVIDER`, and the author uses Infura.

The commands the README gives for a local run:

poetry install
make test

The Makefile wires this together with a `test` target that runs pytest verbosely with a traceback style, a coverage report to HTML, terminal and XML, a `typecheck` target running mypy, a `lint` target running ruff, a `format` target, an `format-abis` target that runs prettier over the ABI JSON files, and a `precommit` target that runs type checking, linting and the tests together.

Typing, packaging and a pinned setuptools

The package metadata is worth reading for two reasons. The first is the dependency set, which is dominated by the web3 stack, with web3 at version 8, plus the async utility crates, click for the CLI, aiohttp for the async client, python-dotenv and typing-extensions, and a curious pin on setuptools below version 82, with a comment explaining that eth-keyfile, pulled in through web3 and eth-account, imports pkg_resources, which setuptools dropped in 82.0.0, and that the pin should hold until web3 7.x with a pkg_resources free eth-keyfile is adopted. The second is the tooling shape, with mypy, ruff, pytest with the asyncio and dotenv plugins, and Sphinx with a book theme, and the ruff configuration ignoring the module level import placement and line length rules, which is a common choice for a project with generated or conditional imports. The package also declares its intended audiences, developers, the financial and insurance industry and information technology, which tells you who the author expects to run this.

Funding, maintainers and what unofficial means for you

The funding section is a good summary of who maintains this. The Uniswap Grants Program awarded a 15,000 dollar grant in 2021 that funded the development of the V3 support, community donations through Gitcoin Grants were used to compensate contributors as discussed in issue 181, and Superuser Labs, Erik's company, has sponsored continued development and maintenance including funding the work on V4 support. The named authors are Shane Fontaine, Erik Bjäreholt and @liquid-8, with a contributors graph behind them, and contributors can earn a GitPOAP for their work, which is a nice touch for a volunteer project. The practical risk to weigh is the one the project states in its own description, that it is unofficial. That means the version of the protocol it targets can move under it, that v4 support is beta, that forks are untested, and that a change in the exchange's fee or pool semantics would arrive as a bug in a client you did not write. For a script, a bot or a research tool that is a trade most people make knowingly.

Editorial conclusion

Adopt uniswap-python if you need to quote prices or trade against Uniswap from Python and you want the contract plumbing, the fee tier handling and the token metadata parsing handled for you. Do not adopt it if you need a guaranteed stable API, because the README marks Uniswap v4 support as beta, the changelog shows breaking changes including the removal of V1 support and the making of many previously public methods private, and the library is explicitly unofficial. Before you commit to it, read the changelog for the version you would pin, because the 0.5.0 entry moved the price methods to `get_price_input` and `get_price_output` and privatised a lot of the surface, and check the fee behaviour, since the default fee is not applied on V3 while V1 and V2 still default to 0.3 percent. The licence is MIT, the current release is 0.8.0 from 2026-08-03, and the last push was on 2026-10-15.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. uniswap-python/uniswap-python on GitHub