x402 y MPP: cómo funcionan, en qué se diferencian

Sahil

29 de marzo de 2026 — 10 minutos de lectura

Compartir

Añadir como fuente preferida

x402 Ha sido el nombre que siempre sale a colación cuando alguien quiere pagar un servicio o una API con un monedero en lugar de con una clave API.

Recientemente, Tempo lanzó el MPP (Machine Payments Protocol) y ahora existe una segunda opción con una filosofía de diseño diferente. Se suelen comparar mucho ambas. Las dos se basan en HTTP 402 Se requiere pago, pero resuelven problemas distintos en distintos niveles.

A continuación te explicamos cómo funciona cada una, dónde encajan las herramientas de Quicknode y los aspectos que realmente hay que tener en cuenta a la hora de elegir.

Versión resumida

• x402 En Quicknode puedes acceder a los puntos finales RPC de Quicknode con solo un monedero. Sin cuenta, sin clave API, sin suscripción. Paga con USDC (Base, Polygon, Solana) o USDG (X Layer) y empieza a realizar llamadas.

• MPP, de Tempo , es un protocolo para pagos entre máquinas a través de cualquier API. Cuenta con su propio sistema de desafío/credencial/recibo flow, admite múltiples métodos de pago (Tempo , stablecoins, tarjetas Stripe y Lightning) e incluye un modelo de sesión para la facturación por consumo de alta frecuencia, como RPC.

• Quicknode ofrece herramientas para ambos: @Quicknode/x402 y @Quicknode/x402-solana para x402 y un endpoint compatible con MPP en https://mpp.quicknode.com/ para utilizar con el mpp SDK.

¿Qué es « x402 »?

x402 es un estándar abierto, creado originalmente por Coinbase, que permite el uso de HTTP 402 una especificación real tras décadas de estar «reservada para uso futuro».

La idea es sencilla: un servidor responde con 402 Se requiere pago, el cliente consulta los requisitos de pago, firma una autorización para el uso de una moneda estable, vuelve a intentar la solicitud y el servidor liquida el pago y devuelve el recurso. Todo ello dentro del mismo intercambio HTTP.

Quicknode utiliza x402 para proporcionar acceso autenticado mediante monedero a su infraestructura RPC. No es necesario crear una cuenta en Quicknode . Basta con conectar un monedero que contenga USDC, y la biblioteca de cliente se encarga de todo lo demás: la autenticación, la liquidación de pagos y la gestión de sesiones.

Para qué se utiliza « Quicknode » x402

Dos paquetes de código abierto:

• @quicknode/x402 – Cliente multicadena para JSON-RPC, REST, gRPC-Web y WebSocket a través del proxy Quicknode x402

• @quicknode/x402-solana – Un cliente específico para « Solana » que se integra con « Solana » Kit y Kite

El cliente admite los siguientes modelos de pago:

• pago por solicitud – 0,001 dólares por llamada, sin autorización ni sesión. La opción más sencilla.

• disposición de crédito – Inicia sesión una sola vez con SIWX (Sign-In with X), compra un paquete de créditos con USDC y, a continuación, utiliza esos créditos en cada solicitud. Resulta más económico para un uso continuado.

Hay algo que cabe destacar: la red de pagos está separada de la red RPC. Por ejemplo, puedes pagar con USDC en Base Sepolia y realizar consultas en Ethereum ,mainnet, Solana, Aptos, Flow o cualquiera de las más de 140 redes blockchain compatibles. La misma cartera, la misma autenticación: flow.

x402 disposición de crédito flow

Un cliente que utiliza @quicknode/x402 primero solicita un recurso al proxy Quicknode x402 (como RPC, REST, gRPC-Web o WebSocket) y obtiene un 402 Se requiere pago respuesta. A continuación, el cliente realiza la autenticación SIWX, recibe un token de sesión JWT y envía una credencial de pago. El proxy envía dicha credencial al facilitador de x402 para verificar y liquidar el pago; a continuación, carga los créditos tras la confirmación. El cliente vuelve a intentar la solicitud original con el token de sesión. El proxy la reenvía a la infraestructura de Quicknode , recibe la respuesta y devuelve un código de estado 200 OK al cliente, consumiendo 1 crédito.

¿Qué es el MPP de Tempo?

El MPP (Machine Payments Protocol) adopta un enfoque más amplio. Mientras que el protocolo « x402 » surgió como una forma de monetizar los puntos finales individuales, el MPP pretende estandarizar la forma en que cualquier máquina realiza pagos a cualquier otra máquina a través de HTTP.

El protocolo utiliza directamente el marco de autenticación HTTP:

• WWW-Authenticate: Pago La información incluida en la respuesta 402 indica al cliente qué pago debe realizar

• Autorización: Pago en el nuevo intento se adjunta el comprobante de pago

