# Pay.sh, x402 and MPP: Agentic Payments Deep Dive > An open operational map of early agentic payments for people and AI agents. --- snapshot: 2026-08-06 language: en format: text/markdown human_report: [paysh-x402-report.html](paysh-x402-report.html) machine_index: [llms.txt](llms.txt) idea_profiles: [ideas.json](ideas.json) market_snapshot: [data/snapshots/2026-08-06-bazaar-summary.json](data/snapshots/2026-08-06-bazaar-summary.json) changelog: [CHANGELOG.md](CHANGELOG.md) --- ## Interpretation constraints - Calls are fields published by the catalogue and are not treated as independently audited accounting payments. - Payer observations are endpoint-level counts and are not unique wallets for a category. - Current price multiplied by calls is an indicative signal, not accounting revenue. - A listed endpoint proves availability, not service quality, sustainable demand, or direct partnership. ## Bazaar snapshot - Endpoint records: 14505 - Hosts: 1504 - Calls published over 30 days: 374409 - Top-10 host call share: 72.7% - Reproducibility: summary-only | Category | Endpoints | Hosts | Payer observations | Calls 30d | Share | Median USD | |---|---:|---:|---:|---:|---:|---:| | Social networks and messaging | 463 | 134 | 951 | 119185 | 31.83% | $0.01 | | Blockchain and market data | 3285 | 560 | 18511 | 100140 | 26.75% | $0.01 | | Search and web data | 1613 | 381 | 4501 | 99495 | 26.57% | $0.02 | | Developer tools | 2016 | 312 | 2999 | 9147 | 2.44% | $0.02 | | AI and generation | 666 | 212 | 1090 | 6383 | 1.7% | $0.05 | | Commerce and actions | 698 | 221 | 1427 | 5718 | 1.53% | $0.01 | | Security and risk | 803 | 181 | 1393 | 3576 | 0.96% | $0.02 | | Compute and storage | 328 | 117 | 495 | 1723 | 0.46% | $0.01 | | Media and content | 214 | 104 | 311 | 709 | 0.19% | $0.014 | ## Product idea catalogue ### A1 — Practical workshop on machine payments One live workshop built around a working endpoint: seller, buyer agent, facilitator, policies, receipts, and measurement of repeat purchases. The format can be adapted for developers, data owners, or product teams. Continue only after payments from an external audience and repeated requests. A full course without your own production case quickly becomes a retelling of the documentation. The content should include x402 V2, MPP, AP2, real catalogues, and the limits of specific networks and providers. Language is a launch channel, not a market boundary. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** developers, product teams, data owners - **Paid job:** Teach a team to run a complete paid-tool flow using a working example - **Team asset:** a working paid endpoint and production case, access to a target audience - **Model:** paid workshop or corporate session - **Time to test:** 2–4 weeks - **Technical burden:** medium - **Operational burden:** medium - **First test:** One live workshop and a repeat request from an external team - **Primary risk:** Documentation repackaging without a production case - **Stop condition:** No external payment or repeat request after the first launch - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [MPP services](https://mpp.dev/services) · [Google AP2](https://ap2-protocol.org/) - [Human card](paysh-x402-report.html#idea-A1) ### A2 — Bazaar Intelligence — рынок как датасет A daily snapshot of Bazaar, MPP, and Pay.sh: new and vanished endpoints, prices, distinct payers, concentration, uptime, and category movement. Outputs: a web dashboard, API, and newsletter; email, a community feed, or a messaging platform can be channels, but not the product itself. Monetisation: a premium cut, API access to a cleaned time series, or B2B competitor monitoring. The defensible asset is a normalised history of hosts/buyers/prices absent from the source catalogues. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** API providers, infrastructure teams, market researchers - **Paid job:** Track demand, pricing, and competitors without cleaning catalogues in-house - **Team asset:** recurring snapshots and a normalized time series - **Model:** premium snapshot, API, or B2B monitoring - **Time to test:** 1–2 weeks - **Technical burden:** medium - **Operational burden:** high - **First test:** Two demonstration snapshots and 10 buyer interviews - **Primary risk:** Open catalogues may be sufficient without a paid layer - **Stop condition:** After 10 interviews, fewer than three teams are willing to pay - **Sources:** [CDP Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) · [MPP services](https://mpp.dev/services) - [Human card](paysh-x402-report.html#idea-A2) ### A3 — Living implementation library A versioned web guide, videos, templates, and a cookbook in one repository: how to launch a paid endpoint, monetize an MCP tool, build a buyer agent, and measure repeat demand. A working demo evolves with x402/MPP and displays its own metrics. This provides distribution and trust for a stronger product — a dataset, API, or consulting offer. A separate PDF, playlist, and recipe collection drift apart too quickly and should not exist as three independent products. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** developers, product teams - **Paid job:** Launch and maintain a paid endpoint from a verifiable recipe - **Team asset:** a maintained demo and implementation library, current protocol expertise - **Model:** open-source library plus implementation services - **Time to test:** 2–4 weeks - **Technical burden:** medium - **Operational burden:** medium - **First test:** One working demo and five external template users - **Primary risk:** Protocol versions can quickly diverge from examples - **Stop condition:** The demo gains no external users and creates no leads - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [MPP services](https://mpp.dev/services) · [Cloudflare Agentic Payments](https://developers.cloudflare.com/agents/tools/payments/) - [Human card](paysh-x402-report.html#idea-A3) ### A4 — Research newsletter on the machine economy A regular analysis of protocols, demand, prices, and working services. A paid edition is viable if it draws on a proprietary time series and helps providers make decisions; a simple news digest competes with free feeds. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** market researchers, API providers - **Paid job:** Receive a recurring verified snapshot of the machine economy - **Team asset:** proprietary data and a regular editorial cadence, recurring snapshots and a normalized time series - **Model:** subscription to a proprietary research-data product - **Time to test:** 1 week - **Technical burden:** low - **Operational burden:** medium - **First test:** Three issues based on proprietary data and three paying subscribers - **Primary risk:** Free news feeds commoditize aggregation - **Stop condition:** Proprietary data does not convert into three paid subscriptions - **Sources:** [CDP Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar) · [MPP services](https://mpp.dev/services) - [Human card](paysh-x402-report.html#idea-A4) ### B1 — Real-time trading intelligence API Funding rates, liquidations, open interest, and normalised signals across multiple venues. Hyperliquid can be the first market, but should not define the whole product. Bazaar contains 231 endpoints across 85 hosts on Hyperliquid/funding topics. The advantage comes not from x402, but from proprietary methodology, data quality, speed, and a result that cannot be reproduced with one public request. The earlier estimate of 100,000 calls per day is not a forecast. The first validation threshold is five independent payers, repeat purchases, and a positive margin after data sources, compute, and settlement. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** trading and risk teams - **Paid job:** Receive a fresh trading signal unavailable from one public request - **Team asset:** high-quality market data and signal methodology - **Model:** per-request or request-bundle pricing - **Time to test:** 1–2 weeks - **Technical burden:** high - **Operational burden:** high - **First test:** Five independent buyers, repeat use, and positive margin - **Primary risk:** No durable data or quality advantage - **Stop condition:** There are no repeat buyers or positive margin - **Sources:** [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-B1) ### B2 — Vertical DeFi liquidity analytics LP optimisation, impermanent-loss calculations, ranges, and backtests on real pools. For Solana/Meteora, 58 endpoints across 19 hosts and 1,907 calls were found: the niche is alive but narrow. The idea works only with a demonstrably better model or proprietary historical data. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** DeFi teams and LP managers - **Paid job:** Calculate LP range, risk, and historical outcome for a real pool - **Team asset:** pool history and a verifiable model - **Model:** per-request or request-bundle pricing - **Time to test:** 2–4 weeks - **Technical burden:** high - **Operational burden:** medium - **First test:** One benchmark against an alternative and a small paid pilot - **Primary risk:** Demand may be too narrow to support the model - **Stop condition:** The benchmark shows no measurable advantage - **Sources:** [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-B2) ### B3 — Vertical language intelligence API Morphology or translation alone is already a commodity: 265 endpoints across 107 hosts were found for language/NLP topics. Keep the idea only as an industry product—for example, normalising documents, catalogues, or support conversations with measurable accuracy. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** teams with vertical documents and support data - **Paid job:** Normalize a vertical document or conversation with measurable accuracy - **Team asset:** a vertical corpus and accuracy benchmark - **Model:** per-request or request-bundle pricing - **Time to test:** 2–4 weeks - **Technical burden:** medium - **Operational burden:** medium - **First test:** One benchmark against an alternative and a small paid pilot - **Primary risk:** No durable data or quality advantage - **Stop condition:** The benchmark shows no measurable advantage - **Sources:** [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-B3) ### B4 — Controlled egress & network diagnostics Safe endpoints: verify access to the client’s own resource from an allowed region, provide a fixed egress IP, measure latency/TLS/DNS, and return an audit log. Residential rotation and “clean IP” offers without strict acceptable-use controls increase abuse and blocking risk. Unit economics depend on network costs, permitted use cases, SLA, and customers' actual willingness to pay. Open data does not support a ready-made revenue model; a small paid pilot with a legitimate use case is required before development. A provider’s existence validates technical feasibility, not demand or open market space. Before an MVP, you need a permitted use case, a customer, and abuse-blocking rules. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** DevOps, security, and network teams - **Paid job:** Test an owned resource from an allowed network and receive an audit log - **Team asset:** a controlled network, abuse policy, and SLA - **Model:** per-request or request-bundle pricing - **Time to test:** 1–2 weeks - **Technical burden:** high - **Operational burden:** high - **First test:** One legitimate use case, one customer, and a paid pilot - **Primary risk:** Abuse, blocking, and high network costs - **Stop condition:** No acceptable paid use case with abuse controls - **Sources:** [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-B4) ### C1 — Vertical Facilitator — settlement for a specific industry A self-hosted facilitator makes sense for a global vertical that lacks its own settlement rules, SLA, routing, or accounting. Examples include a data marketplace, a compute-provider network, or a closed ecosystem of paid MCP tools. CDP already offers a low-cost managed facilitator, so fees alone cannot beat it. A functional wedge is required: a special settlement scheme, batch processing, vendor payouts, reconciliation, or enterprise deployment. Before specific merchants and volume exist, a prototype can use an existing facilitator. A proprietary settlement layer comes later, when it solves a measurable problem rather than existing for infrastructure’s sake. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** vertical marketplaces and provider networks, paid-agent tool platforms - **Paid job:** Run vertical settlement, payouts, and reconciliation under special rules - **Team asset:** a defined vertical, merchants, and settlement volume - **Model:** subscription plus usage or platform fee - **Time to test:** interviews before code - **Technical burden:** high - **Operational burden:** high - **First test:** One merchant workflow on an existing facilitator - **Primary risk:** A managed incumbent provides the function more cheaply - **Stop condition:** A managed solution solves the task without a custom layer - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [CDP Agentic Wallet](https://docs.cdp.coinbase.com/agentic-wallet/cli/welcome) - [Human card](paysh-x402-report.html#idea-C1) ### C2 — Managed deployment for paid tools Deploy from a repository or OpenAPI: middleware, wallet, pricing, secrets, OpenTelemetry, and catalogue publication. Hosting/compute already has 561 endpoints across 195 hosts, so the market does not need “another VPS”. A vertical platform with an SLA, managed updates, and a demonstrably short path to the first payment still has a chance. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** developers, paid-agent tool platforms - **Paid job:** Deploy a paid tool through its first payment with managed runtime and SLA - **Team asset:** managed runtime, observability, and SLA - **Model:** B2B subscription or usage-based SaaS - **Time to test:** 1–2 months - **Technical burden:** high - **Operational burden:** high - **First test:** One deployment through the first external payment with measured SLA - **Primary risk:** A managed incumbent provides the function more cheaply - **Stop condition:** A managed solution solves the task without a custom layer - **Sources:** [Cloudflare Agentic Payments](https://developers.cloudflare.com/agents/tools/payments/) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) - [Human card](paysh-x402-report.html#idea-C2) ### C3 — Vertical monetization gateway Gateway concept: an OpenAPI specification, per-endpoint pricing, and a proxy that creates the 402 flow. MCPay, Foldset, Fluora, ag402, and Pay.sh already cover adjacent parts; multi-protocol support alone is weak differentiation. A specific workflow is needed: pricing, receipts, vendor payouts, analytics, or enterprise deployment. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** existing API businesses, paid-agent tool platforms - **Paid job:** Add pricing, receipts, and payouts to one merchant workflow - **Team asset:** one proven merchant workflow - **Model:** subscription plus usage or platform fee - **Time to test:** about one month - **Technical burden:** high - **Operational burden:** medium - **First test:** One narrow pricing/receipt workflow with a design customer - **Primary risk:** A basic gateway or deployment layer is easy to copy - **Stop condition:** No design partner has a specific unmet pain - **Sources:** [MCPay](https://github.com/microchipgnu/MCPay) · [Pay.sh](https://pay.sh/) · [x402 V2](https://github.com/x402-foundation/x402) - [Human card](paysh-x402-report.html#idea-C3) ### C4 — Task-level Agent FinOps & observability SDK and dashboard: success rate, P99 latency, spending anomalies, attribution by task and sub-agent, cost per success, and quality evidence. Basic analytics already exists with wallet and gateway providers; a strong version connects spend to the task and outcome. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** teams operating spending agents, wallet and gateway providers - **Paid job:** Bind agent spend to task, outcome, and cost per success - **Team asset:** task-level telemetry and quality evidence - **Model:** B2B subscription or usage-based SaaS - **Time to test:** about one month - **Technical burden:** high - **Operational burden:** medium - **First test:** One agent workflow with cost-per-success and quality evidence - **Primary risk:** Wallet providers may absorb most of the functionality - **Stop condition:** Task-level data does not improve cost, quality, or audit - **Sources:** [CDP Agentic Wallet](https://docs.cdp.coinbase.com/agentic-wallet/cli/welcome) · [Privy Policies](https://docs.privy.io/controls/policies/overview) - [Human card](paysh-x402-report.html#idea-C4) ### C5 — Wallet risk & counterparty verification The API checks an address and counterparty before payment: sanctions lists, contract risk, labels, source freshness, and machine-readable evidence for the decision. Sentinel and GuardScan confirm that the category exists, but Bazaar's entire security/risk segment remains small — 3,576 calls in the snapshot. The first test is not a promise of ‘full compliance,’ but one verifiable policy check for a wallet or gateway provider. Price, margin, and liability depend on data sources and the required SLA. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** security, risk, and compliance teams, wallet and gateway providers - **Paid job:** Check a counterparty before payment and retain decision evidence - **Team asset:** licensed risk data and provenance - **Model:** per-request or request-bundle pricing - **Time to test:** 2–4 weeks - **Technical burden:** high - **Operational burden:** high - **First test:** One verifiable policy check for a wallet or gateway - **Primary risk:** The segment is still small and depends on costly risk data - **Stop condition:** Nobody pays for a separate verifiable policy check - **Sources:** [Demand snapshot in the report](#demand-profile) · [Circle Agent Wallets](https://developers.circle.com/agent-stack/agent-wallets) · [Privy Policies](https://docs.privy.io/controls/policies/overview) - [Human card](paysh-x402-report.html#idea-C5) ### C6 — Agent Spend Control Plane — mandate, payment, and evidence The basic version of this idea is no longer new. AP2 defines IntentMandate and PaymentMandate; Coinbase, Circle, Privy, Crossmint, and Pay.sh offer limits, policies, or manual confirmation; PayAI, P402, Valta, and Axiru explicitly sell a control/evidence layer. Therefore, “daily limit + allowlist + approval” is a feature, not a standalone moat. Версия, которую ещё имеет смысл проверять: единый B2B control plane, принимающий AP2-мандат и связывающий «кто разрешил → какая задача → какой vendor → какой rail → сколько списано → что получено» . Он не хранит средства, не владеет master key и подключается к существующим signer-ам. Дифференциация — task/result binding, vendor-risk, multi-agent cost allocation, переносимые signed receipts и incident workflow. The first step is not six weeks of development, but 10–15 interviews and one design partner already spending through agent tools. The MVP must close that partner’s specific audit/approval gap on one rail and one wallet provider. Expand to x402 + MPP only after a repeatable paid case. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** teams operating spending agents, wallet and gateway providers - **Paid job:** Bind mandate, task, vendor, charge, result, and audit trail - **Team asset:** a design partner and one wallet/rail integration - **Model:** B2B subscription or usage-based SaaS - **Time to test:** interviews before code - **Technical burden:** high - **Operational burden:** high - **First test:** 10–15 interviews and one paid narrow pilot - **Primary risk:** Wallet providers may absorb most of the functionality - **Stop condition:** The pain reduces to limits and allowlists, or no design partner exists - **Sources:** [Google AP2](https://ap2-protocol.org/) · [Privy Policies](https://docs.privy.io/controls/policies/overview) · [P402 Controls](https://p402.io/product/controls) - [Human card](paysh-x402-report.html#idea-C6) ### D1 — Vertical quality benchmark Not a translation of a general catalogue, but a verified vertical selection: quality benchmark, latency, price, provenance, and a test workflow. Close the general marketplace idea; a vertical search/enrichment/travel catalogue may be part of A2 or H1. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** buyers of vertical API catalogues - **Paid job:** Compare vertical APIs by quality, latency, price, and provenance - **Team asset:** a benchmark, test workflow, and proprietary methodology - **Model:** paid benchmark or monitoring subscription - **Time to test:** about one month - **Technical burden:** medium - **Operational burden:** high - **First test:** One vertical benchmark and three teams using it to choose - **Primary risk:** Supply and demand must be created at the same time - **Stop condition:** Buyers do not use the benchmark for an actual decision - **Sources:** [CDP Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-D1) ### D2 — Managed Agent Workflows A user buys not an “agent”, but a finished result: research, a lead list, monitoring, or a booking. Web, Slack, email, and messengers are interchangeable interfaces. The hard part is SLA, support, credential handling, and recovery from failed actions. As a general store, the idea is too broad. Keep one repeatable managed workflow with a clear outcome price. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** operations teams with a repeatable workflow - **Paid job:** Buy one completed workflow at a clear outcome price - **Team asset:** an operations playbook and vertical access - **Model:** fixed price per verifiable outcome - **Time to test:** 2–3 months - **Technical burden:** medium - **Operational burden:** high - **First test:** One repeatable workflow and three paid outcomes - **Primary risk:** SLA, credentials, support, and failed-action recovery - **Stop condition:** There is no repeat order for the same outcome - **Sources:** [Demand snapshot in the report](#demand-profile) · [MPP services](https://mpp.dev/services) - [Human card](paysh-x402-report.html#idea-D2) ### E1 — Outcome-priced vertical researcher The agent buys search/data endpoints and produces a verifiable report with sources and a budget. Crypto, procurement, travel, or sales are verticals of the same pattern. Research is already broad and competitive in Bazaar; domain methodology and outcome—not the interface—create the advantage. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** buyers of vertical research - **Paid job:** Receive a verifiable vertical report with sources and budget - **Team asset:** domain methodology and a verifiable outcome - **Model:** fixed price per verifiable outcome - **Time to test:** 2–4 weeks - **Technical burden:** medium - **Operational burden:** high - **First test:** One vertical report, three buyers, and a repeat order - **Primary risk:** Generic research is already broad and competitive - **Stop condition:** There is no repeat order for the same outcome - **Sources:** [Demand snapshot in the report](#demand-profile) · [CDP Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar) - [Human card](paysh-x402-report.html#idea-E1) ### F1 — “x402 Linter” — CLI validator for endpoint configurations A free lead-magnet product. Similar to x402scan or Sherlock tools. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** developers - **Paid job:** Validate an endpoint configuration before publishing and receive actionable errors - **Team asset:** current protocol expertise - **Model:** free tool as lead generation - **Time to test:** 1 week - **Technical burden:** medium - **Operational burden:** low - **First test:** 20 external runs and two inbound implementation requests - **Primary risk:** The tool may gain usage without commercial leads - **Stop condition:** Usage creates no integrations, implementations, or contracts - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) - [Human card](paysh-x402-report.html#idea-F1) ### F2 — Python adapters for paid agent tools Open-source adapters for FastAPI, MCP, popular agent frameworks, and messengers where needed. This builds reputation and leads for an integration platform; an SDK tied to a single framework is too narrow for a standalone company. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** agent-framework users - **Paid job:** Connect a paid tool to a familiar framework without hand-building the protocol - **Team asset:** maintained integrations and documentation - **Model:** free tool as lead generation - **Time to test:** 1–2 weeks - **Technical burden:** medium - **Operational burden:** medium - **First test:** Two framework integrations and five external users - **Primary risk:** Protocol versions can quickly diverge from examples - **Stop condition:** Usage creates no integrations, implementations, or contracts - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [MCPay](https://github.com/microchipgnu/MCPay) · [Cloudflare Agentic Payments](https://developers.cloudflare.com/agents/tools/payments/) - [Human card](paysh-x402-report.html#idea-F2) ### G1 — Agent-ready API pack для владельцев данных An existing API or closed dataset becomes a paid endpoint with an OpenAPI/MCP description, discovery metadata, quality tests, and billing. Low integration cost matters, but the offer should sell access to agent demand and product management—not the paywall itself. The package includes code generation, an agent card, deployable image, pricing experiment, and directory publishing. Start as a productized service for data owners, then gradually turn repeatable components into SaaS. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** data owners, existing API businesses - **Paid job:** Turn an existing API or dataset into an agent-ready product - **Team asset:** access to API owners and their real data - **Model:** productized service with later automation - **Time to test:** 2–4 weeks - **Technical burden:** medium - **Operational burden:** medium - **First test:** One data owner, one published endpoint, and one external payment - **Primary risk:** Every integration may remain a custom project - **Stop condition:** After three customers, recurring work still cannot be automated - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [CDP Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar) · [MPP services](https://mpp.dev/services) - [Human card](paysh-x402-report.html#idea-G1) ### G2 — Dual billing & reconciliation Cards and subscriptions remain for people, while x402/MPP serves agents; the product synchronises entitlements, credits, invoices, and receipts. Simply transferring a Stripe plan is insufficient: per-call, session, and subscription require different semantics. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** existing API businesses, paid-agent tool platforms - **Paid job:** Reconcile human and agent billing in one entitlement and receipt ledger - **Team asset:** billing, entitlement, and receipt integrations - **Model:** B2B subscription or usage-based SaaS - **Time to test:** about one month - **Technical burden:** high - **Operational burden:** medium - **First test:** One API with human and agent billing plus reconciled records - **Primary risk:** Different payment models may not reconcile cleanly - **Stop condition:** Existing invoices and wallet receipts are sufficient for the customer - **Sources:** [MPP services](https://mpp.dev/services) · [x402 V2](https://github.com/x402-foundation/x402) - [Human card](paysh-x402-report.html#idea-G2) ### H1 — Agent Data Router — price, quality, provenance One endpoint selects among search, social, and enrichment providers based on budget, freshness, latency, and quality. It adds caching, fallback, deduplication, and signed provenance. Strong market: these three data categories account for 85.15% of Bazaar calls. - **Evidence:** Adjacent — An adjacent need is supported by evidence - **Buyer:** API providers, paid-agent tool platforms - **Paid job:** Choose the best data provider by price, quality, latency, and provenance - **Team asset:** provider benchmarks and routing telemetry - **Model:** per-request or request-bundle pricing - **Time to test:** about one month - **Technical burden:** high - **Operational burden:** high - **First test:** Three providers, one buyer workflow, and a measurable improvement - **Primary risk:** Routing adds no value without measurable quality improvement - **Stop condition:** The router does not improve price, latency, or quality by 20% - **Sources:** [Demand snapshot in the report](#demand-profile) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) - [Human card](paysh-x402-report.html#idea-H1) ### H2 — B2B Enrichment Bundle People/company search, contact discovery, verification, and a confidence score in one result. In the snapshot, individual enrichment endpoints charge $0.15–0.30 and show dozens of payer wallets—one of the densest monetary signals. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** sales, recruiting, and research agents - **Paid job:** Receive one people/company record with verification and a confidence score - **Team asset:** sources, identity resolution, and quality control - **Model:** per-request or request-bundle pricing - **Time to test:** 1–2 weeks - **Technical burden:** medium - **Operational burden:** high - **First test:** One narrow endpoint, five buyers, and a repeat-purchase test - **Primary risk:** Source costs and rules may break unit economics - **Stop condition:** No repeat purchase within 30 days or margin disappears - **Sources:** [CDP Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-H2) ### H3 — Social Intelligence API Search and monitoring for topics, authors, and changes in social data. The category leads in calls, but 110,880 of them are concentrated in one x402.twit endpoint. The opportunity is large; so is dependence on source and platform rules. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** buyers of vertical research, sales, recruiting, and research agents - **Paid job:** Find and monitor a topic, author, or change in social data - **Team asset:** durable access to social-data sources - **Model:** per-request or request-bundle pricing - **Time to test:** 1–2 weeks - **Technical burden:** medium - **Operational burden:** high - **First test:** One permitted source and five external requests with repeat use - **Primary risk:** Market signal is concentrated among a few providers - **Stop condition:** Durable permitted access to the source is unavailable - **Sources:** [Demand snapshot in the report](#demand-profile) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) - [Human card](paysh-x402-report.html#idea-H3) ### H4 — Travel Search & Booking Toolkit Flights, seats, hotels, and later booking/status/refund as one workflow. Travel queries produced 6,313 calls; Google Flights shows 1,058 calls and 40 payers. Start with search and add stateful actions only after manual review. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** travel agents and booking services - **Paid job:** Find a travel option and safely progress to booking, status, and refund - **Team asset:** travel inventory and a safe path from search to booking - **Model:** per-request or request-bundle pricing - **Time to test:** 2–4 weeks - **Technical burden:** high - **Operational burden:** high - **First test:** A search-only pilot with five buyers before booking actions - **Primary risk:** SLA, credentials, support, and failed-action recovery - **Stop condition:** Search gains no repeat buyers before booking features - **Sources:** [Demand snapshot in the report](#demand-profile) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) - [Human card](paysh-x402-report.html#idea-H4) ### H5 — Agent Browser Session Broker Paid browser sessions with time limits, egress policy, secrets isolation, and execution artefacts. Browserbase shows 961 calls and 19 payers at $0.002; StableBrowser, 119 and 18 at $0.10. The signal is early, but closer to real agent work than generic compute. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** agent platforms with browser automation - **Paid job:** Purchase an isolated browser session with limits and execution artifacts - **Team asset:** browser infrastructure, isolation, and incident operations - **Model:** subscription plus usage or platform fee - **Time to test:** 1–2 months - **Technical burden:** high - **Operational burden:** high - **First test:** Five paid sessions and repeat use by two teams - **Primary risk:** SLA, credentials, support, and failed-action recovery - **Stop condition:** Paid sessions gain no repeat use by teams - **Sources:** [Demand snapshot in the report](#demand-profile) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) - [Human card](paysh-x402-report.html#idea-H5) ### H6 — Prepaid Credits & Session Tokens The agent buys a $1–10 credit pack, and repeat operations are charged inside the session without separate on-chain settlement. Apify and CheapTokens already show demand for the prepaid model. The product is especially useful for frequent low-cost calls and multi-provider billing. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** APIs with frequent low-cost calls - **Paid job:** Prepay frequent calls and debit them inside a session ledger - **Team asset:** a credit ledger, session semantics, and reconciliation - **Model:** subscription plus usage or platform fee - **Time to test:** about one month - **Technical burden:** high - **Operational burden:** high - **First test:** One credit pack with confirmed repeat usage - **Primary risk:** Different payment models may not reconcile cleanly - **Stop condition:** Credit packs do not reduce cost or friction for repeat calls - **Sources:** [MPP services](https://mpp.dev/services) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-H6) ### H7 — Signed Evidence & Attestation API Signs the provenance of input data, task parameters, result hash, and verification status. In Bazaar, evidence/attestation signals are still mixed with chain receipts; start with one industry where outcome proof reduces a real dispute or audit cost. - **Evidence:** Inferred — The hypothesis is inferred from an observed market gap - **Buyer:** B2B audit and dispute teams - **Paid job:** Sign inputs, parameters, outcome, and verification status - **Team asset:** signing, provenance, and a vertical audit workflow - **Model:** per-request or request-bundle pricing - **Time to test:** about one month - **Technical burden:** high - **Operational burden:** medium - **First test:** One vertical dispute where evidence reduces audit cost - **Primary risk:** The segment is still small and depends on costly risk data - **Stop condition:** Evidence does not reduce disputes or audit cost - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [Google AP2](https://ap2-protocol.org/) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-H7) ### H8 — Commerce Fulfillment Bridge Gift cards, eSIMs, top-ups, or other digital goods with inventory check, quote, purchase, delivery, status, and refund evidence. Bitrefill, Laso, and BuyWith402 confirm the first payments, but volume is still thin. This is a vertical operations company, not a universal shopping button. - **Evidence:** Observed — A comparable result is already being purchased - **Buyer:** digital-goods providers and commerce agents - **Paid job:** Purchase and receive a digital good with status and refund evidence - **Team asset:** inventory, delivery, refund, and fraud operations - **Model:** take rate on a completed task or transaction - **Time to test:** 2–3 months - **Technical burden:** high - **Operational burden:** high - **First test:** One digital SKU with delivery, status, and refund evidence - **Primary risk:** Refunds, fraud, inventory, and support make this an operations business - **Stop condition:** Refunds and fraud make one SKU unprofitable - **Sources:** [Demand snapshot in the report](#demand-profile) · [Public Bazaar API](https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources?limit=20&offset=0) - [Human card](paysh-x402-report.html#idea-H8) ### H9 — Outcome Jobs, Bounties & Escrow The customer publishes a machine-readable task, budget, and acceptance criterion; contractors or agents compete for payment. x402 batch settlement and receipts provide primitives, but Bazaar shows no broad live demand yet. This is a long-term bet after H7, not a quick MVP. - **Evidence:** Speculative — A long-range bet without confirmed demand - **Buyer:** networks of task buyers and providers - **Paid job:** Publish a task and acceptance criteria, then pay for an accepted outcome - **Team asset:** a participant network and verifiable acceptance criteria - **Model:** take rate on a completed task or transaction - **Time to test:** interviews before code - **Technical burden:** high - **Operational burden:** high - **First test:** 15 interviews before escrow code and one manually paid bounty - **Primary risk:** There is no broad demand for machine-readable jobs and escrow - **Stop condition:** After 15 interviews, no bounty can be paid manually - **Sources:** [x402 V2](https://github.com/x402-foundation/x402) · [Demand snapshot in the report](#demand-profile) - [Human card](paysh-x402-report.html#idea-H9) --- Research and developing by [@Oh_johnny](https://x.com/oh_johnny_ai)