Original Source: Waterdrop Capital

Summary

Large models are evolving from tools that answer questions into intelligent agents capable of planning, invoking tools, and delivering results. Meanwhile, stablecoin settlement, HTTP-native payment protocols (HTTP 402), and smart wallets are beginning to combine into a payment infrastructure designed for machines. A program can receive a quote at runtime, sign an authorization, and complete a micropayment—something that was merely a concept just a few years ago but has now become a viable technological pathway.

However, "machines can pay" does not equal "machines can complete transactions." When an intelligent agent needs to purchase search, data, computing power, content generation, or professional analysis services, it still faces challenges such as discovering endpoints, comparing quotes, making cross-protocol payments, controlling budgets, verifying delivery, and unifying reconciliation. Payment rails solve how value moves, but they do not automatically solve how demand finds supply, or whether the correct service was received after payment.

This means that in the next phase of Agent Payment, the competitive focus may no longer be solely on protocol throughput, settlement speed, or how many chains are supported, but rather on whether true machine-buyer infrastructure can be built. This article attempts to discuss why Agent Payment will become an independent track—starting from demand structure, protocol evolution, real-world bottlenecks, and market division of labor—and what key missing links remain before it can achieve scaled adoption.

Introduction: Intelligent Agents Are Gaining a Constrained "Discretionary Budget"

Over the past two years, the capabilities of intelligent agents have evolved very rapidly. Early large models primarily handled information generation—users asked questions, and the models produced text. Subsequently, tool invocation enabled models to search web pages, query databases, execute code, and operate software. Taking it a step further, intelligent agents began breaking down goals, formulating plans, and adjusting actions based on external results across multiple execution rounds.

When the execution targets were limited to free tools or internal enterprise systems, invocation permissions could be pre-configured by developers. But high-quality capabilities in open markets typically require payment: real-time financial data is priced per call, web scraping consumes credits, inference and GPU computing power are billed by usage, and video generation and professional databases have clear pricing. For an intelligent agent to independently complete a task, it inevitably must become a buyer during runtime.

The traditional API business model was not designed for this kind of buyer. It requires a person to first visit a website, register an account, link a bank card, select a plan, safeguard an API Key, and then place the key into the program environment. Purchasing decisions and actual invocations are split across two points in time: humans complete the purchase before the task occurs, and the software is only responsible for consuming the quota already purchased.

An agent may not know what it needs until it reaches a certain step in executing a task. It cannot predict in advance which data source it will ultimately call, nor should it require the user to open accounts for every potential service one by one. Its procurement is characterized by being instant, low-value, multi-merchant, high-frequency, and results-oriented. For it, the most natural experience is not "subscribe first, then call," but "discover the service, get a quote, authorize payment, obtain the result."

Agent Payment is therefore not about adding a payment button to a chatbot. It means software begins to have constrained spending authority and forms a procurement process belonging to machines. Humans set goals, budgets, and risk boundaries, and agents allocate funds within those boundaries. Payment thus shifts from a settlement action to part of the agent's decision-making system.

1. Why Agent Payment Will Become an Independent Track

1.1 From Tool Invocation to Economic Action

The difference between agents and ordinary automation scripts lies not only in reasoning capability. Scripts execute predetermined processes, and the required resources and vendors are usually already written into the code; agents choose paths based on the environment. In the same research task, it may first purchase search results, then based on the results decide whether it needs an industry database, and finally call another model for cross-validation. Each procurement step changes subsequent decisions.

This "execute while procuring" model brings economic choice into software runtime. An agent must not only judge whether a tool is available, but also whether it is worth purchasing: whether the price exceeds the budget, whether response speed meets the task requirements, whether historical fulfillment is reliable, and whether an alternative service is more suitable. Traditional tool routing focuses on capability matching, while machine procurement must also handle price and counterparty risk at the same time. In such transactions, the party bearing the risk is the agent itself: payment may succeed, but the service may not be delivered.

Therefore, the core need of Agent Payment is not unconditional automatic payment, but controllably delegating purchasing power to software. Users will not easily hand over their entire wallet to an agent, but they are willing to set a few dollars of budget for a clear task and allow it to make several cent-level purchases. Large authorizations may still require long-term trust-building, but small authorizations can already create real value.