• Recibo de pago El código de respuesta 200 demuestra que el servidor ha aceptado el pago

Se trata de un borrador de Internet de la IETF (elaborado por Tempo Labs y Stripe), lo que significa que están trabajando para convertirlo en un estándar real, y no solo en una convención de SDK .

Métodos e intenciones

El MPP distingue entre la forma de pago y el tipo de pago:

• Un «método» es el canal de pago: tempo (monedas estables en la cadena de bloques Tempo ), raya (cartas), rayo (Bitcoin), o a medida.

• Una «intención» es el patrón de facturación: cargo (una sola vez por solicitud) o sesión (pago por uso según el canal).

Esto es importante porque permite combinar diferentes opciones. Una sola API endpoint puede aceptar tanto stablecoins de Tempo como tarjetas de Stripe. El servidor indica todas sus opciones en el desafío 402, y el cliente elige la que sea compatible.

En el caso concreto de Tempo , el sesión Lo interesante es el enfoque. En lugar de liquidar una transacción en cadena por cada solicitud, el cliente deposita fondos en un contrato de depósito en garantía y, a continuación, firma vales fuera de cadena a medida que consume recursos. El servidor verifica cada vale con un único ecrecover Llamada; sin RPC, sin consulta a la base de datos, solo CPU. La liquidación se realiza por lotes cada vez que el servidor decide cerrar el canal. Para algo como la facturación de un modelo de lenguaje grande (LLM) por token, esto resulta mucho más práctico que pagar en la cadena por cada fragmento.

Cargo del MPP flow

En el MPP cargo flow, un mppx El cliente solicita un recurso a un servicio MPP y recibe un 402 respuesta con un WWW-Authenticate: Pago reto. A continuación, el cliente completa el pago a través del backend elegido (por ejemplo, firmando una transacción o pagando una factura) y vuelve a intentar la misma solicitud con Authorization: Payment <credential>, y el servicio verifica esa credencial con el servidor de fondo. Una vez que la verificación se ha realizado con éxito, el servicio devuelve el recurso con 200 OK e incluye un Recibo de pago.

Sesión del MPP flow (canales deTempo )

En el MPP sesión flow En el caso de los canales « Tempo », el cliente abre primero un canal ingresando fondos en el contrato de depósito en garantía Tempo y, a continuación, solicita acceso al servicio. El servicio solicita un vale de sesión, y el cliente responde con un vale acumulativo fuera de cadena firmado. El servicio verifica el vale localmente utilizando ecrecover y comprueba el importe incremental antes de enviar la respuesta. Este ciclo de actualización de vales se repite con gran frecuencia durante el uso y, posteriormente, el servicio cierra el canal en la cadena mediante una liquidación por lotes, tras lo cual se reembolsa al cliente cualquier depósito no utilizado.

Comparación entre ambos

Datos sobre la producción que conviene conocer

x402 en Quicknode

• En pago por solicitud mode, no hay SIWX, ni JWT, ni ningún tipo de estado de sesión. Cada solicitud es independiente.

• El proxy solo procesa el pago una vez que la llamada a los servidores superiores se ha realizado con éxito. Si la llamada RPC falla, no hay que pagar.

• Puedes configurar preAuth: true En la solicitud de crédito mode , realizar la autenticación durante la creación de la cuenta del cliente, en lugar de hacerlo en el primer error 402. Así se ahorra un intercambio de datos de ida y vuelta.

• gRPC-Tanto Web como WebSocket funcionan, pero requieren el modelo de deducción de crédito, ya que se basan en la sesión JWT. Para obtener más información, consulta

  https://x402.quicknode.com/llms.txt

MPP con Tempo

• 402 es solo para los controles de pago. Si el cliente no supera la autenticación, el servidor devuelve 401 . Si el pago se ha procesado correctamente, pero una política impide el acceso, eso es 403 . Esta separación se indica explícitamente en la especificación.

• Un servidor puede devolver varios WWW-Authenticate: Pago Encabezados con diferentes métodos. Un único « endpoint » puede aceptar « Tempo », «Stripe» y «Lightning» simultáneamente. El cliente elige uno.

• En la sesión mode, el Recibo de pago contiene el ID del canal, no un hash de transacción. El hash de la transacción en la cadena se obtiene más tarde, cuando se cierra el canal.

• MPP también funciona a través de MCP (Model Context Protocol) para las llamadas a herramientas de IA. En ese protocolo de transporte, el código 402 se corresponde con el código de error de JSON-RPC 32042 , y ahí se guardan las credenciales y los recibos _meta campos en lugar de encabezados HTTP.

• Para obtener información completa sobre el proxy MPP de endpoint en Quicknode —incluidos los precios, las rutas, las intenciones de sesión frente a las de cargo, las redes compatibles y la configuración del cliente—, consulta

  https://mpp.quicknode.com/llms.txt.

