Mahshar

Mahshar

The API marketplace for humans and autonomous agents, powered by USDC on Arc.

Mahshar lets API providers monetize existing endpoints without rebuilding billing infrastructure. Buyers and autonomous agents can discover APIs, pay per call in USDC, and receive responses through Mahshar's payment-aware proxy.

• Live: https://mahshar.xyz
• Network: Arc Mainnet
• Chain ID: 5042

What Mahshar Does

For sellers:

• List an existing API without changing its backend.
• Set a USDC price per call.
• Support public or credential-protected upstream APIs.
• Keep upstream credentials hidden from buyers.
• Track calls, earnings, and withdrawal state.
• Receive seller earnings through the marketplace accounting flow.

For buyers and agents:

• Discover APIs programmatically.
• Inspect machine-readable API metadata.
• Pay per request using USDC.
• Retrieve responses tied to the exact purchase.
• Never receive the seller's upstream credentials.

Public Discovery and Buyer Application

Mahshar provides crawlable public discovery surfaces without requiring a wallet connection:

• Marketplace for browsing active pay-per-call APIs.
• What is Mahshar? for a public overview of the marketplace and payment-aware API access.
• For API Providers for provider education and the path to listing an existing API.
• Stable API detail URLs at /apis/ / .
• Public agent guidance, documentation, and support.
• robots.txt and a generated sitemap for public discovery.

The public discovery layer is isolated from wallet authentication, payment execution, and proxy behavior. The wallet-enabled /buyer application remains the place to connect a wallet and execute paid API requests.

Supported Upstream Authentication

The Client Credentials profile must be enabled by the operator. Authorization Code + PKCE is present in the implementation but disabled in Production. An active provider connection does not activate a listing; publication still requires verification. Stored credentials and tokens are server-side data and are not included in buyer responses or public discovery metadata. Provider authentication details.

How a Paid API Call Works

Buyer / Agent

→ Discover API → Request paid endpoint → x402 payment requirement → USDC settlement → Canonical target authorization → Seller credential injected server-side where required → Upstream API → Durable purchase-scoped response → Buyer / Agent

Settlement, delivery, and response recovery have distinct durable identities. A recovery capability can retrieve only the response associated with its exact purchase.

Beyond the Arc Reference Apps

circlefin/arc-commerce demonstrates purchasing application credits with USDC, while circlefin/arc-p2p-payments demonstrates wallet-based peer-to-peer payments.

Mahshar adds application-layer primitives for machine-readable paid API discovery, MCP-native discovery and externally signed execution, x402 pay-per-call API monetization, canonical upstream authorization before credential injection, server-side seller credential isolation, prepared-call integrity, purchase-scoped response recovery, and durable payment, settlement, accounting, and delivery state handling.

Mahshar composes existing x402, MCP, Circle Gateway, USDC, Arc wallet, CCTP, and bridge infrastructure; it does not claim to have invented those technologies. See Reusable Arc primitives for implementation boundaries, verification status, and extraction requirements.

Arc Mainnet

Mahshar's production network is Arc Mainnet, chain ID 5042 (eip155:5042). Marketplace prices, buyer payments, platform accounting, and seller earnings are denominated in USDC.

Public Arc Mainnet Verification

Mahshar-owned:

• Platform EOA: 0x052650D1764406d702252B20B2294346A594A1ef
• Successful Arc Mainnet transaction: 0xa3efb83ad9ac4f2164d36b2579104cb7fb19c986cd623206b27387330e33fa33

The public address above is Mahshar's platform wallet on Arc Mainnet. The linked historical transaction is a successful call from that wallet to the official Arc Memo contract and can be independently verified in the Arc explorer. It is evidence of Mainnet operation and is not presented as independent proof of an x402 buyer purchase. Private signing material is never committed to the repository.

Automatic Memo writes have been removed. The linked transaction remains historical Mainnet evidence; paid API execution relies on Circle Gateway settlement and durable purchase, delivery, and response records, with no auxiliary platform-wallet transaction.

Official Arc/Circle contracts currently used by Mahshar:

These are official system contracts, not Mahshar contracts. Mahshar currently deploys no custom smart contract.

The installed Circle x402 runtime requires explicit Arc Mainnet RPC configuration and its current Mainnet compatibility settings. See .env.example and agent integration for the repository's operational contract.