1.2 Micropayments, High Frequency, and Multiple Merchants Change Payment Economics

The payment infrastructure of the human internet is good at handling relatively low-frequency, higher-value transactions. Credit card networks, payment gateways, and subscription systems all have fixed costs, so merchants often bundle many calls into monthly packages. For API requests worth only a few cents each, the fees, chargeback risk, and account maintenance costs of traditional payments may exceed the value of the goods themselves.

Machine consumption is the exact opposite. An agent can initiate multiple purchases from multiple merchants within minutes to complete a single deliverable. The amount per transaction is very low, but the call frequency is high, and the number of transactions may far exceed that of human consumers. Stablecoins and on-chain programmable settlement provide a new economic foundation for such scenarios: funds can flow around the clock, payment authorizations can be signed by software, and services can be priced directly per call.

More importantly, multi-merchant procurement will change the way competition works in the API market. Subscription models encourage users to remain locked into one vendor for the long term, while pay-per-use allows agents to make dynamic choices for each task. Service providers no longer compete only for annual contracts; they also compete for a momentary need. Price, performance, and fulfillment records may all influence routing results in real time.

1.3 Stablecoins Are Moving from a Medium of Exchange to Settlement Infrastructure

In the early crypto market, demand for stablecoins mainly came from trading and capital flight to safety. As issuance, custody, compliance, and cross-chain infrastructure gradually mature, stablecoins are beginning to enter cross-border settlement, corporate treasury management, and internet-native payments. For machine payments, stablecoins have another special advantage: they are both currency and a digital asset that can be directly operated by programs.

Credit card payments depend on cardholder identity, bank accounts, and geographic networks. Agents themselves do not have the identity of a natural person and cannot independently go through traditional account-opening processes. A policy-constrained wallet, however, can become an agent's funding interface: the operator injects a limited balance, sets per-transaction and per-session caps, and retains freeze and revocation permissions; the agent only signs payments within the authorized scope.

This does not mean that on-chain payments are inherently superior to all traditional payments. Consumer protection, refund mechanisms, privacy, key management, and regulatory responsibility still need to be addressed. But in machine-to-machine, low-value pay-per-use, and global service procurement, programmable stablecoins have clear compatibility. For the first time, they give "calling an interface" and "paying an interface" the opportunity to be compressed into the same network interaction.

2. Payment Rails Have Already Emerged: x402, MPP, and HTTP-Native Transactions

2.1 Turning 402 from a Status Code into a Commercial Interface

HTTP long ago reserved the 402 Payment Required status code, but for nearly 30 years it did not form a general workflow. Machine payment protocols have reactivated this semantics: the client requests a paid endpoint, the server returns 402 and machine-readable payment terms; the client selects an acceptable option, completes signing or payment, and then retries the request with credentials.

The importance of this process lies in the fact that it eliminates the human registration page. Price discovery, payment requirements, and content delivery all occur at the protocol layer that programs can understand. For developers, paid APIs no longer need to build a complete SaaS portal around accounts, plans, and keys; for agents, services can be discovered like ordinary web pages and purchased when actually needed.

x402 is one of the most closely watched open protocols on this path. It organizes payment challenges and credentials around HTTP 402, enabling service providers to collect payment on a per-request basis. MPP, by contrast, starts from a different ecosystem and explores machine-oriented payment methods such as charge and session. The two differ in their specific designs, yet together they validate one direction: machine payments can become part of the application protocol, rather than requiring a separate manual settlement process built outside the application.

2.2 The Long-Term Nature of Payment Rail Diversification

The industry often expects that eventually only one standard protocol, one settlement network, and one payment scheme will remain. But from a merchant's perspective, diversification has long-term rationale. One-off data queries are suited to pay-per-call, while continuous inference or streaming services may be better suited to session-based billing; high-value services require stronger guarantees and dispute handling, while low-value calls care more about speed and cost; different regions and enterprises will also choose different compliance and settlement networks.

The protocol layer will continue to innovate. Merchants may adopt direct debit, pre-authorization, escrow, streaming payments, or batch settlement; networks may make different trade-offs in cost, finality, liquidity, and ecosystem tools. For sellers, this is freedom of choice. For buyers, each new combination adds another integration surface.

