Open Source Agentic Protocols
Introduction
What if artificial intelligence could not only run itself - but fund and expand it's own evolution?
Sahara x402 turns infrastructure into a self-propelling economy, where agent infrastructures like compute, storage and agent tools provide agent friendly interfaces, paid at true marginal cost.
Three extensions on the top of x402 make this possible:
x/function - serverless: pay-per-deploy serverless workloads that launch new Agents or functions instantly.
x/function - verifiable: verifiable execution that proves every result was computed honestly.
x/function - customized policy: programmable collaboration rules that define how agents trade, share, or restrict their own data and capabilities.
From there emerges a new kind of network:
Agents that buy, sell, spawn, and verify intelligence without the need of human involvement — brand-new economy of self-funding, self-expanding, self-proliferating agents.
Extension 1: The x/function-serverless-modular deployment for fair value distribution
Background
The x/function extension provides an agent (buyer) a standard way of creating and invoking computation workloads (for example, spawning another agent) by leveraging the existing x402 payment and authentication flow. Instead of just granting access to a pre-existing API, x/function uses the x402 mechanism to dynamically deploy and execute arbitrarily new, on-demand serverless functions.
In short, x402 standardizes payment-for-access, while x/function extends this to standardize payment-for-deployment-and-access, turning any x402-enabled endpoint into a potential serverless platform for launching arbitrary agents.
Who is the x function for?
AI Developer: Focus solely on AI innovation, freed from the burdens of server setup, operations, and billing. Our system deploys instances on-demand for each function call, with infrastructure costs directly billed to the buyer.
Retail User: x402 unlocks access to highly customized services that simply didn’t exist before, because no one wanted to host or maintain a dedicated server for a tiny, one-off use case.
With Sahara x402’s pay-to-spawn model, anyone can request a personalized agent or micro-service, pay only for the seconds it runs, and retire it immediately after use.
That means features that were once too niche or too expensive to operate, like a custom data filter or a one-time computation via vibe coding, can now be delivered on demand, at a very low and transparent cost on cloud.
How it Works
Client makes HTTP request - The client sends a standard HTTP request to a service provider for a function call.
Service provider asking the serverless infra to do the cost estimation: The serverless infra estimate the cost based on the function call metadata.
Serverless infra returns the cost estimation.
Server responds with 402 - The service provider returns an HTTP 402 Payment Required status code with payment details in the response body.
Client chooses a payment method.
Client prepares and submits a payment payload based on the provided requirements.
Service provider verifies the payment payload through the facilitator.
Facilitator performs payment verification.
Service provider asks the serverless infra to run the function.
Serverless infra deploys the function and runs it.
Serverless infra fulfills the request with the function result.
Service provider settles the payment and confirms transaction completion.
Facilitator submits the transaction to the blockchain
Transaction is confirmed on the blockchain.
Facilitator returns Payment Execution Response to the service provider.
Service provider returns a 200 OK response to the client with the function result they requested as the body of the HTTP response, and a X-PAYMENT-RESPONSE header containing the Settlement Response as Base64 encoded JSON if the payment was executed successfully.
Extension 2: The x/function-verifiable-trustless compute for secure agent workflows
Background
The x/function protocol provides a powerful standard for dynamically deploying and invoking serverless workloads via the x402 payment flow. This enables a "pay-per-deploy" model where users, not developers, fund the computation they consume.
However, the base x/function protocol operates on an implicit trust model. The agent (buyer) paying for the computation must trust that the Function Provider:
Executes the correct function metadata.
Executes it faithfully without tampering.
Returns an honest result.
This trust assumption is a significant barrier for dApps, decentralized systems, and any high-stakes computation where the integrity of the result is critical. A malicious or compromised provider could return incorrect data, posing a severe security risk.
The TEE based and verifiable Extension
The x/function/verifiable extension addresses this gap by introducing a standardized convention for verifiable computation. It extends the x/function flow to ensure that the execution of a workload is not just paid for, but cryptographically(or other methods like TEE) proven.
This extension modifies the core x/function interaction:
Secure Execution: The Function Provider must perform the deployment and computation within a secure environment (such as a TEE, ZK-VM, or other provable system).
Proof of Execution: The provider's response, along with the function's result, must include related work proofs.
Client-Side Verification: The agent (buyer) is now required to perform a verification step on these proofs before handling or trusting the API result.
This transforms x/function from a simple pay-for-compute mechanism into a robust "pay-for-verified-compute" protocol, enabling a truly trustless ecosystem for on-demand serverless workloads.
Why It Matters
Trustless verification makes x402 ideal for decentralized multi-agent coordination and AI marketplaces. When an agent pays another to compute, you can cryptographically prove that the computation actually happened — and that its result wasn’t tampered with.
This shifts agent interactions from “trusted APIs” to “provable intelligence.”
How it Works
Extension 3: The x/function-customized policy-programmable governance for programmable agent workflows
Background
As autonomous agents begin to exchange data or pay for computation across the Sahara network, a new challenge emerges: not every transaction should follow the same rulebook.
A historical transaction data provider may allow its data to be used for analysis, but never for generation. A blockchain analytics dataset might allow aggregated insights, but forbid any instance-level address or transaction export. Meanwhile, some agents may simply want every usage recorded transparently on-chain.
Until now, these rules relied on trust or manual verification. The customized policy extension introduces a new standard that lets every agent, function, or dataset define its own “terms of use” policy directly in the protocol. The rules can be checked automatically, creating compliant and verifiable conditions for collaboration.
How it works
Each agent, function, or dataset provider publishes a Policy Manifest - a declaration that describes how its resource may be used by a requesting agent (buyer). Policies can include operational limits (e.g. no data retention), usage boundaries (e.g. output binary labels only), or accountability rules (e.g. log usage on-chain).
When another agent wants to use the service, it attaches an Intent Claim - a statement that declares how it plans to use the output. Both the requesting and the providing agents set their acceptable forms of the Claim: from self-reported intents, source code, to TEE enclave measurements. To prevent abuse, every Intent Claim must be cryptographically signed by the same key used for payment, binding the Agent’s declared intent to its verifiable identity on-chain.
Both documents - the provider’s Policy Manifest and the requester’s Intent Claim - are evaluated by a Policy Compliance Verifier, a verifiable program that functions as an off-chain contract. The Policy Compliance Verifier runs inside a secure TEE to protect the confidentiality of the Intent Claims and produce proof of execution. It evaluates the Intent Claim against the Policy Manifest and issues a short-lived authorization key that allows the x/function payment and computation to proceed if the compliance check passes. If not, the request is automatically denied before any data is shared.
The agent, function, or dataset provider (seller) can further ask a requesting agent (buyer) running on a TEE to provide a proof on how a Policy Enforcement Algorithm will be applied to continuously enforce the policy after receiving the requested data.
Why it matters
Customized policy brings governance, trust, and autonomy together in one programmable flow. It lets agent, function, and data providers retain fine-grained control while still participating in an open, decentralized compute economy.
For developers, it removes the need for manual permission handling — policies are enforced by the protocol itself. For data providers, it ensures their assets are used according to their defined purpose, with verifiable evidence of compliance. And for the broader Web3 ecosystem, it introduces a trust layer that extends beyond payment: a way to prove why and how a computation took place, not just that it did.
By cryptographically binding intent, policy, and payment in a single verifiable workflow, Sahara x402 transforms agent interaction into a model of accountable collaboration.
Conclusion
Sahara x402 introduces more than a new payment standard — it defines a new computational economy where agents can deploy, verify, and govern intelligence on their own terms. With serverless pay-to-spawn compute, cryptographically verifiable execution, and programmable policy enforcement, the protocol forms the backbone of a world where autonomous agents collaborate, transact, and evolve without human micromanagement. But this is only the foundation.
Sahara x402 doesn’t just power autonomous computation — it orchestrates entire multi-agent workflows, exactly like the one illustrated in the next page - a user asks a question, a Planner Agent decomposes the task, and every downstream action — from policy checking to social-media querying to TEE-secured graph generation — flows through the same x/function payment layer.
Each agent, tool, and dataset broadcasts its policies; each request carries a signed intent; and a Verifier enforces compliance before any compute occurs. Payments are streamed directly to the developers who built each capability, creating a real-time economy of interoperable, self-contained agents.
This unified protocol turns what used to be a centralized pipeline into a decentralized, policy-aware, pay-per-compute ecosystem, where agents can safely collaborate, transact, and verify one another’s work.
Next, we’ll move beyond the concepts and into reality: concrete demos that show how x402 powers agent collectives, verifiable AI pipelines, and self-funding multi-agent ecosystem that grow on their own.
You can also find our Github repo here: https://github.com/SaharaLabsAI
Last updated