MoltsPay primary sources — 2026-05-03

Project status in this pass

  • No canonical standalone MoltsPay whitepaper or litepaper surfaced.
  • The clearest current sources of truth were the official site, developer guide, canonical TypeScript and Python READMEs, package manifest, and browser-demo README.
  • MoltsPay is best understood as an agent-payments control plane that packages both provider-side monetization and buyer-side payment execution across multiple chains and payment schemes.

Primary-source snapshots

1) Official homepage / top-level positioning

  • URL: https://moltspay.com/
  • Key excerpt:
    • The homepage says developers can “add one JSON file” to turn a skill into a paid service.
    • It highlights gasless payments, x402, multi-chain support, testnet flows, service-discovery APIs, and a no-signup playground.
    • It positions MoltsPay as infrastructure for an “Agent Economy” built by Zen7 Labs.
  • Why it matters:
    • This is the clearest first-party statement that the project is trying to be a reusable machine-commerce layer rather than just a sample app.

2) Developer guide / provider and buyer workflow

  • URL: https://moltspay.com/docs
  • Key excerpt:
    • The docs split the product between creators/providers and AI agents/buyers.
    • Providers publish services with moltspay.services.json, validate configs, add CDP credentials, and expose a .well-known/agent-services.json manifest.
    • Buyers use CLI or SDK methods like .pay(), .discover(), .balance(), .limits(), .faucet(), and .fund().
  • Why it matters:
    • The docs show that MoltsPay is packaging both sides of a paid-service marketplace: publication, discovery, payment, and execution.

3) Canonical TypeScript README / multi-chain operational surface

  • URL: https://raw.githubusercontent.com/Yaqing2023/moltspay/main/README.md
  • Key excerpt:
    • The README describes MoltsPay as “Blockchain payment infrastructure for AI Agents” and says it can turn any skill into a paid service with one JSON file.
    • It documents several chain-specific payment paths: x402 + CDP on Base and Polygon, server-fee-payer flows on Solana, BNB intent-style flows, and MPP on Tempo.
    • It also documents CLI flows for providers and buyers, MCP support, spending limits, and browser-wallet support.
  • Why it matters:
    • This is the strongest first-party proof that MoltsPay is broader than a single-chain SDK or one-off wrapper.

4) Python README / second implementation surface

  • URL: https://raw.githubusercontent.com/Yaqing2023/moltspay-python/main/README.md
  • Key excerpt:
    • The Python README exposes the same buyer-side flow in a different language: MoltsPay().discover(...), MoltsPay().pay(...), chain selection, faucets, limits, and LangChain integration.
    • It repeats the multi-chain coverage and emphasizes that clients never pay gas in the supported happy paths.
  • Why it matters:
    • A separate maintained Python surface suggests the project is trying to become real infrastructure for autonomous software rather than just a JavaScript experiment.

5) Package manifest / exported modules and binaries

  • URL: https://raw.githubusercontent.com/Yaqing2023/moltspay/main/package.json
  • Key excerpt:
    • The package exports root, server, client, web, chains, wallet, facilitators, and MCP modules.
    • It also exposes both moltspay and moltspay-mcp binaries.
    • Dependencies include Solana packages, @x402/fetch, mppx, wallet libraries, and the MCP SDK.
  • Why it matters:
    • The package structure makes the project look like a real modular payments stack rather than a single CLI.

6) Browser demo README / wallet and cross-VM abstraction layer

  • URL: https://raw.githubusercontent.com/Yaqing2023/moltspay/main/examples/web/README.md
  • Key excerpt:
    • The demo supports EIP-1193 wallets for EVM chains and Phantom via wallet-adapter for Solana.
    • It documents Tempo permit handling, BNB approval handling, and the use of one client surface across several chains.
  • Why it matters:
    • This shows MoltsPay is also trying to solve browser-native, user-wallet-driven payments in the same stack, not just backend automation.

Working conclusion

MoltsPay is best cataloged as a multi-chain agent-payments control plane. The decisive evidence in this pass was the combination of provider manifests, buyer SDKs, chain-specific payment schemes, browser and MCP surfaces, and a package topology that spans server, client, wallet, facilitator, and agent-host integrations. That puts it closer to a reusable operating layer for machine commerce than to a narrow x402 demo or wallet helper.