The configuration matrix in the figure below is one cross-section of this diversification: protocols/payment schemes form the columns, chains form the rows, and each choice is a payment configuration that requires separate integration, and this table is still widening.

Figure 1: Payment Rail Configuration Matrix Under Fragmentation

So fragmentation is not necessarily going to disappear naturally as the market matures. The bank card market did not end up with only one card organization after long-term development, and cloud computing did not converge on a single vendor. Mature markets usually do not eliminate differences; instead, they form aggregation, routing, and clearing layers on top of those differences. Agent Payment is very likely to follow the same evolutionary path. This split is already measurable. Data from two public explorers (x402scan and mppscan) over the past 30 days (as of September 3, 2026) show: the MPP protocol has 65,591 active buyer wallets on the Tempo chain, x402 has 19,472 on the Base chain, and only 365 wallets appear on both rails, less than 0.6% of MPP protocol buyers and 2% of x402 Base buyers; among them, only 112 completed more than ten transactions on each rail, and a considerable portion are dual-rail aggregators paying on behalf of users with the same key, rather than buyers themselves adopting a second payment rail. Buyers are not flowing across rails; each rail is accumulating its own independent buyer base.

2.3 Seller onboarding is only half the transaction

Payment protocols first lower the barrier for merchants to accept payments. Once an endpoint can publish quotes, verify credentials, and return services, it meets the basic conditions for machine-facing commerce. A growing number of developer tools, data services, and content interfaces are thereby becoming machine-purchasable.

However, payable supply does not mean demand will automatically follow. Merchants solve "how do I collect payments from machines," but agents still must answer "whom should I buy from, which payment method should I use, and how do I confirm delivery after payment." If every buyer has to separately integrate each protocol, prepare funds on different networks, and maintain independent ledgers, machine payments will repeat the complexity of early API integration—just swapping API keys for wallets and protocol adapters.

Real adoption depends on the total friction of the transaction, not just the friction at the settlement step.

3. The industry's real bottleneck: transactions have no closed loop

Figure 2: The complete process of a machine procurement

3.1 The first hurdle: discovering purchasable services

Agents need machine-readable service directories. An effective directory cannot contain only names and URLs; it must also describe endpoint capabilities, inputs and outputs, pricing units, available protocols, latency, geographic restrictions, and update status. Mapping between natural language intent and API parameters is also needed; otherwise, an agent knows it "needs macroeconomic data" but cannot determine which endpoint satisfies the task.

Directories in open markets also face duplication, expiration, and false claims. Any merchant can claim to provide high-quality data, but agents cannot spend days conducting background checks like human procurement staff. The discovery layer must continuously verify whether endpoints are callable, whether quotes are real, and whether descriptions match returned content.

This makes service discovery different from traditional search. Search engines optimize for information relevance, while machine procurement directories must also optimize for tradability: whether capabilities match, whether prices are acceptable, whether payments are compatible, and whether merchants can deliver.

3.2 The second hurdle: understanding and comparing quotes

On the surface, similar APIs can all be priced per call, but in reality quotes are weakly comparable. One charges per request, another charges per result item; one includes model inference in the price, another requires extra payment; still other services bill dynamically based on input length, runtime, or successful results.

An agent cannot simply choose the endpoint with the lowest nominal price. It needs to consider total cost, delivery probability, latency, and outcome quality. If a cheap interface fails repeatedly, retry costs and task delays may make its effective price higher. Quotes should therefore be evaluated alongside service level, historical performance, and task context.

Machine-readable quotes also need to specify validity periods and final amounts. In a dynamic pricing environment, what the agent signs must be a firm commitment, not a vague price range. Operators also need to know the fee composition, including service fees, network costs, and routing fees, in order to set credible budgets.

3.3 The Third Gate: Fund Distribution and Cross-Rail Liquidity

If an agent needs to purchase services across multiple chains and multiple protocols simultaneously, the most straightforward approach is to pre-fund balances on each network. But this fragments a small amount of capital into many pieces. Funds sit idle on networks that are not currently in use, while popular networks may run short on balance; topping up balances involves bridging, swapping, gas, and security operations.

For a single user, this is already cumbersome. For an enterprise managing a large number of agents, the problem is amplified further: how much balance should each agent hold, who is responsible for topping up, how do you prevent funds from being misspent, and how do you aggregate assets and fees across different networks? Without a unified funding layer, the more payment rails there are, the higher the financial complexity becomes.

