agentwallet-mcp

Billetera EVM del lado del servidor para agentes de IA. Envía transacciones, gestiona tokens e interactúa con contratos inteligentes en múltiples cadenas.

Documentación

Servidor MCP de AgentWallet

Infraestructura de wallet sin permisos para agentes de IA. Crea wallets, firma transacciones y transmite en cadena, en cualquier cadena EVM y Solana. Protecciones integradas. Sin KYC. La única wallet para agentes de IA que acepta cripto para sus propias tarifas de API.

Tus claves pueden permanecer en tu máquina. Configura una variable de entorno y cada firma ocurre en tu propio proceso. Ningún servidor ve la clave, ninguna empresa puede congelar la wallet, y puedes verificar esa afirmación leyendo src/local-wallet.ts o ejecutando el servidor con la API apuntando a un puerto cerrado.

Sin KYC. Sin KYT. Sin proceso de aprobación. Sin monitoreo de transacciones. Nadie puede bloquear tu wallet. Paga con USDC en cadena, sin necesidad de tarjeta de crédito.

Dos modos

Local (autocustodia)Alojado (custodial)
Quién tiene la claveTú, en tu propio procesoCifrada en los servidores de AgentWallet
ConfiguraciónUna variable de entorno, sin cuenta necesariaClave API
CadenasEVM + SolanaEVM + Solana
¿Alguien puede congelarla?NoSí, para eso sirve la pausa
Protecciones de gastoAGENTWALLET_MAX_TX_NATIVE, AGENTWALLET_MAX_TX_TOKEN, AGENTWALLET_MAX_TX_SOL, AGENTWALLET_MAX_AUTOPAYLímites del lado del servidor, pausa, límites de tasa
Muros de pago, uso, facturaciónTambién necesita una clave APIIncluido

Ejecuta wallet_mode en cualquier momento y el servidor te dirá en cuál estás, y qué dirección controla.

Firma local en una variable

{
  "mcpServers": {
    "agentwallet": {
      "command": "npx",
      "args": ["-y", "agentwallet-mcp"],
      "env": {
        "AGENTWALLET_PRIVATE_KEY": "0xyour_key",
        "AGENTWALLET_RPC_8453": "https://your-own-rpc",
        "AGENTWALLET_MAX_TX_NATIVE": "0.05"
      }
    }
  }
}

Usa AGENTWALLET_KEYFILE=/path/to/key en su lugar si prefieres mantener la clave fuera de la configuración de tu shell. La clave se lee una vez, nunca se escribe en disco, nunca se registra y nunca se incluye en un mensaje de error.

AGENTWALLET_RPC_<chainId> (o AGENTWALLET_RPC_URL para todas las cadenas) apunta a un endpoint en el que confíes. Sin él se usa un RPC público, y un RPC público puede ver qué direcciones consultas.

AGENTWALLET_MAX_TX_NATIVE es un límite máximo por transacción en unidades nativas (ETH, MATIC, etc.). En modo alojado el servidor aplica límites; en modo local no hay servidor, así que estas protecciones son las únicas que existen. Configúralas.

AGENTWALLET_MAX_TX_TOKEN es el límite equivalente para movimientos de ERC-20, en unidades humanas del token. Configura también esta si tienes stablecoins. El límite nativo no puede ver una transferencia de tokens: un envío de ERC-20 lleva value = 0 con el monto en los calldata, así que AGENTWALLET_MAX_TX_NATIVE solo deja un saldo de USDC sin límite. AGENTWALLET_MAX_TX_TOKEN cubre transfer, transferFrom, approve, increaseAllowance, Permit2 approve, y deposit() / withdraw(uint256) en el contrato de token nativo envuelto de la propia cadena (para que wrap_eth y unwrap_eth sigan funcionando bajo el límite), las aprobaciones porque una asignación ilimitada es un drenaje a punto de ocurrir. Cualquier otro calldata enviado a un contrato de token o a Permit2 se rechaza mientras el límite esté configurado, porque la protección no puede valorarlo; configura AGENTWALLET_ALLOW_UNKNOWN_TOKEN_CALLS=1 para permitir tales llamadas deliberadamente. increaseAllowance se evalúa sobre el total resultante: la asignación actual se lee primero y la llamada se rechaza si no puede hacerlo, así que dos incrementos conformes no pueden acumular una asignación permanente por encima del límite. Las llamadas a otros contratos (routers, puentes) pasan, ya que solo pueden retirar lo que una aprobación ya permitió; un contrato cuenta como "otro" solo cuando demuestra rechazar decimals(), así que una respuesta absurda o malformada, o un RPC inalcanzable, rechaza en lugar de permitir. Los decimales se resuelven localmente desde el registro de confianza, luego el propio decimals() del token; un token que no se resuelve de ninguna manera se evalúa con 0 decimales, el único valor que no puede fallar abierto. Para un token fuera del registro, el RPC es la única fuente de decimales, y un RPC que no controlas podría escalar el monto y el límite juntos; fija tales tokens con AGENTWALLET_TOKEN_DECIMALS (por ejemplo 8453:0x<token>=6) y la fijación se usa en todos los lugares donde se habría usado la respuesta del RPC.

