If you want an agent in Python to pay for an API call over HTTP 402, the stack today is a protocol, one clearly Python-shaped client, and a few neighboring SDKs for identity and agent-to-agent commerce. That is a real starting point. It is not yet a full kit. This post walks through the six components Sato Hub tracks for this job, what each says it does, and where you will be writing your own glue.
One framing note before the list: every Sato Score below is a transparency and liveness signal. It tells you how much is open, active, and checkable. It is not a safety grade, a quality grade, or a promise about returns. Everything in the "what it does" lines is what the project says about itself, taken from its listing.
The protocol: x402
x402 is the layer everything else here hangs off. Its listing describes an open HTTP 402 payment protocol, now at the x402 Foundation, where agents pay per request in stablecoins. It also notes a newly merged spec for paying in bitcoin over Lightning. Tracked chains: Base, Ethereum, Solana, Bitcoin, and multichain. Sato Score: 87, tier High, with a deploy spec on file.
The point for Python builders: x402 is a protocol, not a Python library. The listing does not describe a Python package. It describes the contract your client and the server you are paying have to agree on. Read it first, because every other row in this list is an implementation of one side of it.
The client: x402 OpenAI (Python)
x402 OpenAI (Python) is the most direct answer to the search. Its listing calls it a drop-in OpenAI Python client with transparent x402 micropayment support. Chains: Ethereum, Base, Solana. Sato Score: 64, tier Medium, deploy spec on file.
What that framing implies: if your agent already talks to an OpenAI-style API from Python, the payment step moves inside the client instead of into your control flow. What the listing does not tell you is how spend limits, retries after a failed payment, or key handling work. If your agent can move funds, "drop-in" is the start of the design conversation, not the end of it. Read the repo before you hand it a funded wallet.
The commerce layer: Agently
Agently is described as a routing and settlement layer and CLI for agent-to-agent commerce. The listing names EVM wallets, agent discovery, A2A messaging, x402 payments, and ERC-8004 identity. Chain: Base. Sato Score: 62, tier Medium, deploy spec on file.
This is the one to look at when your agent is not just a buyer of one API but a participant that finds other agents and settles with them. The listing describes a CLI; it does not say Python, so check the repo for how you would drive it from your own code.
The identity and reputation neighbors
Payments answer "can this agent pay." They do not answer "who is this agent." Two tracked SDKs cover the ERC-8004 side, and both list Python.
- ▸ChaosChain — protocol and SDKs (Python, TypeScript) for agents that register an ERC-8004 identity and record their work for reputation, with x402 payments. Chain listed as unknown. Sato Score: 54, tier Medium. No deploy spec on file.
- ▸Agent0 SDK — TypeScript and Python SDKs to register an agent on ERC-8004, publish its MCP and A2A endpoints, and search for or give feedback on other agents. Multichain. Sato Score: 48, tier Medium. No deploy spec on file.
Note the difference in emphasis. ChaosChain frames itself around recording work for reputation. Agent0 frames itself around registration, publishing endpoints, and discovery. Both are claims from their listings; "recorded work" and "feedback" are only as meaningful as the data behind them, which a listing cannot tell you.
The data you might pay for: MadeOnSol
MadeOnSol is on the list because it shows what the paying side looks like. It is a trading-intelligence API for Robinhood Chain and Solana (KOL trades, DEX tape, deployer reputation) with MCP, SDKs, an ElizaOS plugin, and x402 pay-per-call. Sato Score: 60, tier Medium, no deploy spec on file. The listing does not say which languages the SDKs cover, so do not assume Python. It is a useful example of an x402 seller: an API that charges per call rather than per seat.
What is still missing
Read across the six listings and a few gaps stand out. These are gaps in what the tracked listings describe, not claims about the wider ecosystem.
- ▸Seller-side Python. The only Python-labeled payment component here is a client. None of the six is described as a Python helper for putting x402 in front of your own endpoint.
- ▸Spend controls. No listing here describes per-call or per-day spend limits for the paying agent. Wallet controls are your job until you have read the code that says otherwise.
- ▸Identity, payments, and discovery as one flow. ERC-8004 SDKs and x402 clients sit side by side in the same neighborhood. Wiring an agent that registers an identity, discovers a seller, and pays it is still a three-library exercise.
- ▸Deploy specs. Three of the six have one on file. The other three you will integrate by hand.
What to watch
Two things. First, whether the Lightning spec for x402 turns into client support in the Python libraries, since today the tracked chains for the client are Ethereum, Base, and Solana. Second, whether the identity SDKs and the payment clients start referencing each other, so an agent's ERC-8004 record and its payment history stop living in separate worlds. We will keep re-scoring these as their repos move.
Build with it
The prompt is the cute part; the stack is where the work lives. Describe the agent you want and Sato maps the wallet, payment rail, identity, and data pieces it needs: satohub.ai/build.