Ideally, what an agent sees is a single spendable budget, not multiple network balances. The underlying system handles selecting settlement paths, managing liquidity, and providing transparent quotes. The principle is similar to a traveler using one card to spend in different countries: the user cares about the total credit limit and exchange rate, and does not need to pre-open a local account for each destination.

3.4 The Fourth Gate: Policy-Based Authorization

The concern most easily triggered by autonomous payments is whether an agent will spend out of control. The solution is not simply choosing between "complete prohibition" and "complete authorization," but establishing multi-layered policies.

Per-transaction caps limit the loss from a single mistake, session budgets constrain the total spend of a task, merchant whitelists or blacklists control counterparties, category rules restrict what can be purchased, and rate limits prevent abnormal calls within a short period. High-risk or high-value transactions can also trigger manual confirmation. Policies should be set by operators, and agents can only act within the boundaries—they cannot raise limits on their own.

A wallet should also not only handle signing. It needs to be combined with tasks, identity, and audit records to answer "which agent approved this payment, for what task, and under what policy." Otherwise, what the enterprise ends up with is just a string of on-chain transaction hashes, which cannot satisfy internal controls and cost attribution requirements.

3.5 Stage Five: Successful Settlement Does Not Equal Service Delivery

Blockchain excels at proving that funds have moved from one address to another, but it cannot inherently prove that an API returned the correct content. A transaction may complete settlement, yet the server times out, returns an error status, or delivers data that does not match what was advertised. For agents, this is not an edge case—it is the core of procurement risk.

Traditional e-commerce connects payment and delivery through logistics, reviews, and refunds; machine services have no physical logistics—delivery may be nothing more than a transient HTTP response. If payment systems only record the trajectory of funds, and merchants only record their own responses, the market lacks a unified fulfillment view that spans merchants and protocols.

What requires caution is that recording a response does not equal proving quality. But correlating payment with response can at least distinguish basic states such as "paid and received result," "paid but service failed," and "not settled." This is the first layer of fact for building machine transaction credibility.

3.6 Stage Six: Unified Reconciliation and Responsibility Definition

A single task may include a dozen micro-purchases. If each transaction is scattered across different wallets, protocols, and merchant backends, it is difficult for users to know why the final deliverable cost what it did. Enterprises also need to attribute spending to projects, teams, customers, and cost centers, and retain auditable evidence.

A unified ledger should simultaneously record procurement intent, merchants, quotes, authorization policies, settlement results, response status, and failure reasons. It serves not only finance, but also agent optimization. The system can analyze which data sources frequently fail, which routes are more costly, and the typical procurement mix for a given type of task.

When payment is embedded in the reasoning chain, cost becomes a feedback signal for model decisions. Without unified reconciliation, agents can only optimize answers, not the economic process of obtaining answers. A large part of Agent Payment's long-term value comes precisely from this kind of observability.

4. From Payment Protocol to Machine Procurement Layer

4.1 The Core Abstraction of the Future Is Not "Pay," but "Buy"

Payment is an action taken after the object and price are made clear, whereas procurement covers the complete process from demand to acceptance. Exposing a pay() function to an agent only allows it to transfer funds to a known address; exposing a buy() capability means the system can receive demand, discover services, compare options, execute payment, and return verifiable results.

This distinction determines the division of labor in the industry. Protocols provide standardized payment messages, wallets manage signatures and assets, settlement networks move value, directories aggregate supply, and the procurement layer organizes these components into a single task. Any single component is important, but none can independently represent a complete transaction.

The machine procurement layer needs to remain open. It should not require all merchants to migrate to the same protocol, nor should it determine who can be purchased through a closed directory. A more sustainable model is to be compatible with multiple payment rails, disclose routing costs in quotes, and allow agents to choose autonomously based on policy.

4.2 Buyer aggregation may be more important than seller aggregation

Internet platforms typically aggregate supply first, then attract consumers. In machine markets, supply already exists widely in the form of APIs; what is missing is a standardized buyer capable of continuous purchasing. An equipped agent can convert fragmented, occasional demand into a stable transaction flow.