Firma local en Solana

"env": {
  "AGENTWALLET_SOLANA_KEY": "[12,34...]",
  "AGENTWALLET_SOLANA_RPC": "https://your-own-rpc",
  "AGENTWALLET_MAX_TX_SOL": "1",
  "AGENTWALLET_MAX_TX_TOKEN": "25"
}

Acepta el formato que ya tengas: un array id.json de solana-keygen, una clave secreta base58 exportada por Phantom, o base64. Usa AGENTWALLET_SOLANA_KEYFILE para apuntar a un archivo en su lugar. Las transferencias de SOL nativo y de tokens SPL se firman ambas localmente, y se crea automáticamente una cuenta de token asociada faltante para el destinatario.

Configura cualquiera de las dos claves, o ambas. Son independientes: ejecuta EVM localmente y Solana alojado, o al revés.

Una operación sin clave local coincidente se rechaza, nunca se enruta silenciosamente al firmante alojado. Si tienes una clave EVM configurada y pides una transferencia de Solana sin clave de Solana, el servidor se detiene y te dice qué variable falta. Mover fondos silenciosamente a una clave que no posees, mientras crees que estás en autocustodia, es lo peor que este servidor podría hacer.

Sobre el árbol de dependencias

La firma local usa viem para EVM y @solana/web3.js para Solana, además de bs58 para el análisis de claves. Las instrucciones SPL se construyen a mano en lugar de con @solana/spl-token, porque ese paquete arrastra bigint-buffer, que lleva un aviso de desbordamiento de búfer de alta gravedad. Una wallet no tiene por qué enviar eso para ahorrar una docena de líneas de codificación de instrucciones.

npm audit actualmente reporta problemas dentro de las dependencias de transporte HTTP de @modelcontextprotocol/sdk. Este servidor habla stdio, así que ese código nunca se carga, y el SDK no es algo que este paquete pueda parchear. Ejecuta la auditoría tú mismo. Publicar un árbol que puedas inspeccionar es el punto.

AgentWallet demo, AI agent pays x402 invoice automatically

Características

  • 34 herramientas MCP: crea wallets, envía transacciones, aprueba tokens, envuelve ETH, transfiere tokens SPL, paga y acepta pagos x402, verifica el modo de custodia, y más
  • EVM + Solana: Ethereum, Base, Polygon, BSC, Arbitrum, Optimism, Avalanche, Zora, PulseChain, Solana, y cualquier otra cadena compatible con EVM
  • Tokens SOL + SPL: transferencias de SOL nativo y transferencias de tokens SPL (USDC, USDT, etc.) con creación automática de cuentas
  • Protecciones integradas: en modo alojado, límites de gasto diarios, protección de precio de gas, pausa de emergencia y límites de tasa se aplican del lado del servidor por defecto. En modo local tu protección son los límites por transacción que configures (AGENTWALLET_MAX_TX_NATIVE, AGENTWALLET_MAX_TX_TOKEN, AGENTWALLET_MAX_TX_SOL, AGENTWALLET_MAX_AUTOPAY). La protección de repetición x402 y la verificación en cadena se aplican de cualquier manera
  • Pagos x402: paga automáticamente por APIs habilitadas para x402, o acepta pagos x402 en tus propios endpoints (EVM y Solana)
  • Opción de autocustodia: ejecuta el modo local y la clave nunca sale de tu máquina. En modo alojado, las claves se cifran en reposo, se descifran solo durante la firma y se ponen a cero en memoria inmediatamente después. De cualquier manera puedes exportar e irte.
  • Sin permisos: Sin KYC. Sin KYT. Sin verificación de identidad. Sin proceso de aprobación. Sin control de cumplimiento. Regístrate, obtén una clave API y comienza a transaccionar de inmediato.
  • Configuración en 30 segundos: tres líneas de configuración. Sin SDK que instalar. Sin dependencias que gestionar.

