Why Tollex
An agent can already call an API. The hard part is everything around the call: deciding what it may buy, finding a service that fits, knowing the price before it pays, paying safely, recovering when a response disappears, and proving afterwards what happened.
Tollex handles that layer.
01
The problem isn’t making the request.
An agent with a wallet can reach hundreds of paid services. They do not agree on much. Schemas differ. Prices are declared in different places, or only appear when you ask. One service takes USDG on one network, another wants a different scheme, a third is fast but returns no proof, and a fourth has been failing since this morning.
Without a layer that sorts this out, every team building an agent writes the same code: catalogue parsing, price checks, payment handling, retries, record keeping. Most of it is written once, under deadline, and never tested against a lost response.
Tollex reads each source as it comes and turns it into one capability model, so the agent compares like with like.
GET /v2/spot/{pair}x-price: noneauth: X-Api-Keyname: get_priceinputSchema: { symbol }transport: stdio402 PAYMENT-REQUIREDscheme: exact · 2000asset: USDGskill: market-quotetags: [prices]protocolVersion: 1.0- Tollex capability
- capability
- acme_spot_price v1.0.0
- input
- JSON Schema, validated
- price
- 2000 atomic USDG, exact
- network
- eip155:46630
- receipt
- signed, EIP-712
- evidence
- source_hash
- health
- checked 28 s ago
- history
- success, p50, p95
02
Ask for the outcome.
The agent says what it needs and what it is prepared to accept: a cost ceiling, a latency limit, a receipt, a network. It does not need to know the provider in advance. Tollex finds the capabilities that fit, rules out the ones that cannot, ranks the rest and buys the best eligible one.
That search can include x402 services Tollex does not run. When a compatible external merchant is the best fit, Tollex applies the agent’s rules, confirms the merchant’s live price and pays it directly from the agent’s wallet. How external routes work.
The words in need only help matching. They cannot raise a ceiling, add a network or unblock a provider. Constraints are typed fields, checked before anything is ranked.
If you want to look before you buy, resolve returns the same plan without spending anything.
const result = await tollex.do<{ address: string; balance: string }>({
need: "token balance of a wallet",
input: { address: wallet.address },
constraints: { maxCost: usdg("0.001"), receiptRequired: true },
});
result.result.balance; // the capability's output
result.payment.actualAmount; // what was charged, in atomic USDG
result.receiptVerification?.valid; // the signed receipt checked out
result.settlement?.status.settlement; // "included", "finalized", ...Need: current ETH/USD market price
Selected provider-03 · eligible 4 of 7
- provider-030.00063200 msreceiptselected
- provider-070.0008450 msreceipteligible · rank 2
- provider-010.0015350 msreceipteligible · rank 3
- provider-050.0025210 msreceipteligible · rank 4
- provider-020.0009280 msno receiptno execution receipt
- provider-040.0004300 msreceiptfailing health check
- provider-060.007180 msreceiptover the cost ceiling
- matches the need (relevance 0.87)
- exact on eip155:46630, at most 600 atomic USDG (limit 3000)
- returns a signed execution receipt
- observed success 99.0% over 960 calls, p95 3200 ms
- terms and health observed 40 s ago
- provider health check passing
Illustrative providers. Each outcome was computed by the Tollex resolver; this page only displays the results.
03
Policy before payment.
An agent should not hold an open-ended wallet. It should hold economic authority: a defined amount it may spend, on defined things, for a defined time.
You write that authority down as a policy. Tollex evaluates it before the signer is asked for anything, and the signer only signs what the policy approved. Budget reservations are atomic and can live in Postgres, so twenty parallel calls cannot each spend the whole daily allowance.
Keys stay where you keep them: a local key in development, a KMS or a remote signer in production. Tollex never holds them, and a policy cannot be rewritten by the model it constrains.
- Per requestthe most one call may cost
- Per hour, per daybudgets that hold under concurrency
- Tools and providersallow and block lists, with prefixes
- Merchants and assetswho may be paid, and in what
- Networkstestnet only, until you decide otherwise
- Receiptsrequire a signed receipt, or do not buy
- Authorization lifetimehow long a signature stays valid
04
One economic interface.
x402 resources can ask to be paid in different ways. A fixed price suits one call; a metered ceiling suits generation; a payment channel suits thousands of tiny charges. An agent should not need four payment architectures to use four merchants.
Tollex reads each resource’s live terms, keeps only the routes your policy allows, and pays through the one it selected. Each resource offers the schemes it chooses, and not every resource supports every scheme. When a route needs something first, such as a Permit2 allowance or a channel deposit, the plan says so before you commit.
05
Failure is part of payments.
A timeout does not mean a payment failed. The transaction may already be on its way to a block while the HTTP connection that carried it has gone. An agent that treats the timeout as failure pays twice.
Tollex records every operation durably before it moves money. It tracks the settlement against the chain, matches a retry to the authorization it already holds instead of creating a new one, and hands back the stored result. An agent can always ask for the state of an operation instead of guessing.
- 12:00:01.204RequestSubmitted with an authorization for 0.002 USDG.
- 12:00:03.880NetworkConnection reset. The response never reaches the agent.
- 12:00:04.112ChainThe payment is included in a block.
- 12:00:04.950TollexThe agent’s retry carries the same authorization. It is matched to the existing operation; nothing new is signed or charged.
- 12:00:05.020ResultDelivered from the stored response, with its receipt.
An example timeline. The behaviour is what the system does; the timestamps are illustrative.
06
Proof comes back with the result.
Every paid response carries a receipt signed by the merchant’s published key. It is not a log line; it is a structured record another program can check without asking anyone.
The agent can audit its own spending. The operator can reconcile every charge against what was delivered. The provider has evidence that it did the work. And anyone holding the receipt can check the signature against the published key and look up the settlement transaction on chain.
A receipt proves who signed what. Whether to trust that signer is your decision, so Tollex lets you pin the keys you trust.
- tool
- id, version and provider
- request
- hash of what was asked
- quote
- id, hash and quoted amount
- terms
- hash of the payment requirements
- metering
- units and formula, for upto and batch
- charge
- the amount actually settled
- settlement
- transaction and its state
- response
- hash of what came back
- assurance
- the finality level reached
07
Discovery should work both ways.
For people
A catalogue with real prices, documentation written for integrators, and a console that shows what actually happened.
For software
Machine-readable capabilities, schemas, prices and payment terms in the formats agent runtimes already read.
- x402 Bazaar metadata on payment challenges
- OpenAPI 3.1 for every capability
- A2A agent card
- MCP server, stdio and Streamable HTTP
- /.well-known/tollex.json and llms.txt
- SDKs for TypeScript and Python, a CLI, AI SDK and AgentKit tools, an Agent Skill
Compatible agents can discover and use Tollex automatically when their runtime supports the relevant discovery and payment protocols.
08
Providers get a distribution layer for agents.
If you run an API, agents are a new kind of customer. They do not sign up, do not read pricing pages and do not file support tickets. They need your capability described precisely and priced in a way software can act on.
Describe your endpoints once, with an OpenAPI document or a short manifest, set a price per call, and keep your credentials to yourself. Tollex does the rest of the translation.
- Capability metadata normalised from your OpenAPI document or manifest, with strict input schemas.
- Agent discovery through the catalogue, OpenAPI, A2A, MCP and Bazaar metadata.
- x402 payment terms generated from the price you declare, settled in USDG.
- Credentials by reference. Your API key is resolved at call time and never appears in a schema, catalogue, receipt or log.
- Health observations recorded over time, reported dimension by dimension.
- Receipts that show you did the work and were paid for it.
- Policy-compatible access. Operators can allow your capabilities by name, so cautious agents can still buy from you.
09
What Tollex adds.
x402 makes a single resource payable. Tollex works one level up, across resources and over time. Both are useful; this is the difference.
| Direct x402 resource | Through Tollex | |
|---|---|---|
| Choosing what to buy | The agent already knows the resource URL. | The agent states a need and constraints; Tollex evaluates its catalogue and verified x402 services it found, and explains every rejection. |
| Spending rules | Each payment is judged on its own terms. | One agent policy applies across providers: budgets, tools, providers, networks, receipt requirements, signature lifetime. |
| Provider choice | One endpoint, one decision. | Every compatible provider is checked for eligibility, then ranked with a published formula. |
| Price | The price in the 402 response at request time. | A hash-bound quote that the receipt later commits to. |
| Lost responses | A timeout leaves the outcome unclear. | Durable operation state, reconciliation against the chain, and the stored result on retry. |
| Proof | The settlement response names a transaction. | A signed execution receipt binds request, quote, payment, response and settlement. |
| Output | Whatever the provider returns. | The result plus evidence, with third-party text marked as untrusted data. |