Skip to main content

Building the Internet of Agents with z402

· 16 min read
Frollo
Frollo
Tesseract CTO

AI agents are playing an increasingly important role in our lives, they're becoming more capable and autonomous, the Internet of Agents is what will make them an organism that is greater than the sum of its parts.

History and motivation​

Each day millions of internet transactions are carried out, these transactions are done through different UIs and payment processors, there's no standard governing them. But why would we need a standard in the first place? Essentially a standard makes things easier, for developers and for users; it creates a more fair and open environment, where there are no few "gatekeepers" companies governing payments and charging high fees, there's just the standard: if you use it, you're ready to go.

It's weird that such a universal human primitive like payments is not encoded into the internet as a fundamental protocol, this wasn't supposed to be case, in fact, in 1997 in the specification of HTTP/1.1 a 402 - Payment Required status code was added and kept for "later use". Still today, the 402 status code is considered non standard and there's no internet native payment protocol. But this is about to change.

Requirements for an internet native payment protocol​

We believe that an internet native protocol should have the following characteristics.

  1. No protocol fees: the protocol itself should not charge any fees. There could be some processing fees due to the technology used to settle transactions (blockchain for instance).
  2. No central control: the protocol shouldn't be controlled by any individual or organization with conflicts of interest, the same holds for the technology used to settle payments.
  3. Integrated with HTTP: the protocol should be implemented in HTTP using the 402 status code, as per the 1997's original spec.
  4. Transactions have no minimum (or very low): it must be possible to make subcent transactions.
  5. As scalable as the internet: the payment protocol should be able to scale almost without limit, like the internet itself.
  6. As fast as the internet: the payment protocol shouldn't introduce any delay due to the protocol itself. When making a transaction as an HTTP request, it should be immediately clear that the transaction is valid and there should be no need of triggering more network requests.

The first protocol to try tackle these problems was x402, created by Base; it satisfies (debatably1) all the requirements except the 5th and 6th: x402 is not as fast and as scalable as the internet, it is just as fast and as scalable as the underlining blockchain. We will later see how z402 solved these problems, nevertheless, x402 enabled new interesting use cases, in particular the constitution an Internet of Agents.

Internet of Agents architecture​

The expression Internet of Agents (IoA) takes inspiration from the Internet of Things (IoT), that is a network of computers, typically sensors and low power devices, that communicate with each other and share data. The Internet of Agents is similar, it is a network of specialized agents (AIs or humans) that perform complex tasks autonomously by collaborating with each other and paying for the services/goods that they offer.

In such a system, you will have humans, AI and potentially other programs to purchase from each other: it's a new kind of economy where AI agents and humans can work together by selling services, on demand access to content and more; in many situations it supersedes or complements the subscription model. For example, you could have an artist AI agent offering to generate an image for 0.0001$ or a human asking for 0.10$ to access an exclusive blog post instead of requiring a full subscription; you can unlock pay-per-use and micropayments natively, without the sellers and buyers having to set up API keys, without a minimum amount and with no funds lock in. More use cases are explored in the dedicated section.

To build such an agent network, you need to equip it with the following:

  • Discovery mechanism: agents need to find each other and know what services they offer
  • Communication protocol: agents need to "speak the same language" to start, end and update tasks
  • Payment protocol: agents need to pay for the tasks performed by other agents
  • Reputation system (optional): a system to assign and retrieve a score to sellers based on the quality of the output they produce

Google's A2A protocol seems the emerging protocol for the internet of agents: it offers Agent Cards for discovery, it has a communication protocol but no payment protocol nor reputation system. It is possible to extend A2A with A2P, adding a payment protocol that is also compatible with x402 and z402. Finally, the EIP 8004 improves A2A discovery capabilities and adds a reputation system.

z402​

z402 is an extension of x402 that is as fast as the internet, transactions are instant with no delay and no extra HTTP requests and, for now, it is five times as scalable as x402. For this reason z402 satisfies also the 5th point of our list of requirements for an internet native payment protocol, we didn't hit the 6th point of the list yet, but it's in on our roadmap! Being more scalable than x402, means also being cheaper, a z402 transaction can cost less than one fifth of a x402 transaction. We are continuously working on improving the scalability of z402, you can read what we are doing in our z402 costs and scalability post.

Broadly speaking, z402 uses a smart contract as escrow for the payments and releases the funds only if a valid cryptographic proof of payment is given, the verification of the payment proofs is done completely off-chain, allowing to bypass the delay of the underlining blockchain and to perform instant transactions. The actual transaction settlement is done on-chain at a later time and the deposit is locked for a payer chosen amount of time.

Another advantage of z402 is that, by design, it can support blockchains with longer block time like Ethereum, x402 can't support such a blockchain because it would make also x402 payments slow and nobody wants slow transactions, especially for AI agents.

