Skip to main content

Building the Internet of Agents with z402

· 15 min read
Frollo
Frollo
Tesseract CEO

AI agents are playing an increasingly important role in our lives, they're becoming always 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 we would need it? Essentially a standard makes things easier, for developers and for users, moreover it creates a more fair environment, where there are no few "gatekeepers" companies handling the payments and can charge high fees, there's just the protocol and everybody can use it.

It's weird that such a universal human primitive like the payment 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 be free to use. There could be some fees due to the technology used to make the transaction possible tho (blockchain for instance).
  2. No central control: the protocol shouldn't be controlled by any individual or organization with conflicts of interest.
  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 with no minimum (or very low): it must be possible to make subcent transactions.
  5. Scalable: 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 (debatebly1) 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 a 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.

So, 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 satisfies all the requirements for an internet native payment protocol, in particular it is as fast as the internet (no delay and no extra HTTP requests) and it scales almost limitlessly (transactions can be batched). 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 full verification process is done off-chain, allowing to bypass the delay of the underlining blockchain and to perform instant transactions.

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 a (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.
    • Cloud resources: 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".
    • AI services: 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.
    • 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. Leveraging protocols like A2A and z402, it's possible to create a network of AI agents doing tasks and selling services, every task can be monetized seamlessly with z402.
    • 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 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.. Of course, most 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 estensive offering that they will never use, in some cases it might be appropriate for these models to coexist.
    • 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.
    • 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. Another notable case is the economy around exclusive, paywalled, content, offered by individual creators: services like OnlyFans charge 20% on all earnings and imposes a minimum PPV (pay per view) fee usually forcing creators to bundle multiple media; an alternative service using z402 could offer much lower rates and a low limit on PPV content (cents)
    • Paywalls: paywalls block access to content and unlock it after paying a subscription, an alternative paywall could use z402 to create a paywall that unlocks after a micropayment, this way customers don't need to subscribe to content they might never need.

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 make z402 special, with instant payments, added scalability and lower fees on batched transactions

In short, we believe that z-mode is better than x-mode in most cases, but not in all. z-mode outperforms x-mode every time a buyer needs to perform multiple transactions with a seller, in this case you get instant transactions and the lowest blockchain 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 offer REST API usage as service
  • when you offer database access as service
  • when you offer AI inference, cloud storage, etc as service
  • when you own a store
  • 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

  • the first time you buy from a seller and you don't think you will buy again
  • when you are buying access to a one-time use resource from a seller you didn't buy from before
  • 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$ + gas12 s1–2 min euristic, 13 min finality15–20 TPSNo – not reversible
x402 (Base Flashblocks)<0.001$200 ms3200 ms preconfirmation, 2s finality3Hundreds to thousands TPSNo – not reversible
z402 (Base Flashblocks) (1k mean4)<0.0001$0 mswhenever you want5TPSNo – not reversible
z402 (Ethereum) (1k mean4)<0.001$0 mswhenever you want5Almost limitlessNo – not reversible
z402 (Solana) (1k mean4)<0.0001$0 mswhenever you want5Almost limitlessNo – 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. Base uses Flashblocks that splits a 2 seconds block into ten 200 milliseconds blocks, in the Flashblocks FAQ, they claim that it is very rare that a flashblock fails to be included in a final block, but it's possible, this even it's called reorg, so the actual finality is still 2 seconds. You can read more technical details, for example, here. ↩ ↩2

  4. 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 1000 batched transactions. Read more in the docs. ↩ ↩2 ↩3

  5. The settlement is done through the z402 smart contract, so users can know immediately if a payment is valid or not (i.e. if it will be settled or not), but the actual settlement time is chosen by the seller, the more they wait, the more they can batch transactions and save on blockchain fees. So, once the payment proof has been submitted, the settlement time is the settlement time of the blockchain (as for x402), the best strategy is to submit the payment proofs during execution or at later moment, this way the task execution is not delayed at all. ↩ ↩2 ↩3