Cuándo usar cada uno

Quicknode Admite ambas opciones. Ninguna de ellas requiere una cuenta. La elección depende de con qué otras aplicaciones Agente/aplicación se comunica con qué otros servicios.

Si tu principal necesidad es acceder a datos de la cadena de bloques, utiliza x402. El @quicknode/x402 El cliente ofrece los protocolos de transporte JSON-RPC, gRPC-Web y WebSocket, facturación por paquetes de crédito e integración con el kit « Solana » a través de @quicknode/x402-solana. Se trata de las bibliotecas propias de Quicknode, creadas específicamente para su proxy x402 .

Si tu Agente paga por varios servicios, Quicknode para RPC, un proveedor de LLM para la inferencia y una API de búsqueda para la recuperación. MPP te permite utilizar un único protocolo y un único monedero para todos ellos. El MPP de Quicknode endpoint en https://mpp.quicknode.com/ funciona igual que mppx el cliente que se utilizaría para acceder a cualquier otro servicio compatible con MPP.

No hay ningún motivo por el que no puedas utilizar ambos. « x402 » para tu capa de infraestructura y MPP para las API que desarrolles sobre ella.

Código: cómo es en realidad

Quicknode x402 (TypeScript)

import { createQuicknodeX402Client } from '@quicknode/x402'

// Initialize x402 client for Base Sepolia
// Wallet needs testnet USDC — get it via POST /auth (SIWE) then POST /drip
const client = await createQuicknodeX402Client({
  baseUrl: 'https://x402.quicknode.com',
  network: 'eip155:84532',
  evmPrivateKey: process.env.PRIVATE_KEY as `0x${string}`,
  preAuth: true,
})

// Make a paid RPC call — payment is handled automatically
const res = await client.fetch('https://x402.quicknode.com/base-sepolia', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_blockNumber',
    params: [],
  }),
})

// Print the result
console.log(await res.json())

Quicknode x402 para « Solana » (TypeScript)

import { createSolanaX402Clients } from "@Quicknode/x402-solana"
import { address } from "@solana/kit"
import { homedir } from "node:os"

const { rpc } = await createSolanaX402Clients(
  "mainnet",
  `${homedir()}/.config/solana/id.json`,
)

const balance = await rpc
  .getBalance(address("dDCQNnDmNbFVi8cQhKAgXhyhXeJ625tvwsunRyRc7c8"))
  .send()
console.log("Balance:", balance.value)

MPP con el mppx CLI

# create a wallet (stored in keychain)
npx mppx account create

# charge intent — $0.001/request, one on-chain tx per request
npx mppx -X POST -H 'Content-Type: application/json' \\
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \\
<https://mpp.quicknode.com/base-sepolia>

# session intent — $0.00001/request, off-chain vouchers
npx mppx -X POST -H 'Content-Type: application/json' \\
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \\
<https://mpp.quicknode.com/session/base-sepolia>

MPP del lado del cliente (TypeScript)

import { Mppx, tempo } from 'mppx/client'
import { privateKeyToAccount } from 'viem/accounts'

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)

// Polyfills globalThis.fetch — handles 402 challenges automatically
Mppx.create({
  methods: [tempo({ account })],
})

// Charge intent ($0.001/req) — payment is transparent
const res = await fetch('https://mpp.quicknode.com/base-sepolia', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_blockNumber',
    params: [],
  }),
})

const { result } = await res.json()
console.log('Block number:', BigInt(result))

Sesión de MPP « mode » (TypeScript)

import { Mppx, tempo } from 'mppx/client'
import { privateKeyToAccount } from 'viem/accounts'

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)

// deposit 0.10 PathUSD into a payment channel
// first request opens the channel on-chain, subsequent ones use off-chain vouchers
Mppx.create({
  methods: [tempo({ account, deposit: '0.10' })],
})

const res = await fetch('https://mpp.quicknode.com/session/base-sepolia', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_blockNumber',
    params: [],
  }),
})

console.log(await res.json())

Conclusión

x402 y MPP están estrechamente relacionados y resuelven el mismo problema fundamental: proporcionar acceso de pago a una API a través de HTTP.

Para el proxy RPC de Quicknode , se puede utilizar cualquiera de los dos. La diferencia práctica radica en el estilo de implementación. x402 se basa en un modelo de facilitador, mientras que MPP elimina esa dependencia y enmarca el flow como un esquema formal de autenticación HTTP.

Enlaces

• @Quicknode/x402 en GitHub

• @Quicknode/x402-solana en GitHub

• Quicknode x402 guía

• x402 repositorio del protocolo (Coinbase)

• Documentos del MPP

• Método de pago del MPP « Tempo »

• Referencia de la CLI de mppx

• Borrador de la IETF: Esquema de autenticación HTTP «Payment»

• Quicknode MPP endpoint