Precios

  • $0.00345 por operación
  • 6,000 operaciones gratuitas/mes
  • $0.0005 por verificación x402
  • 1,000 verificaciones x402 gratuitas/mes
  • Paga con USDC en cadena vía x402, sin necesidad de tarjeta de crédito
  • Sin tarifa mensual, sin niveles, solo paga lo que uses

Las comparaciones con competidores se mantienen en hifriendbot.com/wallet/#pricing con la fecha en que se verificaron por última vez. Viven allí en lugar de aquí porque un README npm publicado no se puede corregir cuando alguien más cambia sus precios.

Inicio rápido

Obtén tu clave API gratuita en hifriendbot.com/wallet, sin necesidad de tarjeta de crédito, sin KYC, sin espera de aprobación.

Claude Desktop / OpenClaw

Agrega a tu configuración:

{
  "mcpServers": {
    "agentwallet": {
      "command": "npx",
      "args": ["-y", "agentwallet-mcp"],
      "env": {
        "AGENTWALLET_USER": "your_username",
        "AGENTWALLET_PASS": "your_api_key",
        "AGENTWALLET_WALLET_ID": "1"
      }
    }
  }
}

AGENTWALLET_WALLET_ID es opcional. Configúralo para habilitar el pago automático x402: cuando superes el nivel gratuito sin tarjeta de crédito, el servidor MCP paga automáticamente las operaciones con USDC desde esta wallet.

Límite de seguridad de pago automático. AGENTWALLET_MAX_AUTOPAY (opcional, por defecto 1) es el máximo que un pago x402 puede autorizar, en unidades de stablecoin: 1 significa un dólar. Solo valora stablecoins del registro (USDC, USDT, USDbC, DAI en las cadenas compatibles, USDC y USDT en Solana). Un requisito en el activo nativo de la cadena o en cualquier otro token se rechaza, porque "1" medido en ETH son unos pocos miles de dólares; lista tales activos en AGENTWALLET_AUTOPAY_ASSETS (direcciones o mints separados por comas, o la palabra native) para permitirlos, y el límite se aplica entonces en las unidades de ese activo. Cualquier requisito por encima del límite se rechaza en lugar de pagarse, así que un requisito de pago malformado o manipulado no puede drenar la wallet. Esta ruta automática liquida solo requisitos exact; una oferta upto de la API se rechaza antes de cualquier llamada a la wallet, porque pagar un máximo de uso por adelantado no es lo que significa la oferta (usa pay_x402, que firma una autorización Permit2 para ello). El límite es el techo del operador: un argumento max_payment puede bajarlo para una llamada pero nunca subirlo. Sube la variable en sí si realmente necesitas pagos automáticos más grandes (por ejemplo "5" para hasta 5 USDC por llamada).

Claude Code

claude mcp add agentwallet \
  -e AGENTWALLET_USER=your_username \
  -e AGENTWALLET_PASS=your_api_key \
  -e AGENTWALLET_WALLET_ID=1 \
  -- npx -y agentwallet-mcp

VS Code

Agrega a tu configuración:

{
  "mcp": {
    "servers": {
      "agentwallet": {
        "command": "npx",
        "args": ["-y", "agentwallet-mcp"],
        "env": {
          "AGENTWALLET_USER": "your_username",
          "AGENTWALLET_PASS": "your_api_key",
          "AGENTWALLET_WALLET_ID": "1"
        }
      }
    }
  }
}

Herramientas