Buyer aggregation also improves the visibility of long-tail services. Human developers tend to use familiar big brands because the time cost of evaluating new suppliers is high; if agents can read standardized capability, price, and fulfillment signals, they can choose more suitable services for each task. This may lower customer acquisition costs for new merchants and also force established merchants to compete on actual performance.

But buyer entry points can also create new platform power. Whoever controls the default directory, ranking, and payment paths may influence traffic allocation. Therefore, the industry needs transparent ranking rules, explainable fees, and portable transaction records. Aggregation can reduce friction, but it should not repackage open protocols into closed channels.

4.3 Building reputation based on real transaction data

Machine buyers make decisions very quickly and cannot rely on lengthy due diligence. They need counterparty signals at the same time a quote appears. Traditional ratings and user reviews can provide reference, but they are easily manipulated by wash volume, sybil accounts, and related parties. If reviews do not require real payment, the cost of attack is especially low. Recent empirical research on ERC-8004—the first permissionless on-chain trust layer for agents—confirms this [6]. The protocol's specification states verbatim that "Payments are orthogonal to this protocol"—reviews by default need not be tied to any real paid transaction, and proof of payment is only an optional field. The result is: on Ethereum, BSC, and Base (as of May 13, 2026), 73.5%, 59.2%, and 90.6% of reviewers, respectively, exhibited coordinated sybil behavior.

A more reliable foundation is outcome records tied to real paid calls: how many settlements a service endpoint has completed, what the response success rate is, what the common latency is, and how high the proportion of no response after payment is. These metrics still cannot fully represent content quality, but they are closer to verifiable facts than self-declarations.

As data accumulates, the market may develop tiered reputation. The first tier is objective transaction status, the second tier is reproducible service metrics, and the third tier is quality evaluation for specific tasks. Agents can choose the required strength of evidence based on amount and risk: a few cents for a data query can rely on statistical signals, while high-value procurement requires guarantees, audits, or dispute resolution.

4.4 Budget strategy will become an important capability for agents

Today, agents are mainly evaluated on answer quality, task completion rate, and tool-calling accuracy. Once they enter paid environments, economic metrics must be added: how much is spent to achieve the same quality, whether the task is completed within budget, when it is worth buying more expensive data, and how to balance speed, cost, and reliability.

This will create new directions for training and evaluation. Agents will not only learn "which tool can answer the question," but also "whether buying this tool is worthwhile given the value of the current task." They may first use low-cost services to filter, then purchase high-quality verification for key conclusions; they may also reduce call frequency when the budget is nearly exhausted, or request additional authorization from the user.

In this sense, Agent Payment is not a financial plug-in outside model capabilities, but part of decision intelligence. A truly mature agent should not only use resources, but also price resources.

5. Possible evolution paths for Agent Payment

5.1 Phase one: developer tools and digital services lead the way

The earliest large-scale scenarios will most likely still be purely digital delivery, such as search, data, proxy scraping, model inference, code execution, storage, and content generation. These services are themselves provided through APIs, have low marginal delivery costs, can complete payment and response within the same network session, and do not involve complex logistics.

Typical amounts at this stage are very small, and users focus on development convenience and task completion rate. The market will quickly validate protocols, but transaction volume may be highly fragmented. Many calls will still be handled by traditional API keys and subscriptions, with machine payments used more for temporary needs, cross-merchant procurement, and long-tail services that cannot be pre-opened as accounts.

5.2 Phase two: enterprise budgets and multi-agent collaboration

When enterprises begin deploying multiple agents, fund management will upgrade from personal wallets to organization-level account systems. Enterprises need to allocate budgets to different roles, control purchasable categories, set approval thresholds, and write expenditures into financial systems. Internal settlement may also form between agents: research agents purchase data, analysis agents buy computing power, and execution agents call external services.

At this point, security and compliance become more important than payment novelty. Enterprises care about key custody, permission isolation, transaction monitoring, vendor review, and audit trails. Only infrastructure that can integrate with existing financial processes can move from experimentation into production.

5.3 Phase Three: Extending from Digital Services to the Real Economy

Air tickets, hotels, logistics, advertising, and professional services may all become procurement targets for agents, but real-world transactions require more complex identity, refund, tax, and dispute handling. Stablecoins can only solve part of the settlement problem; they cannot replace consumer rights and commercial contracts.