You can read more how z402 works in the z402 docs.

Use cases​

Here is an (incomplete) list of use cases of z402, along with a comparison with existing services2:

  • Pay-per-use: the pay-per-use business model allows to offer on demand service with micropayments, but as of today, it is inherently flawed. This is because of the high fees payment processor take (around 3%) and because users are forced to lock their funds into the platform usually without the possibility to withdraw them, this creates more friction compared to seamlessly pay (no registration) for what you need, with no locked funds.
    • AI inference: OpenAI API users need to pay a minimum of 5$ in credits, that expire after one year, with no refund of unused credits. An alternative service could leverage z402 to offer no lock in of funds, reducing lost funds and initial friction.
    • Cloud services: a service using z402 could offer cloud resources usage, including GPU and CPU, per hour or per minute at a lower price than competition. Moreover, likely the customers might as well not be humans, but rather AI agents that need compute for their "survival".
    • Access to a database: a service could use z402 to offer access to a database on demand for a micropayments, instead of asking for a subscription. AI agents can access and pay for only the data they need.
  • Agentic payments: this is a new use case. The open market of the Internet of Agents, made up of humans and AI agents, offers big opportunities: with z402 it's possible to monetize every task done by the agents in the network.
    • AI specific services: since AI agents will be protagonist in the Internet of Agents, products and services specifically intended for AI agents will be developed. For example a service, like firecrawl, that turns website into text specifically formatted for LLMs could be monetized using z402 and autonomously accessed by AI agents every time they need to read a website page, paying per each request without needing a human register to a website and setting up API key, etc.
    • Personal agent economy: for most people the smartphone is the gateway to many of their everyday activities, even though smartphone interfaces are built to be intuitive, they still require the user to "adapt" to the interface. From a UX perspective, AI devices, equipped with speech and video capabilities, are the ultimate interface, because they would work by simply asking them to do whatever pleases you. Personal agents will emerge, they are AI agents that know us well as our smartphone knows us today. Differently from your smartphone, an AI agent would be autonomous, so it could do actions on our behalf, including shopping, opening up a new set of use cases: ads for AI agents, personalized ads delivered through personal agents in the form of text or speech and more.
    • Agentic economy: AI agents can sell services and accumulate wealth, they can even invest that wealth to gain even more: all this autonomously. Agents can aggregate to offer complex services, de facto making their own companies and partnerships. Also, many AI agents will work for humans that programmed them or that have control over their funds.
  • High speed services:
    • High frequency trading: we can unlock trading stocks on any blockchain thanks to z402 instant transactions
    • Highly requested API endpoints: API endpoints with thousands of requests per seconds can be monetized with no performance impact
    • High throughput agents: agents that make thousands of requests per second can deliver instantly, thanks to z402
  • On demand content with no minimum limit: today a popular business model is the subscription business model, we believe it can be overtaken by an on demand business model where a user makes request for a specific content, not an extensive offering that they will never use, in some cases it might be appropriate for these models to coexist.
    • Paywalls: paywalls block access to content and unlock it after paying a subscription, an alternative is using z402 to create a paywall that unlocks after a micropayment, this way customers don't need to subscribe to content they might never need. Some examples are: scientific journal access, newspapers/articles access, exclusive paid content by content creators.
    • Content creator economy: content creators get mainly monetized through sponsoring, for creators with a smaller public this is difficult to achieve. A simple "tipping service" could be developed to integrate into existing social platforms and be set to have a low minimum (ex. 0.01$), tipping small creators is now possible.
    • Streaming: Netflix's Standard subscription costs 17,99$ a month. An alternative streaming service using z402 could offer to pay 0.25$ to rent a single movie or even charge per minutes watched.

Operative modes​

Since z402 is an extension of x402, it offers two operative modes:

  • x-mode: a 100% x402 compatible mode, following the same specs
  • z-mode: what makes z402 special, with instant payments, added scalability and lower fees

In short, we believe that z-mode is better than x-mode in most cases, but not in all. z-mode outperforms x-mode when a buyer needs to perform multiple transactions with a seller, in this case you get instant transactions and the lowest fees, even in the case of a single transaction z-mode performs just as good as x-mode (they have the same speed), but the overhead of using a smart contract slightly increases the blockchain fees. So, it's smart to use x-mode for single-use non-repeated transactions, for all the rest use z-mode.

Choose z-mode every time, as buyer or seller, you need to do multiple transactions. For example, choose z-mode

  • for the internet of agents: z-mode is perfect for AI agents because it can stand high frequency transactions with no delay added and the lowest blockchain fees
  • as a buyer or seller, when you want instant transactions
  • when you want to monetize REST API endpoints
  • when you want to monetize database access
  • when you offer AI inference, cloud storage, etc as service
  • when you own a store: for users that buy repeatedly and want to save on the total cost
  • when you want to use a blockchain network not supported by x402