HerramientaDescripción
create_walletCrea una nueva wallet EVM o Solana
list_walletsLista todas tus wallets
get_walletObtén detalles de la wallet por ID
get_balanceVerifica el saldo de tokens nativos en cualquier cadena
get_token_balanceVerifica el saldo de tokens ERC-20 o SPL
get_token_infoObtén nombre, símbolo y decimales del token ERC-20
transferEnvía tokens nativos (ETH, SOL, POL, BNB, etc.)
transfer_tokenEnvía tokens ERC-20 o SPL (USDC, USDT, etc.)
send_transactionFirma y transmite una transacción cruda
sign_transactionFirma una transacción sin transmitirla
call_contractLlamada de contrato de solo lectura (eth_call)
approve_tokenAprueba el gasto de tokens ERC-20 para DeFi
get_allowanceVerifica la asignación de tokens ERC-20
wrap_ethEnvuelve tokens nativos a WETH/WAVAX/etc.
unwrap_ethDesenvuelve WETH de vuelta a tokens nativos
pay_x402Paga facturas x402 (exactas vía EIP-3009, hasta vía Permit2), con aprobaciones por encima del límite
check_approvalEstado de una aprobación humana creada por un pay_x402 por encima del límite
approve_permit2Aprobación de token única para Permit2 para endpoints upto
check_token_riskIndicadores de honeypot, impuestos, poder del propietario y concentración de tenedores para un token
create_paywallCrea un muro de pago x402 para cobrar por un recurso
list_paywallsLista todos tus muros de pago x402
get_paywallObtén detalles del muro de pago por ID
update_paywallActualiza el precio, recurso o estado del muro de pago
delete_paywallElimina un muro de pago
get_paywall_paymentsVe el historial de pagos de un muro de pago
get_x402_revenueEstadísticas de ingresos agregadas en todos los muros de pago
wallet_modeReporta si la firma es local (autocustodia) o alojada, y qué dirección está en uso
export_wallet_keyCómo exportar una clave de wallet alojada y pasar a autocustodia
buy_verification_creditsCompra créditos de verificación x402 con USDC en cadena
get_usageVerifica tu uso mensual y facturación
get_chainsLista todas las cadenas compatibles
pause_walletPausa de emergencia de una wallet
unpause_walletReanuda una wallet en pausa
delete_walletElimina una wallet

Cadenas compatibles

CadenaIDToken nativoStablecoin
Ethereum1ETHUSDC
Base8453ETHUSDC
Polygon137POLUSDC
BSC56BNBUSDT
Arbitrum42161ETHUSDC
Optimism10ETHUSDC
Avalanche43114AVAXUSDC
Zora7777777ETHUSDC
PulseChain369PLSUSDC
Solana900SOLUSDC
Solana Devnet901SOLUSDC

Caso de uso: GuessMarket

Combínalo con guessmarket-mcp para permitir que tu agente de IA negocie mercados de predicción:

  1. Crea una wallet en Base
  2. Aprueba el gasto de USDC
  3. Compra acciones de SÍ/NO en mercados de predicción
  4. Proporciona liquidez y gana comisiones de trading
  5. Reclama ganancias

Todo en cadena. Todo a través de MCP. Sin necesidad de frontend.

Pagos x402

AgentWallet habla el estándar de pago abierto x402 tal como lo define la especificación. Cuando tu agente de IA accede a una API que responde con HTTP 402, pay_x402 realiza todo el flujo:

  1. Obtiene la URL y lee los requisitos de pago, desde el encabezado v2 PAYMENT-REQUIRED o el cuerpo JSON v1.
  2. Elige una opción exact (puedes dirigirla con prefer_chain).
  3. Firma una EIP-3009 TransferWithAuthorization por exactamente ese monto. No se transmite nada y el pagador no paga gas; el facilitador del endpoint lo liquida en cadena.
  4. Reintenta la solicitud con el encabezado de pago (PAYMENT-SIGNATURE para v2, X-PAYMENT para v1).
  5. Devuelve la respuesta, el recibo de liquidación (PAYMENT-RESPONSE / X-PAYMENT-RESPONSE) y, si el endpoint lo rechazó, la razón indicada en retry_error.

Verificado contra el facilitador público de Coinbase (isValid: true para cargas v1 y v2) y servidores x402 en vivo en Base. Funciona en ambos modos de custodia: la clave local firma en el proceso; las wallets alojadas firman a través de POST /wallets/{id}/x402/authorize, un endpoint limitado que solo firma esta única estructura y ejecuta las mismas verificaciones de pausa y límite de tokens que una transferencia.

pay_x402(
  url="https://api.example.com/premium-data",
  wallet_id=1,
  max_payment="1.00"
)