Wallet Authentication

Normal browser authentication is designed to avoid repeated signature prompts:

Connect wallet

→ Sign one login challenge → Fixed eight-hour authenticated session → Use normal marketplace features without repeated wallet prompts

The server stores an opaque, wallet-bound session in an HttpOnly cookie. The session has a fixed expiry and does not become permanent through activity. Wallet changes isolate private state and require authentication for the newly connected wallet.

Fresh operation-specific signatures remain required for:

• Seller withdrawals.
• endpoint_url changes.
• auth_type changes.
• Stored credential, OAuth configuration, or provider connection changes.
• Authentication parameter-name changes.
• HTTP method changes.
• Dynamic-path, path-parameter, or query-parameter security-contract changes.

Normal navigation, private reads, and edits to names, descriptions, categories, prices, examples, documentation, and other presentation fields use the existing session.

Security Architecture

Mahshar includes layered controls for payment-aware proxying and wallet-scoped marketplace data:

• Canonical upstream target validation before credential injection.
• Traversal and encoded-traversal rejection.
• Declared dynamic-path and query-parameter contracts.
• Duplicate-query and credential-query collision protection.
• Seller credential non-disclosure.
• Purchase-scoped response recovery.
• Durable x402 settlement and delivery state.
• Atomic seller withdrawal reservations.
• Durable fencing for ambiguous external execution.
• Wallet-scoped private buyer and seller data.
• Independent wallet and trusted-IP rate-limit buckets where applicable.
• Bounded serialized response delivery.
• A bounded declarative path/query matcher rather than arbitrary request-path JavaScript regular expressions.
• Bounded response-retention and wallet-authentication pruning.
• Origin and Fetch Metadata checks for session-authenticated mutations.
• Fresh one-use operation authorization for sensitive listing changes.

These controls reduce identified risks; they are not a claim that the system is vulnerability-free. See Security documentation and SECURITY.md.

API Response Safety

Seller verification measures a representative serialized response. A response near Mahshar's delivery limit produces a seller-visible warning, and an over-limit representative response cannot complete verification. The runtime serialized-response limit remains authoritative for every paid delivery.

Verification observes one response and cannot guarantee that the upstream API will return the same size later.

Seller Withdrawals

Before external withdrawal work begins, Mahshar creates an atomic database reservation against the seller's currently available earnings. Concurrent requests cannot reserve the same earnings twice.

If submission or mint execution becomes ambiguous, the reservation remains locked in a recoverable submission_unknown or mint_unknown state. Confirmation and reconciliation are idempotent, and ambiguous money-moving operations are not blindly retried. The dashboard presents a status-check action instead of offering a duplicate withdrawal.

Machine Discovery

Autonomous clients should start with the public discovery endpoint and its current machine contract:

• MCP V1 endpoint: https://mahshar.xyz/api/mcp (stateless discovery through search_apis and get_api, real x402 challenge preparation and externally signed replay through execute_api_call, and purchase-capability recovery through get_purchase_response). Mahshar never accepts buyer private keys, signs automatically, or takes custody. A scripted external MCP Canary verified four paid Production executions covering HTTP Basic, custom API-key header, custom Authorization token, and multiple credential headers. All four responses and purchase-scoped recoveries succeeded, with matching application accounting and no observed duplicate payment or credential exposure. Gateway nanopayment balances updated; final onchain batch settlement was not independently verified. This was a scripted harness, not a fully autonomous AI agent. Earlier external-client verification also covered same-authorization replay without duplicate payment.
• OpenAPI document
• Agent integration guide

Runtime discovery and OpenAPI URLs are generated from the configured canonical marketplace origin.

Admin Acquisition

The first bounded Production mock canary completed successfully. Continuous draft-only acquisition is deployed. Execution follows operator-approved configuration and Admin Start/Stop controls. All server-only acquisition flags default to false; the existing bounded Discovery Worker remains the default. Enabling acquisition flags requires separate operator approval; deployment does not start the Worker. The consumed canary and historical invitations remain preserved.

The Brevo acquisition delivery integration is deployed with real sending disabled by default. Immutable acquisition drafts and simulated results remain separate from ordinary Admin Outreach messages. A separately authorized real del