The Double-Spending Vulnerability

The core issue with the current x402 implementation is a race condition between payment verification and blockchain settlement. Because a client can mint multiple signatures against a single wallet, a malicious actor can initiate thousands of requests before the first transaction settles. If a provider performs the requested work (such as running an expensive API job) before settlement, they risk providing services for free. While providers can mitigate this by waiting for settlement before starting work, this introduces latency that is unacceptable for many real-time agentic use cases.

Standards Conflict and Billing Rigidity

Jan Curn identifies two major architectural friction points in the current ecosystem:

• Status Code Collisions: x402 mandates an HTTP 402 response, while the Model Context Protocol (MCP) requires 401. Because a single endpoint cannot return both, developers are forced to stand up separate hostnames for different payment providers—an antipattern that complicates infrastructure and maintenance.
• Billing Inflexibility: The original 'exact' payment scheme is ill-suited for metered billing, where jobs vary in duration and resource consumption. While the 'up to' scheme attempted to address this, it failed to solve the underlying double-spending window. Apify’s current workaround—charging in full and refunding the remainder—is inefficient as it requires two blockchain transactions and introduces unnecessary trust assumptions.

The Agent General Interface (AGI) Approach

To bypass these limitations, Apify developed an 'Agent General Interface' (AGI). Instead of forcing agents to interact with a rigid, version-locked API, Apify provides a markdown-based instruction page that agents can parse to understand how to purchase prepaid tokens. By decoupling the payment mechanism from the primary API, Apify allows agents to buy a token (e.g., $5 worth of credit) which they can then use across existing API or MCP channels. This approach provides a flexible, agent-readable layer that avoids the need for constant, breaking API changes while the underlying payment standards continue to evolve.