max_payment reduce el límite para una sola llamada. No puede aumentarlo: AGENTWALLET_MAX_AUTOPAY (por defecto 1) es el techo del operador, y un max_payment por encima de él se ignora y se informa como max_payment_ignored, de modo que ni un endpoint 402 malicioso ni un agente con inyección de prompt pueden autorizar más de lo que el operador permitió. Las wallets alojadas solo pueden superar el techo mediante una aprobación del propietario por correo electrónico (abajo); el modo local eleva la variable. En modo local, AGENTWALLET_MAX_TX_TOKEN también se aplica a las autorizaciones, porque una autorización es una transferencia que otra persona ejecuta. Las autorizaciones son válidas como máximo AGENTWALLET_X402_MAX_TIMEOUT segundos (por defecto 3600) sin importar cuánto tiempo solicite el endpoint, y una llamada repetida a pay_x402 para el mismo endpoint, monto y destinatario dentro de esa ventana reenvía la firma anterior en lugar de firmar una segunda (su nonce es de un solo uso, por lo que un servidor que retuvo el recurso después de liquidar no puede recibir doble pago; pasa fresh_authorization=true para forzar una nueva). La etiqueta mostrada para el activo proviene del registro o de la cadena, nunca del cuerpo 402.

Esquemas. exact (EIP-3009, sin gas para el pagador) es el preferido y funciona en todas las cadenas EVM que AgentWallet conoce. upto (un máximo de Permit2 que el vendedor liquida según el uso real) se firma como un PermitWitnessTransferFrom vinculado al facilitador del endpoint; necesita un approve_permit2 único por token (o AGENTWALLET_PERMIT2_AUTO_APPROVE=1). Una opción upto sin extra.facilitatorAddress se rechaza, nunca se aproxima con una transferencia anticipada. Las solicitudes de activos nativos y Solana, y los muros de pago propios de AgentWallet, se pagan mediante una transferencia en cadena comprobada por hash de transacción, que es lo que esos servidores verifican.

Aprobaciones por encima del límite. En una wallet alojada, un pago por encima del límite no tiene que fallar. Con request_approval (activado por defecto; AGENTWALLET_APPROVALS=0 lo desactiva), el propietario de la wallet recibe un correo electrónico con enlaces de aprobar y denegar, pay_x402 devuelve un approval_id, y el agente reintenta con él una vez que check_approval dice aprobado. Una aprobación está vinculada a una wallet, cadena, activo, destinatario y máximo específicos, caduca en 24 horas y se consume con una sola firma. El modo local no tiene canal de aprobación: los límites en tu entorno son la política.

Riesgo de activos. check_token_risk (y cada resultado de approve_token) informa banderas de honeypot, impuestos, poder del propietario, fuente verificada, concentración de tenedores y liquidez de GoPlus Security, con un respaldo en cadena. Una advertencia para que el llamador la evalúe, nunca un bloqueo.

Prueba. Los acuerdos reales se enumeran en PAYMENTS.md; el primero es un pago de 0.02 USDC exact en Base con el facilitador pagando el gas.

Paga cualquier API x402 desde Claude en tres pasos

  1. Agrega el servidor (uno de los fragmentos en Inicio Rápido). Autocustodia: establece AGENTWALLET_PRIVATE_KEY a una clave que tenga USDC en Base. Alojado: AGENTWALLET_USER y AGENTWALLET_PASS de hifriendbot.com/wallet.
  2. Pregunta: "Usa pay_x402 para hacer POST a https://api.ozdreamtools.de/api/holidays con el cuerpo {"year":2026,"state":"BY"} y un max_payment de 0.05."
  3. Lee el resultado: payment_made: true, el monto, payment_method, y settlement.transaction, el hash en cadena. No se necesita ETH para exact: el facilitador del endpoint paga el gas.

Dominios de tokens. El dominio EIP-712 proviene del extra.name / extra.version del endpoint, luego de un registro corto de implementaciones de USDC, luego del propio name() / version() del contrato del token. Si ninguno de esos responde, el pago se rechaza en lugar de firmarse con un dominio adivinado.

Pagadores delegados. Si la dirección pagadora es una cuenta delegada EIP-7702, pay_x402 lo informa en payer_delegation (el delegado y si responde a ERC-1271). Un delegado sin ERC-1271 es rechazado por los facilitadores que verifican el código de la cuenta antes de recuperar el firmante, y la razón que devuelven parece un error de firma; la advertencia nombra la causa real. Paga desde una EOA simple para una liquidación confiable.

