Web3.py

Web3.py is a Python library for Ethereum and other networks exposing compatible EVM interfaces. It reads blocks, interacts with contracts, processes events and prepares transactions. It fits services, scripts and analysis already using the Python ecosystem and its data-processing tools.

It is distinct from Web3.js and has its own release cycle. Provider instructions, asynchronous APIs and Python requirements need to match the installed version. The Web3.js sunset does not mean web3.py was sunset, and examples should not be transferred between the two projects without review.

Clients access nodes through providers. Synchronous variants suit simple scripts, while AsyncWeb3 organises asynchronous calls. Persistent providers support subscriptions according to their configuration; exact names and methods should be checked against documentation for the version used by the project.

Contracts use an address and ABI. Amounts remain in base units with controlled conversion for display or export. Signing uses appropriate account components, separating keys and authorisation from code that queries or transforms data. Reading network state does not inherently require access to signing credentials.

A reconciliation process can retrieve event ranges, normalise amounts and compare them with internal records. Rows retain network, contract, transaction and event identifiers. This supports duplicate detection and report reconstruction when classification rules change or an operational discrepancy needs investigation.

Concurrency should reflect RPC capacity and transformation work. Asynchronous services should not open unlimited requests. Checkpoints, bounded retries and reorganisation recovery let processing continue after interruptions without losing or duplicating movements. These behaviours need testing alongside the calculations that produce the final report.

Web3.py does not replace SDKs for networks exposing different interfaces. Nor does it independently supply an indexed history of every token owned by an account; some queries require events, indexes or additional services. Distinguish node responses from application-derived information when defining scope.

Selection depends on data libraries and team environment. Pin versions with their Python requirements and test upgrades. Measure actual querying, decoding and storage workloads rather than using universal events-per-second claims without a defined workload, provider configuration and recovery policy.