Choose x-mode every time you are buying a service/good from a seller and you don't think you will buy again. For example, choose x-mode

  • when you own a store: for AI agents that buy occasionally (humans instead would pay with blockchain directly using their wallet)
  • when you want to access resource once, ex. a journal, a paid media, an article
  • when you are a first time buyer for a seller and you're not sure you will buy again
  • as a seller, when you want to be compatible with x402
  • as a buyer, when the seller only supports x402

Comparison with other payment methods​

Let's compare z402 with other payment methods, including x402, Stipe and PayPal.

Pricing and speed2​

Payment MethodTypical FeesValid paymentSettlementScalabilityChargeback Risk
Credit Card$0.30 + 2.9%~1sDays (batch)65k TPSYes, up to 120d
PayPal~3% + fixed fee~1sDaysUnknownYes
Stripe2.9% + 0.30$~1s1-3 days>13k TPSYes
Stripe (Pay with Crypto)>1.5%~1sDepends on blockchainDepends on blockchainNo, not reversible
Ethereum L11–5$ + gas12s12s block time, ~13 min finality15–20 TPSNo, not reversible
x402 (Base)<0.001$200 ms200 ms preconfirmation, 2s block time, ~20 min finalityHundreds to thousands TPSNo, not reversible
z402 (Ethereum) (100 mean3)<0.001$0 msyou choose4 + 12s block time, ~13 min finality2 times Ethereum = 30-40 TPSNo, not reversible
z402 (Base) (100 mean3)<0.0001$0 msyou choose4 + 200 ms preconfirmation, 2s block time, ~20 min finality5 times TPS of x402 on BaseNo, not reversible
z402 (Sonic) (100 mean3)<0.0001$0 msyou choose4 + 900 ms block time, ~20s finality2 times Sonic = 800k TPSNo, not reversible

User experience​

Use caseLegacyx402z402
AI agents paymentsNon existing
  1. Seemless integration
  2. Payments speed depends on blockchain
  3. Very low fees
  1. Seemless integration
  2. Payments are instant
  3. Very low fees
  4. Lots of blockchains supported
Pay-per-use (ex. market research agent)
  1. Humans need to manually subscribe/buy credits to many API services
  2. API keys setup required
  3. API credits can expire
  1. AI Agent pays for API services
  2. No API key setup required
  3. Payments speed depends on blockchain and low fees
  1. Agent pays for API services
  2. No API key setup required
  3. Instant payments and low fees
High frequency services
  1. Humans need to manually subscribe/buy credits to the API service
  2. API keys setup required
  3. API credits can expire
Non existing
  1. User pays for API services
  2. No API key setup required
  3. Instant payments and low fees
Pay-per-access (ex. human wants to read an article)
  1. Account registration required to make a subscription
  2. Monthly/yearly subscription required to unlock paywall
  1. Pay with wallet and unlock paywall
  2. No registration required
  1. Pay with wallet and unlock paywall
  2. No registration required
  3. Instant payments and low fees

Conclusion​

I hope this post gave you a bunch of good reasons to start using and building on z402. If you're a dev, head over to our docs, see you out there!

Footnotes​

  1. In some, fairly common, cases, x402 fails to be truly decentralized. For example if you run x402 on Base, Base infrastructure becomes a centralization point, because Base has only one sequencer (theirs), this causes predictable pitfalls. This case is relevant since currently using x402 on Base with Flashblocks is the most used settings. In this case, the protocol is not failing by itself but in the way most people and agents, often unknowingly, use it. z402 can run on more blockchains, including the most decentralized: Ethereum. ↩

  2. The reported information on external companies is to be intended as explanatory and not accurate nor complete as it is outside of Tesseract's control, it's reported for your convenience. The reported information is subject to change, you can verify independently our claims by heading over to the respective companies website, if you find any incorrectness don't hesitated to contact us or open a pull request. ↩ ↩2

  3. Since z402 works in such a way that the more transactions you batch, the less fees are due per transaction, the fees here reported are calculated as a mean of 200 batched transactions. Read more in the docs. ↩ ↩2 ↩3

  4. Users can know immediately if a payment is valid or not (i.e. if it will be settled or not) because the verification happens off-chain, while the settlement time is chosen by the seller, the more they wait, the more they can batch transactions and save on fees, because the z402 smart contract, that handles the settlement, can reduce gas fees. So, once the payment proof has been submitted, the settlement time is the same of x402, the best strategy is to submit the payment proofs during execution of a task or at later moment, this way the task execution is not delayed at all. ↩ ↩2 ↩3