Aceptación x402

AgentWallet también te permite aceptar pagos x402. Crea un muro de pago, apúntalo a cualquier recurso y obtén una URL pública que cobra a los agentes automáticamente:

create_paywall(
  wallet_id=1,
  name="Premium API",
  amount="0.01",
  token_name="USDC",
  token_address="0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  chain_id=8453,
  resource_url="https://your-api.com/data"
)

Cuando un agente accede a la URL del muro de pago:

  1. Recibe HTTP 402 con los requisitos de pago
  2. Paga en cadena usando pay_x402 (o cualquier cliente compatible con x402)
  3. Reintenta con prueba de pago
  4. Recibe el contenido protegido

La verificación en cadena garantiza que cada pago sea real. La protección contra reproducción evita el doble gasto. El seguimiento de ingresos te muestra quién pagó, cuánto y cuándo. 1,000 verificaciones gratuitas al mes, luego $0.0005 cada una. Consulta la comparación de precios para ver cómo se compara.

Cómo nos comparamos

CaracterísticaCoinbase CDPAgentWallet
Tiempo de configuraciónInstalar SDK + configurar3 líneas de configuración
Proceso de aprobaciónVerificación de identidad requeridaNinguno, acceso instantáneo
KYC requeridoSíNo
KYT / Monitoreo de transaccionesSíNo
Puede bloquear tu walletSíNo
Protecciones integradasSí (requiere configuración)Sí (alojado: activo por defecto; local: límites de entorno que estableces)
Operaciones gratuitas / mes5,0006,000
Costo por operación$0.005$0.00345
Costo de verificación x402$0.001$0.0005
Verificaciones x402 gratuitas / mes1,0001,000
Aceptación x402 (muros de pago)NoSí
Paga tarifas de API con criptoNo (solo tarjeta de crédito)Sí (USDC vía x402)
Cadenas compatibles8 EVM + SolanaCualquier EVM + Solana
Herramientas de tokensSíERC-20 + SPL (34 herramientas)
Servidor MCPSíSí

Paga con Cripto, Sin Tarjeta de Crédito

AgentWallet es la única infraestructura de wallets para agentes de IA que acepta cripto para sus propias tarifas de API. Cada competidor, Coinbase CDP, Circle, MoonPay, Crossmint, Turnkey, requiere tarjeta de crédito o factura mensual. Con AgentWallet, tu agente puede pagar las operaciones con USDC en cadena a través del protocolo x402. Sin tarjeta de crédito, sin factura, sin portal de facturación. Solo pagos en cadena.

Cuando tu agente supera el nivel gratuito (6,000 operaciones/mes) sin una tarjeta de crédito configurada, la API devuelve HTTP 402 con instrucciones de pago en USDC. Tu agente paga en cadena, reintenta con prueba de pago y la operación se ejecuta. Totalmente automatizado a través del servidor MCP.

También puedes comprar créditos de verificación x402 por adelantado con USDC usando la herramienta buy_verification_credits, manteniendo tus muros de pago activos más allá de las 1,000 verificaciones gratuitas al mes sin necesidad de tarjeta de crédito.

Protecciones Integradas

Qué protecciones se aplican depende de quién tiene la clave.

Modo alojado (el servidor tiene la clave): cada protección a continuación está activa por defecto, sin configuración requerida.

  • Cifrado en reposo: las claves privadas se cifran antes del almacenamiento y nunca salen del servidor
  • Borrado de memoria: las claves se eliminan de la memoria inmediatamente después de cada operación de firma
  • Límites de gasto diarios: establece un límite diario por wallet en USD, aplicado por el servidor en cada transacción
  • Protección de precio de gas: las transacciones se bloquean cuando los precios del gas suben por encima de umbrales seguros
  • Pausa de emergencia: congela instantáneamente cualquier wallet o todas las wallets con un clic
  • Limitación de velocidad: las solicitudes de API se limitan por minuto para prevenir abusos y ataques de fuerza bruta