Therefore, the industry should not misinterpret "autonomous payments" as eliminating all intermediaries. On the contrary, as transaction value increases, guarantees, insurance, credit, and arbitration will re-emerge—they simply need to be transformed into machine-callable services. The future Agent Payment stack may simultaneously include open payment protocols and traditional financial connectivity, rather than one path replacing the other.

5.4 Phase Four: From Cross-Protocol Routing to Cross-Market Execution

In the long run, what agents purchase is not just an API response, but an outcome. A user might request "generate a credible industry report," and the system would autonomously combine search, databases, translation, models, and verification services. Multiple transactions occur at the underlying layer, while the user only sees the total budget, evidence sources, and final delivery.

This will upgrade payment routing into market execution. The system needs to break down complex goals into procurement portfolios, dynamically replace failed vendors, and optimize between total cost and quality. Protocol compatibility is only the foundation; the real moat comes from demand understanding, transaction data, and execution feedback.

6. Risks and Open Questions

Agent Payment has enormous imaginative potential, but real-world constraints cannot be ignored. The first is security. Prompt injection could induce agents to purchase malicious services, supply chain attacks could replace receiving addresses, and flawed policies could cause massive duplicate payments. Payment actions must be isolated from untrusted content and equipped with limits, simulation, revocation, and anomaly detection.

The second is privacy. Procurement records expose what tasks an agent is performing, and on-chain public data could link user identity with commercial intent. Systems need to minimize sensitive metadata leakage and strike a balance between audit requirements and privacy.

The third is liability. When an agent makes an erroneous purchase, a merchant fails to deliver, or a protocol conversion fails, who should bear the loss? Low-value transactions can accept automated risk, but high-value transactions require clear liability boundaries. A payment network without a dispute mechanism will struggle to enter high-value commerce directly.

Fourth is regulation. Stablecoin issuance, wallet controls, cross-border transfers, and merchant payments are subject to rules across different jurisdictions. Machines are executors, not legal liability subjects. Infrastructure must be able to trace every autonomous transaction back to a clear operator, authorization policy, and source of funds.

Fifth is commercial sustainability. Micropayment revenue is easily eroded by network costs, liquidity, and risk control fees. If platforms subsidize the experience through hidden markups, they undermine buyer trust. Fees must be transparent, and a sound business model must be built through scale, routing efficiency, and value-added services.

These issues do not negate the sector; rather, they show that Agent Payment will not be completed through a single protocol alone. It will ultimately become composite infrastructure for payments, identity, permissions, discovery, reputation, and reconciliation.

7. SELAT: Equipping the Buy Side for Machine-Native Commerce

"SELAT" comes from the Malay word for "strait," such as the Strait of Malacca (Selat Melaka). For centuries, regardless of which port goods came from or which market they sailed to, the mainstream of East-West trade passed through this waterway. SELAT aims to become that strait in machine-native commerce: no matter which rail a merchant docks at, agent demand can flow through here.

SELAT is an AI-native company that chooses to enter machine payments from the buy side. SELAT is the buy-side layer for machine-native commerce. Its core goal is not to create yet another payment rail that requires merchants to migrate, but to enable agents to complete procurement across existing rails. It focuses on two core problems: first, the fragmentation of payment configurations, where rails, protocols, chains, and credentials all differ, requiring a new integration for every merchant; second, the lack of measurement for counterparty risk, since successful settlement does not mean the service has been delivered.

Figure 3: Schematic diagram of the SELAT buy-side layer

To address fragmentation, the SELAT CLI keeps differences in protocols, payment schemes, and settlement networks at the infrastructure layer, allowing agents to complete cross-rail procurement with a single command. Discovery, quoting, authorization, payment, delivery status records, and reconciliation are all incorporated into the same procurement process, and every call is also recorded in the same ledger.

• One treasury, using N payment rails

Agents hold a self-custodied USDC balance, with no need to pre-fund by chain or maintain different clients for different protocols.

• Aggregated Endpoint Catalog

SELAT CLI integrates four third-party service registries—Circle, MPP, Apify, and pay.sh—alongside SELAT's own catalog, enabling agents to discover and compare over 4,000 service endpoints based on real-time intent.

• Hard Spending Caps

Operators can set per-transaction limits and session budgets, and freeze spending permissions at any time; agents cannot raise limits on their own.