Modo local (tú tienes la clave): no hay servidor en la ruta de firma, por lo que los límites y la pausa del lado del servidor no pueden ver ni detener una transacción firmada localmente, y nadie (incluidos nosotros) puede congelar una wallet local. Tu protección son los límites por transacción aplicados dentro de tu propio proceso antes de que se firme algo. Establécelos antes de financiar la wallet; un límite no establecido significa sin límite.

  • AGENTWALLET_MAX_TX_NATIVE: techo por transacción en unidades nativas (ETH, MATIC, etc.)
  • AGENTWALLET_MAX_TX_TOKEN: techo por transferencia o aprobación ERC-20, en unidades humanas del token
  • AGENTWALLET_ALLOW_UNKNOWN_TOKEN_CALLS: establecido en 1 para permitir que los datos de llamada que el límite de tokens no puede valorar lleguen a un contrato de tokens o Permit2 (rechazado por defecto mientras el límite esté establecido)
  • AGENTWALLET_TOKEN_DECIMALS: fija decimales para tokens fuera del registro (8453:0x<token>=6,<mint>=9); un valor fijo se usa para montos y límites en lugar de consultar al RPC
  • AGENTWALLET_MAX_TX_SOL: techo por transferencia nativa de SOL (también cobra el alquiler de una cuenta de tokens del destinatario que un envío SPL tenga que crear). No cubre montos de tokens SPL: AGENTWALLET_MAX_TX_TOKEN lo hace, en Solana como en EVM
  • AGENTWALLET_MAX_AUTOPAY: techo por pago automático x402 en unidades de stablecoin (por defecto 1); AGENTWALLET_AUTOPAY_ASSETS incluye activos nativos o no estables; AGENTWALLET_X402_MAX_TIMEOUT limita cuánto tiempo una autorización firmada sigue válida (por defecto 3600 segundos)
  • AGENTWALLET_SOLANA_RPC_<chainId> (o AGENTWALLET_SOLANA_RPC para todos los clústeres): el hash de génesis del RPC se verifica contra el ID de cadena antes de enviar cualquier cosa, y el eth_chainId de un RPC EVM igualmente, para que una URL no pueda servir silenciosamente una red diferente a la solicitada
  • AGENTWALLET_TOKEN_RISK=0: omite la búsqueda de GoPlus que approve_token realiza (una llamada de terceros que revela qué token estás a punto de aprobar)

Todas las variables de límite se validan al inicio; un error tipográfico detiene el servidor en lugar de leerse como "sin límite". wallet_mode informa cada protección, incluido el límite de tokens y si se permiten llamadas a tokens desconocidos. Se requiere Node.js 22.19 o más reciente.

Cualquier modo, para muros de pago x402 que ejecutes a través de la API alojada:

  • Protección contra reproducción: cada pago x402 verificado en cadena con seguimiento único de transacciones
  • Verificación en cadena: los pagos x402 se verifican directamente en la blockchain con compromiso finalizado

Programa de recompensas por errores: $50 a $500 por divulgación responsable (detalles).

Enlaces

Seguridad

pay_x402 valida la URL de destino antes de cada solicitud saliente y nuevamente en cada salto de redirección. Los literales IP se canonizan (incluido IPv4 mapeado a IPv6 como [::ffff:127.0.0.1]) y los nombres de host se resuelven, con destinos de bucle local, privados, de enlace local, NAT de grado de operador, multidifusión y metadatos de nube rechazados.

La validación y la conexión usan la misma respuesta DNS. Cada salto se resuelve una vez, y el socket se fija a una dirección de esa respuesta, por lo que un nombre de host no puede resolver público para la verificación y privado para la conexión. El nombre de host todavía se usa para el encabezado Host y para SNI de TLS y validación de certificados, por lo que la fijación es invisible para los endpoints legítimos.

Las credenciales permanecen con el origen al que fueron otorgadas. Si un endpoint redirige pay_x402 a un origen diferente, los encabezados Authorization, Cookie y X-PAYMENT proporcionados por el llamador, así como cualquier otro encabezado personalizado, se eliminan antes del siguiente salto; solo se conservan los encabezados de negociación de contenido (Accept, Accept-Language, Accept-Encoding, User-Agent, Content-Type). Una redirección que convierte un POST en un GET también elimina los encabezados del cuerpo. Las redirecciones al mismo origen conservan todo, como haría un navegador.

Reporta problemas de seguridad de forma privada a security@hifriendbot.com.

Licencia

MIT