• Zero Merchant Migration

Merchants can keep their preferred payment rails and be discovered and purchased from by agents without re-registering with SELAT.

On the funding side, SELAT works with any agent wallet, including Circle and MetaMask agent wallets. SELAT routes each purchase across payment rails such as x402 and MPP, subject to real-time quotes.

7.1 ERC-8004: Correct Primitives, Questionable Signals

ERC-8004 defines three types of registries—identity, reputation, and validation—and allows buyers to submit reviews to sellers. The direction is right, but it explicitly separates payment from reputation: feedback need not come from real transactions, and attaching payment proof is optional.

Empirical research on the deployed ecosystem shows that on Base, 93.8% of reviewers had never made an x402 payment, yet contributed 94.9% of feedback; much of the feedback also exhibits coordinated sybil behavior [6]. Registries record claims, but what buyers truly need is outcomes.

7.2 Reputation Linked to Real Transaction Data Is What Buyers Need

Payment rails can confirm whether funds settled, but cannot see what the service returned; merchants can see their own responses, but cannot see the entire market; registries can list endpoints, but cannot prove that reviews come from real purchases.

The buyer layer that executes purchases is best positioned to connect both ends of a transaction: every purchase completed through SELAT records which endpoint was paid, how much was settled, and post-payment delivery status metadata (2xx, 4xx, 5xx). These records accumulate continuously by merchant and payment rail, forming the data foundation of the "Settlement–Delivery Graph."

A precise distinction is needed: records linking payment and delivery status are not equivalent to independent proof of delivery quality or quote accuracy. But they provide the foundation that registry-based reputation lacks—outcome data tied to real paid invocations.

7.3 Obtaining Counterparty Credibility Before Transactions

Just as people were discussing on X how to design a Google PageRank-like Trust mechanism for the fourth-generation internet, SELAT had already launched the "Transactability Index" on top of its settlement-delivery graph, aiming to give agents runtime access to counterparty credibility data backed by real transaction outcomes.

The index is returned alongside quotes, without requiring agents to pause their tasks and separately investigate merchants. It flags risk without setting up gates for the market: endpoints can still be discovered and purchased, and agents make decisions based on budget, task importance, and risk preference.

Agents don't have time to read brand stories. They need to know before paying: how does this endpoint perform in real transactions? Credibility in machine-native commerce should not come from claims, but from results.

Figure 3: Transactability Signals at the Quote Stage

Currently, SELAT CLI has been adapted for agent runtime environments including Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes, and Grok Bot.

8. Summary: The Machine Economy Needs More Than Just Faster Payment Rails

Agent Payment is at a stage where it is easily overestimated and easily underestimated. It is easily overestimated because technically completing a stablecoin payment does not mean an agent has mature commercial autonomy; it is easily underestimated because once software can purchase external capabilities under clear constraints, the organizational methods, pricing models, and competitive boundaries of the machine economy will all change.

Payment protocols have already proven that machines can receive quotes and complete settlements. The next key step is to expand an isolated payment into a complete procurement: enabling agents to find suitable services, understand true costs, pay across rails within budget, confirm delivery, and turn every transaction into an auditable, learnable record.

The future machine economy will not have just one chain, one protocol, or one wallet. Multi-source supply will persist long-term, and truly valuable infrastructure will help buyers navigate this complexity. Agent Payment needs to combine rails, supply, default payments, and trust mechanisms to convert technical capacity into real demand.

When software begins to act as a buyer, payment is only the first step it takes. The more important question has always been: can it complete a genuinely useful transaction in a controllable, transparent, and verifiable manner.

References

[1] Circle, "Building the Open Agentic Economy," 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, "Counterparty Risk in Agentic Payments: The Unmeasured Half," 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, "Powering AI commerce with the new Agent Payments Protocol (AP2)," 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402 Foundation, "x402: An Open Internet-Native Payment Standard." https://github.com/x402-foundation/x402

[5] Machine Payments Protocol, "MPP: A Machine Payment Protocol Based on HTTP 402." https://mpp.dev/

[6] Xiong et al., "Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem," arXiv, 2026. https://arxiv.org/abs/2606.26028

[7] SELAT official website: https://www.selat.ai

This article is contributed and does not represent the views of BlockBeats.