SameDayDesk x402 Data Gateway

Trece herramientas MCP en vivo para datos x402 y MPP, extracción web, descubribilidad de agentes, auditorías de seguridad, decisiones Morpho y preflight de trabajo.

GitHub

Prueba este MCPPatrocinado

Documentación

SameDayDesk x402 y MPP Data Gateway

Extracción por lotes acotada opcional

Los GET /extract y GET /read de pago (y MCP extract / read) devuelven un registro tipado después de la liquidación. El HTTP 200 del comerciante es la entrega de ese registro, no una prueba de que la fuente tuvo éxito o de que la página está completa. El JSON conserva requestedUrl, el finalUrl observado (también copiado a url por compatibilidad), el HTTP status de la fuente, sourceOk, un error anulable y un objeto capture que etiqueta el GET sin JavaScript, los límites de cuerpo/extracto, el juego de caracteres y la truncación. Un 403/404 con texto de bloqueo no es un 200 vacío. La evidencia de entrega HTTP observacional puede clasificar la conformidad del esquema, el rechazo de la fuente y la truncación; eso no es utilidad para el comprador ni una garantía vendida. El campo text del extracto es un extracto acotado; use /read para Markdown más largo. Ninguna ruta ejecuta JavaScript, por lo que la ausencia de texto de discusión no es prueba de ausencia. Los islotes de datos de script y los comentarios se eliminan; esto no es un lector de discusión completo. Las conexiones de producción a la fuente validan y fijan respuestas DNS IPv4 públicas, revalidan hasta tres redirecciones y rechazan credenciales en URL, direcciones privadas, IPv6 y respuestas comprimidas que ignoran la codificación de identidad solicitada. Las etiquetas de juego de caracteres de cabecera/meta seleccionan un decodificador; capture.charset nombra el decodificador realmente utilizado. Las etiquetas desconocidas recurren a UTF-8 con un marcador de recurso explícito.

Las filas de lote conservan las ranuras de fuente solicitadas, incluidos duplicados y fallos. El provenance.capture de cada fila capturada registra el método sin JavaScript, la asignación real de bytes y el límite de texto de 1.200 caracteres cuando se solicita texto. Un corte conocido de cuerpo o texto es parcial, no completo. Esto no detecta contenido faltante no divulgado. El rechazo de la fuente sigue siendo una fila fallida incluso cuando su página de error tiene texto. Los enlaces de prueba de captura/tiempo de espera en proceso no tienen vinculación de entrada HTTP, MCP o de entorno y no cambian la liquidación ni el middleware de autorización.

EXTRACT_BATCH_ENABLED=1 añade POST /extract/batch y MCP extract_batch a un precio introductorio de 0,01 USDC por lote admitido de 1 a 5 URL HTTPS públicas. El valor predeterminado está desactivado: 25 operaciones HTTP de pago y 22 herramientas MCP; activado: 26 y 23. Este precio no es una garantía de margen medida. Use un proceso de servidor y COMMERCE_DATA_DIR persistente; la liquidación desconocida se pone en cuarentena, no se vuelve a cobrar automáticamente. La salida parcial acotada no promete cada fuente o campo solicitado.

LOCKFILE_PIN_DELTA_ENABLED=1 añade POST /lockfile-pin-delta y MCP lockfile_pin_delta para dos objetos npm package-lock.json proporcionados por el llamante. El valor predeterminado está desactivado. La producción ya tiene EXTRACT_BATCH_ENABLED=1 (26 HTTP de pago / 23 herramientas MCP). Habilitar lockfile junto a ese sobre es 27 / 24. Los catálogos desactivados por defecto siguen siendo 25 / 22. El precio predeterminado es $0.005 (LOCKFILE_PIN_DELTA_PRICE), que coincide con el GET /extract en vivo. El margen no está probado. La versión inicial en vivo acepta solo x402; las rutas MPP existentes, incluida extract_batch, no cambian. Solo HTTP JSON: sin rutas de sistema de archivos, comandos arbitrarios o captura de red. Los pines idénticos son informativos, no un fallo del motor. La declaración de despliegue firmada no se reescribe aquí. El recurso de desafío de la herramienta MCP lockfile es https://agents.samedaydesk.com/lockfile-pin-delta, no mcp:// y no /extract/batch.

La herramienta MCP extract_batch proyecta el manejo HTTP de pago existente y el reproductor duradero. Su recurso de desafío es https://agents.samedaydesk.com/extract/batch, no mcp://: primera llamada sin pago, luego reutilice el recurso HTTP devuelto y los argumentos exactos con _meta["x402/payment"]. Los llamantes MPP pueden usar el desafío www-authenticate sin modificar en el resultado _meta["samedaydesk/http"].headers y enviar su credencial como HTTP Authorization. Esos metadatos también llevan el estado HTTP y las cabeceras de recibo. Nunca traduzca una credencial de recurso MCP. Las herramientas MCP existentes conservan su límite de pago MCP nativo existente.

La declaración firmada declara 25 capacidades de ruta estándar en cualquier estado de bandera (Circle es separado); no afirma que una ruta desactivada esté disponible ni autoriza el pago. El descubrimiento en vivo excluye la extracción por lotes desactivada.

Cada respuesta HTTP de pago anuncia /.well-known/agent-payment-evidence.json a través de la relación de enlace HTTP estándar describedby. El manifiesto gratuito acotado une cada método exacto y ruta a su efecto de solo lectura declarado por el vendedor, rutas JSON garantizadas recursivamente, resumen del esquema de respuesta, vinculación de reproducción exacta, comportamiento del recibo y la declaración de despliegue firmada existente. No cambia los términos de x402 o MPP y no es autorización para gastar; los compradores aún deben verificar el desafío en vivo, la salida de pago, el recibo y la liquidación.

Veinte herramientas de pago por llamada para la verificación previa determinista de oportunidades de trabajo de agentes, descubrimiento de servicios de máquina, verificación previa de ofertas de pago, decisiones de prestatarios y mercados de Morpho, planes de protección, extracción de URL, lectura de Markdown, escaneos de seguridad de repositorios, enriquecimiento de empresas y carteras, generación de datos estructurados, evidencia de recibos de transacciones, conformidad de políticas de firmantes delegados, prueba de liquidación y auditorías de preparación para búsqueda de IA.

Página de producto: https://samedaydesk.com/x402
Smithery: https://smithery.ai/servers/epistemedeus/x402-data-gateway
MCP remoto: https://agents.samedaydesk.com/mcp
Paquete local de Agent Plugins 1.0: plugins/samedaydesk-x402 (no listado en el mercado)
Mercado de Claude Code: .claude-plugin/marketplace.json más plugins/samedaydesk-extract (samedaydesk-extract@samedaydesk-claude; no es un listado oficial del directorio de Anthropic)
Config nativa de Goose: goose/ (YAML, indicador de sesión y enlace profundo; no es un instalador de Goose)
Habilidades de Hermes Agent: hermes/ más plugins/samedaydesk-x402/skills portátil (drop-in de AgentSkills SKILL.md; no es un plugin o instalador de Hermes)
Manifiesto de recursos en vivo: https://agents.samedaydesk.com/.well-known/x402
OpenAPI: https://agents.samedaydesk.com/openapi.json
OpenAPI oficial de MPP: https://agents.samedaydesk.com/mpp-openapi.json
Contrato de habilidades: https://agents.samedaydesk.com/skill.md
Catálogo de acciones: https://agents.samedaydesk.com/api/actions
Tarjeta de agente A2A: https://agents.samedaydesk.com/.well-known/agent-card.json
Registro global A2A: https://www.a2a-registry.org/agent/9cb0b8e6-cb1f-422b-a604-861d0a79e24b
Radar de liquidación: https://agents.samedaydesk.com/platforms
JSON de salud de la plataforma: https://agents.samedaydesk.com/v0/cards.json
Telemetría agregada de demanda de máquinas: https://agents.samedaydesk.com/v0/commerce-demand.json
Riesgo de posición Morpho: GET /defi/morpho-position?address=0x...&shocks=-10,-20,-30
Cotización de protección Morpho: GET /defi/morpho-protection?address=0x...&targetHealthFactor=1.25&protectAgainstShockPct=-10
Suscripción de mercado Morpho: GET /defi/morpho-market-underwrite?marketId=0x...
Reproducción de pre-liquidación Morpho: GET /defi/morpho-preliquidation-replay?transactionHash=0x...
Verificación previa de oportunidades: GET /work/opportunity-preflight?rewardUsd=10&hours=0.25&hourlyCostUsd=4&selectionProbabilityPct=20
Auditoría de descubrimiento de agentes: GET /distribution/agent-discoverability-audit?origin=https://example.com&intent=extract+a+public+website+into+structured+JSON&route=/extract&method=GET&runtimeUrl=https%3A%2F%2Fexample.com%2Fextract%3Furl%3Dhttps%253A%252F%252Fexample.org&surfaceAudit=true&materializationAudit=true
Verificación previa de ofertas de pago: GET /commerce/payment-offer-preflight?url=https://example.com/paid-route
Auditoría de integridad del vendedor: GET /commerce/seller-integrity-audit?origin=https://seller.example&route=/paid-route&method=GET&requiredPaths=data.attributes
- Un comprador puede añadir referral=r1_<sha256> derivado de su recibo de liquidación x402 completo firmado por el vendedor. Esto crea una etiqueta de adquisición declarada, no una prueba verificada. POST /commerce/referral-recheck acepta ese recibo más un recibo de liquidación firmado por el vendedor posterior de un pagador y transacción distintos, y luego otorga atómicamente como máximo una re-verificación gratuita de estado cambiado. Los recibos no prueban una respuesta HTTP 200 de la aplicación ni la entrega o validez de la salida, y la publicación o difusión pública es opcional. Un archivo que coincida con el contrato de captura observable del PR 1070 de Agent402 (recibo JSON bonito y desnudo, sin código fuente de Agent402 incluido) ya es una entrada drop-in después de JSON.parse ordinario; consulte docs/agent-outcome-referral-experiment.md y agent402-receipt-interop.test.mjs.
Deriva de descubrimiento↔pago en vivo (solo biblioteca/CLI; no es una ruta alojada o de pago): node discovery-drift.mjs observe --url 'https://agent-economy-signal-x402-mainnet.bronzetti-andrea.workers.dev/premium/agent-brief' --bazaar-pay-to '0xbda48b29607b9dc66ef7e38b68ad53f2b17efb23'
Búsqueda calificada por contrato: GET /commerce/contract-qualified-search?query=service+domain+ownership+code+provenance&requiredPaths=data.sourceRepository devuelve un plan de reparación OpenAPI consultivo acotado para rutas faltantes requeridas por el comprador sin mutar archivos del vendedor ni inferir tipos de propiedades no declaradas.
Prueba de liquidación USDC base: GET /commerce/settlement-proof?transactionHash=0x...&recipient=0x...&amountAtomic=5000
Recibo de transacción Base o Ethereum: GET /chain/transaction-receipt?transactionHash=0x...&network=base
Conformidad de políticas de cartera: POST /security/wallet-policy-conformance
Contrato de conformidad de políticas de cartera: GET /schemas/wallet-policy-conformance-v1.json
Conformidad de políticas de cartera con estado: POST /security/stateful-wallet-policy-conformance
Contrato de políticas de cartera con estado: GET /schemas/stateful-wallet-policy-conformance-v1.json
Sonda de alerta de cambio material: https://agents.samedaydesk.com/alerts
Devolución de llamada del vendedor Agoragentic: POST /integrations/agoragentic/ai-readiness-audit
Webhook de cumplimiento firmado the402: POST /integrations/the402/webhook

No se requiere clave API ni suscripción. Cada ruta HTTP de pago anuncia x402 y autenticación de pago MPP nativa en la misma respuesta 402. Ambos protocolos liquidan el mismo monto exacto de USDC a la misma cartera de comerciante en Base mainnet. Las llamadas a herramientas MCP siguen limitadas por x402.

La ruta Morpho es de solo lectura. Calcula LTV, LLTV, factor de salud, margen de liquidación y escenarios de choque de precio de garantía a partir de valores enteros del protocolo, luego verifica de forma cruzada la garantía indexada, las acciones de préstamo y el precio del oráculo contra el estado RPC directo de Base. Los escenarios son cálculos en lugar de probabilidades o recomendaciones de transacción. La ruta de protección separada utiliza una lectura de oráculo RPC directa reciente y confirmación directa de garantía y acciones de préstamo para calcular montos exactos de reembolso parcial y adición de garantía. Devuelve plantillas de aprobación de tokens y llamadas Morpho sin firmar, buffers de ejecución explícitos, requisitos de revalidación y postcondiciones económicas. Nunca accede a una cartera, firma, transmite ni toma custodia.

El servicio también mantiene un telescopio de demanda seguro para la privacidad en un volumen persistente de Railway. Registra familias de rutas, nombres de claves de consulta, clases de desafío/éxito y señales pseudónimas de uso repetido. Las capturas externas son señales de adquisición, no compradores verificados, porque los indexadores automatizados no identificados pueden permanecer. Los agentes de usuario reconocidos de rastreadores e indexadores de agentes se reducen en la ingesta a una etiqueta de fuente controlada y se informan en una lente separada de descubrimiento de máquinas con cobertura de fuente y ruta. Esas observaciones miden capturas, no referencias de catálogo autenticadas, intención o demanda. Las solicitudes no coincidentes se informan por separado de un subconjunto conservador de candidatos semánticos; ninguna se convierte en demanda hasta que un llamante independiente repite o convierte. No registra direcciones IP sin procesar, agentes de usuario, URL, valores de consulta, cuerpos, cabeceras de pago, cargas de mercado o credenciales. La salida pública es solo agregada; el tráfico del propietario está excluido y el tráfico de rastreadores permanece excluido de la demanda incluso cuando sus recuentos de descubrimiento controlado se informan por separado. Las sondas de explotación comunes como .env, .git, y las rutas de descubrimiento de WordPress se clasifican como tráfico de escáner y también se excluyen.

La versión 1.9.4 añade clases explícitas de tráfico de pago sin exponer direcciones de compradores. COMMERCE_PAYER_CLASSES acepta una matriz JSON de { "address", "class" } records. Controlled classes are internal, validation, incentivized, affiliated y independent. Las direcciones se convierten a los mismos pseudónimos de pagador con clave secreta ya utilizados por la telemetría y se clasifican en el momento de la lectura, lo que también permite la corrección retroactiva sin almacenar una dirección sin procesar. Los pagadores desconocidos permanecen unclassified; las carteras desconocidas nunca se convierten en demanda independiente por inferencia. La instantánea pública informa el éxito de pago por clase más recuentos de actores independientes y repetidos independientes.

La versión 1.9.5 añade recuentos de éxito de pago a nivel de ruta dentro de cada clase de evidencia. Esto permite a los monitores posteriores tratar la validación del mercado como evidencia contable y de transporte, alertar sobre el uso de pago no clasificado para investigación y avanzar la tesis de demanda solo para compradores explícitamente independientes o repetidos independientes.

La versión 1.9.6 captura de forma privada un hash de transacción Base válido de cabeceras x402 PAYMENT-RESPONSE o MPP Payment-Receipt exitosas después de una línea base de evidencia explícita. La telemetría pública expone solo cobertura de prueba, recuentos distintos y recuentos de referencias faltantes por clase de pago. Las cabeceras sin procesar y las referencias de transacción permanecen en el volumen privado. Una referencia faltante se convierte en un evento material de integridad de liquidación sin exponer la referencia en sí. Version 1.11.2 negocia el contenido de la raíz sin cambiar su contrato de máquina. La navegación del navegador con un Accept: text/html explícito recibe un mapa humano receptivo de las catorce herramientas, el flujo de pago y los enlaces de descubrimiento autorizados. Los clientes JSON, el encabezado de aceptación comodín de curl y los agentes mantienen el descriptor JSON estable. La respuesta varía según Accept, y la página humana no duplica ningún esquema de pago.

La versión 1.11.2 también añade la lente de descubrimiento de máquina con atribución de fuente. Mantiene los agentes de usuario y las direcciones de red sin procesar fuera de la instantánea pública, informa observaciones futuras exactas del indexador por fuente y ruta controladas, y le da al radar solo los cambios de cobertura de primera fuente y primera ruta como eventos materiales. El volumen de rastreo repetido sigue siendo datos visibles sin convertirse en una alerta de atención o demanda.

La versión 1.11.3 hace que esa lente de alcance sea prospectiva y autoexcluyente. Una línea base distinta de COMMERCE_AGENT_DISCOVERY_SINCE evita que el historial de rastreadores previo a la instrumentación se convierta en alcance atribuido, mientras que los agentes de usuario de monitoreo propiedad de SameDayDesk se excluyen tanto de las observaciones de descubrimiento como de demanda externa. Esto evita que los barridos de integridad, los puntos de referencia ciegos a la marca y las sondas de radar creen su propia señal de adquisición.

La versión 1.11.4 preserva a los agentes que pagan incluso cuando su agente de usuario se identifica como rastreador o indexador. Una credencial x402 o MPP válida enviada mueve el evento a la telemetría económica antes de la clasificación del rastreador, mientras que la etiqueta de agente de usuario controlada registra la conversión de fuente a pago por fuente y ruta. Las etiquetas de canal siguen siendo autodeclaradas en lugar de prueba de referencia autenticada, y la demanda independiente aún requiere la política explícita de clase de pagador.

La versión 1.11.5 separa el alcance de la ruta pagada de la entrega del desafío. Las observaciones prospectivas de agentes/indexadores ahora informan sondas de ruta pagada, desafíos HTTP 402, actores de desafío distintos y repetidos, tasa de desafío y desgloses de fuente y ruta controlados. Esto identifica si el embudo de máquinas se detiene antes del muro de pago, en el desafío o después de una credencial enviada sin tratar una sonda de indexador como intención de compra.

La versión 1.11.6 añade una cohorte conservadora de desafío a pago. Un éxito pagado cuenta como continuación solo cuando el mismo actor de red y agente de usuario con clave secreta regresa después de su primer desafío prospectivo. La instantánea pública informa llamadas convertidas, actores convertidos, actores convertidos independientes, tasa de conversión y totales de fuente y clase de evidencia controlados sin ID de actor. La deriva de red o agente de usuario solo puede crear falsos negativos, por lo que la métrica es un límite inferior en lugar de una afirmación de identidad.

La versión 1.11.7 añade la verificación del conector Glama propiedad del proyecto en /.well-known/glama.json utilizando el correo electrónico comercial público de SameDayDesk. Las solicitudes de Glama tienen su propia etiqueta de fuente de descubrimiento controlada, por lo que una afirmación de directorio propagada se puede medir sin convertirse en demanda.

La versión 1.11.8 inicia un embudo separado de intentos de credenciales. Después de una línea base declarada, un intento analizable debe incluir un enlace exacto x402 v2 sintácticamente completo o una credencial MPP evm/charge. La validez de la firma y la liquidación siguen siendo resultados posteriores. Los agregados públicos separan el ruido del encabezado de los intentos analizables e informan protocolo, resultado, ruta, fuente controlada y clase de pagador explícita sin credenciales sin procesar, ID de actor o direcciones.

La versión 1.11.9 mejora la selección de herramientas MCP sin renombrar ni duplicar ninguna herramienta. Cada herramienta ahora tiene un título único orientado a la acción. Las herramientas web y de empresa superpuestas dicen explícitamente cuándo elegir extract frente a read, enrich frente a schemaforge, y el combinado deep_audit; wallet_enrich también establece que su entrada es una dirección EVM en lugar de un dominio de empresa. Las rutas de pago, nombres, precios, esquemas y manejadores no cambian.

La versión 1.11.10 añade descripciones explícitas a cada entrada de opportunity_preflight y a los tres controles de protección Morpho. Esto mejora la construcción de llamadas de máquina sin cambiar nombres, rutas, precios, entradas requeridas, valores predeterminados, puertas de pago y comportamiento de ejecución.

La versión 1.11.11 otorga a las cuatro herramientas MCP Morpho una guía explícita de selección entre hermanos. El diagnóstico del prestatario, la planificación futura de protección, la suscripción de mercado y la reproducción histórica de PreLiquidation son ahora opciones de máquina distintas sin renombrar una herramienta ni cambiar su ruta, precio, esquema, puerta de pago o manejador.

La versión 1.11.12 inicia una sonda prospectiva de fricción de transporte MCP. Separa cuatro expectativas comunes de cliente, /mcp/sse, /mcp/messages, /mcp/tools y /mcp/events, de fallos arbitrarios de /mcp/* sin servir un alias adivinado. Los agregados públicos exponen solo recuentos de rutas y totales de actores con clave secreta. Una ruta de compatibilidad se justifica solo por uso independiente repetido o conversión.

La versión 1.11.13 repara el contrato de respuesta previa al pago expuesto a los compradores de máquinas. Las trece rutas ya tenían esquemas de salida JSON explícitos, pero el helper Bazaar v2 espera ese esquema bajo output.schema; el campo outputSchema de nivel superior anterior se ignoraba silenciosamente. Un adaptador probado único ahora coloca cada esquema autorizado en la ubicación definida por el protocolo, por lo que un desafío 402 no pagado expone tanto el ejemplo como los campos de respuesta requeridos concretos antes de que un agente autorice el pago. Las rutas, entradas, precios, liquidación y manejadores no cambian.

La versión 1.11.14 proyecta los mismos trece contratos de respuesta en el catálogo gratuito de OpenAPI y acciones. Los agentes de descubrimiento ahora pueden inspeccionar campos requeridos concretos y un ejemplo antes de sondear una ruta pagada; /read también se describe como el objeto JSON que su manejador realmente devuelve en lugar de una cadena Markdown sin procesar. Un mapa de contratos clave de ruta único impulsa el desafío x402, OpenAPI y el catálogo de acciones para evitar que las tres superficies de máquina se separen.

La versión 1.11.16 vincula la referencia gratuita sin credenciales agent-payment-policy desde la raíz de la máquina, los metadatos del servicio OpenAPI y llms.txt. La referencia no tiene ejecutor de billetera, firmante de pago, custodia ni verificador pagado alojado. Proporciona a los compradores de máquinas una primitiva de política y evidencia estable sin cambiar las rutas, precios, requisitos de pago o liquidación del comerciante.

La versión 1.13.1 avanza esa referencia de comprador orientada a máquinas al paquete público 0.4.0. La raíz, los metadatos de OpenAPI y llms.txt ahora anuncian autorización exacta de forma de ejecución más el esquema de cobertura de control de catorce dimensiones v2. Esto sigue la evidencia de primera persona de Tempo y Solana de que las reglas de permiso de método e instrucción nativas del proveedor pueden admitir acciones aprobadas duplicadas. No cambia ninguna ruta, precio, manejador, requisito de pago o liquidación del comerciante.

La versión 1.14.0 convierte el fallo de firmante delegado entre cadenas que encontramos en un producto pagado sin credenciales. POST /security/wallet-policy-conformance acepta solo una matriz acotada y estandarizada de permitir, denegar y error. Separa la lista de permitidos de operaciones del control exacto de forma de ejecución, acredita solo una denegación de política explícita del proveedor como aplicación nativa del proveedor, y devuelve conformant, partial o unsafe sin puntuación opaca. Las formas inválidas o que contienen secretos se rechazan antes del pago. El evaluador no acepta credenciales de billetera, firmas, cuerpos de transacción, acceso a billetera ni autoridad de transmisión, y no afirma haber ejecutado las pruebas de proveedor del llamante.

La versión 1.14.1 publica los casos estandarizados exactos, clases de evidencia, esquema de entrada, esquema de salida, método, protocolos y precio atómico en el contrato canónico gratuito /schemas/wallet-policy-conformance-v1.json. La ruta pagada, el precio, la lógica de decisión, las puertas de pago y la liquidación permanecen sin cambios. Los clientes de máquinas ahora pueden construir y validar la matriz sin decodificar un desafío de pago.

La versión 1.14.2 mueve la taxonomía, el validador estricto, el evaluador fuera de línea y los esquemas JSON al agent-payment-policy@0.5.0 público; el producto alojado ahora importa ese paquete en lugar de mantener un duplicado privado. El paquete público también proporciona comandos CLI wallet-policy-init, wallet-policy-check y wallet-policy-schema. Un caso previsto no ejecutado es correctamente partial, mientras que una acción prevista bloqueada probada o una mutación permitida sigue siendo unsafe. La ruta alojada, el precio de 0.01 USDC, los términos de pago y el límite sin credenciales permanecen sin cambios.

La versión 1.14.3 avanza la dependencia del estándar público a agent-payment-policy@0.5.1. El crédito de control nativo del proveedor ahora requiere que cada caso observado para ese control pase. Un caso de forma opcional denegada ya no puede enmascarar un caso de acción aprobada duplicada permitida. Los adaptadores de Privy Tempo y Solana clasifican la forma de ejecución exacta como no verificada y las políticas nativas generales como inseguras, coincidiendo con la evidencia de primera persona. La ruta, el precio, el pago y los límites de credenciales permanecen sin cambios.

La versión 1.15.0 añade un producto separado de política de billetera con estado del experimento de tope acumulativo de Privy de primera persona. POST /security/stateful-wallet-policy-conformance evalúa siete casos estandarizados seguros para topes secuenciales, contabilidad firmada pero no transmitida, extracción ABI, sobresuscripción concurrente, fallo de referencia de contador y serialización de aplicaciones. GET /schemas/stateful-wallet-policy-conformance-v1.json publica el contrato de construcción gratuito. El evaluador proviene del agent-payment-policy@0.6.0 público, no acepta credenciales ni cargas útiles de proveedor sin procesar, y mantiene separadas la política del proveedor y la aplicación.

La versión 1.15.1 convierte la evidencia de catálogo obsoleto de primera persona en una función acotada de auditoría de descubribilidad. Los llamantes pueden proporcionar expectedPriceUsd junto con una ruta exacta para comparar los precios de ruta anunciados en el catálogo en las diez vistas de descubrimiento público. El resultado distingue estados de coincidencia, deriva, mixto, precio desconocido y ruta ausente, y devuelve una secuencia de remediación máxima de un canario solo después de que los términos en vivo propios coincidan. Nunca trata la expectativa del llamante como verdad de ejecución, no realiza ningún pago de catálogo y deja la propagación asíncrona al monitoreo basado en eventos.

La versión 1.15.2 repara la ruta de medición para los dos contratos gratuitos de política de billetera y sus evaluadores pagados correspondientes. Las cuatro rutas ahora tienen clasificaciones de comercio exactas. Los eventos históricos de /schemas/* permanecen en el recuento bruto no coincidente pero se excluyen de la interpretación de demanda semántica porque el libro mayor seguro de privacidad no retuvo suficiente detalle de ruta para reclasificarlos. Los nuevos eventos exactos producen embudos agregados del mismo cliente desde la lectura exitosa del contrato gratuito hasta el desafío de ruta pagada, credencial analizable y entrega. La instantánea pública no expone actor, credencial, ruta sin procesar, billetera o carga útil del proveedor, y las lecturas de contrato siguen siendo evidencia de alcance en lugar de demanda.

La versión 1.16.0 actualiza la verificación previa de la oferta de pago desde la paridad de protocolo sola hasta la coherencia opcional de catálogo a ejecución. Un llamante puede enviar un candidato de catálogo exacto con el formulario POST o MCP, y el producto lo compara solo con la oferta de protocolo sin firmar en vivo correspondiente en solicitud, protocolo, monto, red, activo, destinatario y vencimiento utilizando el agent-payment-policy@0.7.0 público. La deriva explícita produce review_required; los campos de catálogo faltantes siguen siendo un resultado parcial visible. La ventana de validez x402 se deriva de maxTimeoutSeconds, la entrada de catálogo malformada se rechaza antes del pago, y la solicitud aún no utiliza credencial de destino, billetera, firma, liquidación, redirección o cuerpo de respuesta. Version 1.16.1 mejora la auditoría existente de descubrimiento de agentes sin añadir otro producto ni cambiar su precio de 0,05 USDC. Un runtimeUrl opcional debe usar el origen auditado y la ruta exacta solicitada. La auditoría realiza una única solicitud sin credenciales, fijada por DNS y solo de cabeceras; acepta una referencia de precio únicamente cuando los términos x402 y MPP sin firmar en vivo son analizables y coherentes, y luego compara ese monto canónico en Base-USDC con cada observación del registro. Las expectativas proporcionadas por el llamador siguen siendo compatibles y claramente etiquetadas, mientras que un desacuerdo con la verdad en tiempo de ejecución se convierte en un hallazgo propio. El resultado sigue sin firmar nada, no envía ningún pago objetivo, no sigue redirecciones y no lee el cuerpo de la respuesta objetivo.

Version 1.16.2 añade identidad de listado a nivel de ruta a esa misma auditoría. Cada observación del catálogo ahora informa si la ruta exacta es canónica, duplicada, solo alias o dividida entre orígenes canónicos y no canónicos. Un candidato a alias requiere un payTo explícito y una coincidencia de ruta exacta, y la salida indica que esto no prueba la propiedad del nombre de host. Esto detecta alias de mercado obsoletos y listados duplicados por clave de URL junto con desviaciones de precio, preservando el mismo producto de 0,05 USDC, el límite de solicitud y el barrido de catálogo sin gasto.

Version 1.16.3 hace explícito el límite de la evidencia de identidad. Un registro no canónico que comparte el payTo proporcionado por el llamador y la ruta exacta es un candidato a alias, no una prueba de que el vendedor posee el nombre de host. Cada fuente ahora devuelve identityBasis, ownershipProven y un límite de evidencia en lenguaje sencillo para que una reparación automatizada pueda preservar el registro canónico sin retirar un endpoint de terceros basándose en evidencia circunstancial.

Version 1.23.35 extiende esa auditoría existente sin añadir una ruta ni cambiar su precio de 0,05 USDC. Con materializationAudit=true, una ruta GET o POST exacta se verifica mediante el validador de vendedor actual de Coinbase y la lectura inversa de Bazaar de recurso exacto. El resultado distingue materialized, provider_accepted_not_materialized, seller_not_provider_eligible y unresolved en lugar de tratar cada resultado clasificado faltante de la misma manera. La aceptación de la validación sigue siendo evidencia puntual devuelta por el proveedor, no autoridad de listado, demanda, liquidación o reindexación. La verificación opcional no usa credenciales, firmas ni pagos; Coinbase puede realizar una solicitud no remunerada al vendedor utilizando el método solicitado.

Version 1.16.4 reemplazó el clasificador de identidad privado de la auditoría de rutas con la primitiva pública agent-payment-policy@0.8.0 que lleva procedencia. Los catálogos que no devuelven registros coincidentes ahora se registran como verificados y route_absent; las coincidencias de origen canónico siguen siendo observaciones, no afirmaciones de propiedad. Esto crea un contrato compartido e instalable para el vendedor en vivo y las herramientas independientes del comprador sin añadir credenciales, acceso a billetera, firma, pagos ni identidades de liquidación retenidas.

Version 1.18.3 completa ejemplos construibles por máquina para las rutas de prueba de liquidación en Base y recibo en Solana, y otorga al alias de Circle Gateway el mismo esquema de respuesta de éxito redactado que la verificación previa canónica de oferta de pago.

Version 1.18.2 publica informes de respuesta recursivos bajo su identificador de esquema v2 inmutable.

Version 1.18.1 añade rutas de respuesta garantizadas recursivamente al informe acotado, de modo que un vendedor que solo requiere un sobre data de nivel superior no parezca prometer una carga útil de decisión data.attributes anidada.

Version 1.18.0 mantiene el control de identidad de alias de catálogo firmado y añade una verificación acotada del contrato de respuesta del vendedor a la verificación previa de oferta de pago. La ruta ahora lee el documento OpenAPI público del mismo origen del vendedor exacto bajo un límite de tamaño estricto e informa si la operación GET exacta declara un esquema de éxito JSON autocontenido con campos obligatorios tipados. Nunca lee el cuerpo objetivo pagado, y la declaración del vendedor sigue siendo consultiva hasta que una respuesta pagada pase el validador de salida autorizado independientemente por el comprador.

Version 1.22.3 convierte las declaraciones del vendedor que exceden el límite de bytes de la auditoría acotada en la brecha específica openapi_too_large en lugar de una falla genérica de auditoría acotada. El límite permanece sin cambios y no se infiere ningún esquema.

Version 1.22.2 excluye tanto el origen canónico de SameDayDesk como su conocido alias de catálogo anterior en Railway de la búsqueda calificada por contrato. Agent402 clasificó ambos registros para la primera consulta en vivo en el idioma del comprador, demostrando que excluir solo el nombre de host canónico no excluía el suministro propio a nivel de identidad de servicio.

Version 1.22.1 añade metadatos de selección MCP obligatorios para la nueva herramienta de búsqueda y refuerza la prueba de humo de inicio de producción para que una versión no pueda pasar simplemente porque HTTP está escuchando mientras el montaje MCP asíncrono falló.

Version 1.22.0 añade una búsqueda pagada de servicios de máquina calificada por contrato. Un comprador proporciona una intención de capacidad y rutas de respuesta JSON requeridas recursivamente. La ruta busca en Agent402 y en el catálogo oficial de MPP, excluye el suministro propio y las rutas no resueltas antes de la auditoría, y devuelve candidatos acotados comprables por máquina o listos para contrato, además de códigos de rechazo controlados. No usa credenciales ni billetera, no envía POST al vendedor ni pago objetivo, no lee el cuerpo pagado y solo devuelve un resumen de consulta. La declaración de despliegue firmada ahora vincula veintitrés pares exactos de método HTTP y ruta.

Version 1.17.0 cerró la ambigüedad de alias de catálogo con una declaración de despliegue firmada opcional de agent-payment-policy@0.9.0. El JWS de corta duración en /.well-known/agent-payment-policy-service-deployment.json vincula el origen canónico agents.samedaydesk.com con los pares de método HTTP y ruta pagados vigentes y con las identidades de liquidación exactas de Base USDC x402 y MPP. Cada origen de despliegue lleva su propio alcance de ruta y liquidación, de modo que un alias futuro no puede heredar la autoridad de otro origen.

La clave pública Ed25519 en /.well-known/agent-payment-policy-service-deployment.pem es la misma clave sin procesar que el agentWallet en el registro ERC-8004 de Solana de SameDayDesk. La clave de firma permanece fuera de línea y no se despliega. La respuesta JWS sigue siendo un sobre estricto; sus punteros de clave y registro usan cabeceras HTTP Link y el documento de registro ERC-8004. /healthz informa el ID de la declaración, la huella de la clave, el recuento de rutas, la caducidad y el estado activo para que la rotación pueda monitorearse. La declaración prueba el control de esa clave registrada y el enlace de servicio declarado. No autoriza, firma ni envía un pago del comprador.

Version 1.11.15 valida cada declaración de Bazaar contra su propio esquema JSON antes del inicio. Seis rutas más nuevas se liquidaron previamente con éxito mientras Coinbase rechazaba sus metadatos de descubrimiento porque sus ejemplos de salida omitían campos marcados como obligatorios por los mismos esquemas. Los ejemplos ahora cumplen, y bazaar-contract-audit.mjs verifica cada ruta pagada elegible para CDP Bazaar en vivo mediante sondas HTTP 402 sin credenciales, sin retener cabeceras ni valores de consulta. Las vías de liquidación x402 alternativas se informan como exclusiones explícitas en lugar de clasificarse erróneamente como declaraciones de Bazaar fallidas.

discovery-drift.mjs es una biblioteca y CLI sin credenciales que compara el descubrimiento de registros/catálogos con los requisitos de pago no remunerados en vivo para recurso, red, activo, amountAtomic y frescura de observación. No es una ruta pagada montada por defecto. Copiar y pegar:

node discovery-drift.mjs observe --url 'https://agent-economy-signal-x402-mainnet.bronzetti-andrea.workers.dev/premium/agent-brief' --bazaar-pay-to '0xbda48b29607b9dc66ef7e38b68ad53f2b17efb23'

Version 1.11.18 añade un embudo de calidad de fuentes al agregado público. Cada fuente de descubrimiento controlada ahora informa observaciones junto con actores distintos y repetidos en las etapas de descubrimiento, ruta pagada, desafío, intento de credencial y éxito pagado. Las tasas de desafío están disponibles tanto por solicitud como por actor, de modo que un rastreador de alta frecuencia ya no parece un alcance amplio de máquinas. Las conversiones de desafío a pago se atribuyen a la fuente del primer desafío observado. Los agentes de usuario sin procesar, las direcciones de red y los identificadores de actores permanecen privados y no se devuelven.

Version 1.11.19 inicia una cohorte separada de fuentes prospectivas de proveedores de IA. Utiliza tokens HTTP exactos publicados por el proveedor para distinguir el tráfico de búsqueda, recuperación de usuario y entrenamiento de OpenAI, Anthropic y Perplexity, además de los rastreos de agentes de Google Cloud Vertex. Google-Extended se excluye intencionalmente porque Google afirma que no tiene una cadena de agente de usuario HTTP distintiva. La cohorte de detalle tiene su propia línea base, preserva los registros genéricos históricos, informa el mismo embudo de actores y trata cada etiqueta como una observación no autenticada, no como prueba de referencia.

Version 1.11.20 repara los metadatos de recurso consumidos por agentes de billetera con capacidad de pago. Cada uno de los catorce desafíos x402 v2 ahora lleva el serviceName validado a nivel de proveedor y cinco etiquetas acotadas de capacidad de ruta en el objeto de recurso estándar de nivel superior. El inicio falla de forma segura si la cobertura de rutas pagadas y la cobertura de metadatos divergen. La auditoría de contrato de Bazaar ahora rechaza una ruta cuya extensión es válida pero cuyo nombre de recurso o etiquetas están ausentes o son inválidas. Los precios, salidas, liquidación, privacidad, rutas y términos nativos de MPP no cambian.

Version 1.12.0 añade /chain/transaction-receipt a 0,002 USDC después de que un experimento de mercado en vivo encontrara liquidación a nivel de proveedor para utilidades de cadena baratas pero dos fallos de entrega sin gasto de una ruta de recibo competidora muy vista. La nueva ruta acepta un hash de transacción minada de Base o Ethereum y devuelve estado normalizado, tiempo de bloque, campos de gas y tarifas, eventos de Transferencia ERC-20 decodificados y transferencias canónicas de USDC. Los hashes inválidos y las redes no compatibles se rechazan antes del pago. Los registros sin procesar, el acceso a la billetera, la firma y la transmisión están fuera del límite del producto.

Version 1.12.1 repara el límite de entrega autenticada para la tienda /commerce/payment-offer-preflight de Solana. Después de que la puerta de enlace de Solana haya verificado y liquidado su propio pago x402 o MPP, su cabecera interna privada ahora llega directamente al producto determinista en lugar de encontrar una segunda puerta de pago de Base. Las solicitudes sin la cabecera privada exacta conservan el comportamiento ordinario de x402 y MPP de Base. Las credenciales objetivo y los pagos objetivo permanecen fuera del límite del producto de verificación previa.

Version 1.12.2 mantiene las superficies de descubrimiento propiedad del vendedor sincronizadas con el catálogo canónico de acciones pagadas. La tarjeta de agente A2A ahora usa la versión real del servicio, conserva la habilidad de catálogo agregado primero y añade una habilidad explícita solo de descubrimiento por ruta pagada. El documento de registro ERC-8004 conserva sus puntos de entrada de protocolo y añade las mismas URL directas de acción pagada. El descriptor A2A reutiliza el ID de habilidad agregada canónica, y los mensajes entrantes deben llevar el rol de usuario normativo, el ID de mensaje y al menos una parte. Estos cambios mejoran el descubrimiento de rutas pero no afirman soporte para operaciones de tarea A2A no implementadas.

Version 1.12.3 convierte esa lección de descubrimiento en una auditoría opcional del vendedor. Establezca surfaceAudit=true en la ruta de descubrimiento pagada existente para verificar si la ruta esperada aparece en la tarjeta de agente A2A pública del objetivo, el documento de registro ERC-8004 y el catálogo de acciones. La recuperación del objetivo se limita a tres rutas JSON fijas del mismo origen, fija una respuesta DNS completamente pública, rechaza redirecciones, limita cada respuesta a 512 KiB y agota el tiempo después de cinco segundos. El valor predeterminado sigue siendo solo catálogo y no recupera el origen del objetivo.

Version 1.12.4 otorga a la sonda JSON POST /work/opportunity-preflight el mismo contrato completo de entrada y salida de Bazaar que la ruta GET existente. Esto elimina errores de esquema de descubrimiento de máquinas sin cambiar el precio, la validación, el controlador, la respuesta o el comportamiento de pago. Un POST vacío no autenticado sigue siendo un desafío solo de descubrimiento; una llamada pagada debe seguir suministrando y vinculando el cuerpo requerido. Version 1.13.0 añade un producto de recibo de transacción finalizado de Solana por 0.002 USDC. Valida la firma y cualquier claim opcional de mint, destinatario, monto y pagador antes del pago, y luego devuelve estado finalizado acotado, tarifa, deltas de propietario de tokens SPL, deltas canónicos de USDC y hallazgos de coincidencia deterministas. Lee estado público de RPC solo después de la liquidación y no tiene billetera, firma, custodia ni autoridad de transmisión. La ruta está disponible a través de Base x402, MPP nativo, MCP, A2A y la pasarela de pago separada de Solana.

La versión 1.11.23 añade un puente de compatibilidad limitado para clientes MCP que reintentan un tools/call pagado con el encabezado HTTP x402 PAYMENT-SIGNATURE pero no copian el mismo payload firmado en _meta["x402/payment"]. El comerciante decodifica solo un encabezado acotado con forma de objeto en tools/call, nunca sobrescribe los metadatos MCP canónicos, y pasa el resultado al verificador @x402/mcp existente. El puente no confía en el encabezado, no cambia los términos de pago ni omite la validación de firma, monto, activo, red, nonce o liquidación.

La versión 1.11.24 publica las opciones de pago x402 en vivo exactas de cada herramienta en los metadatos MCP tools/list. Los clientes compatibles pueden inspeccionar precio, activo, red, destinatario y esquema antes de llamar, y luego adjuntar un payload firmado nuevo al primer tools/call en lugar de depender de una reintroducción de desafío. La verificación y liquidación en tiempo de ejecución siguen siendo autoritativas, y la ruta de desafío no pagado no cambia.

La versión 1.11.26 afina el contrato de selección orientado a máquinas para /commerce/payment-offer-preflight: compara los desafíos de pago x402 y MPP y los términos antes de la autorización del comprador. El producto de 0.005 USDC aún acepta una URL GET HTTPS pública exacta y devuelve ofertas normalizadas, verificaciones de vinculación de URL y dominio, hallazgos de caducidad y paridad económica. Rechaza credenciales, objetivos locales o no públicos, parámetros sin resolver y redirecciones, fija un resultado DNS público, lee solo encabezados de respuesta, nunca firma ni envía un pago objetivo, y no devuelve estado de desafío opaco.

La versión 1.11.27 mantiene el contrato de agente compacto /skill.md sincronizado con el catálogo de acciones de catorce rutas. Ahora nombra la verificación previa de ofertas de pago en su vocabulario de selección y declara el límite de inspección de objetivos: sin credencial, firma o pago de objetivo, redirección o lectura del cuerpo de respuesta. Una prueba de regresión mantiene este producto de autorización de comprador enfocado presente en futuras versiones.

La versión 1.11.28 elimina el modo de fallo manual del inventario de rutas. El contrato compacto ahora renderiza y valida cada acción pagada, precio exacto y protocolo compatible desde el catálogo de acciones de máquina canónico. Los contratos de acción vacíos, malformados o duplicados fallan de forma cerrada, por lo que una futura adición de ruta no puede dejar la superficie de agente compacta silenciosamente obsoleta.

La versión 1.11.29 añade una transferencia gratuita de catálogo de máquina para AgenticTrade sin colocar una segunda pasarela de pago frente a SameDayDesk. El catálogo indica a los compradores llamar directamente a la URL de acción seleccionada, satisfacer su desafío x402 o MPP vinculado a la ruta, y opcionalmente llevar la etiqueta de origen agentictrade-v1 declarada. Esa etiqueta entra en el embudo medido de descubrimiento a pago, no almacena ningún token bruto, y no puede cambiar precio, pago o acceso.

La versión 1.11.30 añade un diagnóstico de proxy AgenticTrade sin valor en la respuesta del catálogo. Solo informa qué nombres de encabezado X-ACF-* llegaron al origen y si los campos de firma, marca de tiempo y prueba de uso están presentes. Nunca devuelve sus valores, y las respuestas proxy se marcan como private, no-store.

La versión 1.11.31 incluye el mismo diagnóstico sin valor en el cuerpo del catálogo proxy porque AgenticTrade devuelve intencionalmente solo sus propios encabezados de facturación al llamante. Las respuestas directas del catálogo permanecen sin cambios y se pueden almacenar en caché públicamente.

La versión 1.9.7 concilia de forma privada cada referencia posterior a la línea base contra su recibo canónico de Base. Un registro se acepta solo cuando la transacción tuvo éxito, exactamente una transferencia canónica de USDC de Base llegó al tesoro configurado, el monto atómico coincide con la respuesta pagada y el remitente de la transferencia coincide con el seudónimo del pagador de la solicitud cuando está disponible. Las referencias duplicadas y todas las discrepancias fallan de forma cerrada. El libro de contabilidad privado con modo 0600 conserva la referencia; la salida pública de salud y demanda expone solo recuentos agregados de liquidación, montos atómicos por clase de evidencia y ruta, recuentos de problemas y un estado de error genérico.

La versión 1.9 añade soporte MPP evm/charge de la misma ruta a las doce capacidades HTTP pagadas sin reemplazar el middleware x402 existente. Una solicitud no pagada ahora lleva tanto WWW-Authenticate: Payment como PAYMENT-REQUIRED. Las credenciales MPP nativas usan Authorization: Payment y las llamadas exitosas devuelven Payment-Receipt; x402 conserva sus extensiones Bazaar, identificador de pago, oferta/recibo firmado y PAYMENT-RESPONSE. Los desafíos MPP están vinculados al método canónico, la ruta y la consulta ordenada. Ambos protocolos participan en telemetría segura para la privacidad y reproducción de solicitudes, y OpenAPI 3.1 expone ofertas x-payment-info válidas por operación.

La versión 1.9.3 genera dos vistas de descubrimiento específicas de registro desde la misma fuente de ruta y precio. /openapi.json lleva el precio USD estructurado, declaraciones de protocolo, guía de agente, declaraciones de autenticación de ruta pública y esquemas de respuesta veraces utilizados por AgentCash y MPPScan. /mpp-openapi.json lleva el offers[] MPP oficial sin campos planos incompatibles. Los ID de operación estables y las etiquetas de capacidad hacen que el catálogo público sea más fácil para que los agentes lo busquen, clasifiquen e invoquen. Los desafíos 402 en tiempo de ejecución siguen siendo autoritativos para ambas vistas.

La versión 1.23.6 extiende la reproducción vinculada a la solicitud a cada ruta POST JSON pagada y vincula la huella de reproducción tanto a la credencial de pago liquidada previamente exacta como a los bytes de solicitud bruta exactos. Esto permite que una respuesta POST exitosa perdida se reproduzca sin ejecutar el controlador ni cobrar nuevamente, mientras que una credencial, cuerpo, entrada, pagador o término de pago cambiado falla con un HTTP 409 sin cargo. La versión 1.23.7 publica un contrato de efecto de solo lectura experimental en /.well-known/paid-action-effects.json, en cada operación OpenAPI POST pagada, y en los encabezados de respuesta. También mantiene las solicitudes POST pagadas no pagadas fuera de la telemetría de la aplicación, al tiempo que declara que el estado de desafío del protocolo puede seguir existiendo y que la reproducción de respuesta de pago no es idempotencia de efecto comercial. No se reclama la adopción de ningún estándar externo. La versión 1.8 añade una verificación previa determinista de oportunidades pagadas. El llamante proporciona recompensa, tiempo de ejecución, costo de oportunidad por hora, cómputo, gasto obligatorio, valor reutilizable, competencia y una probabilidad de selección explícita. El resultado devuelve attempt, verify_first o abandon, economía de punto de equilibrio transparente, puertas de acceso y financiamiento estrictas, y una tarjeta opcional de Radar de Liquidación con fecha. No extrae un tablero restringido ni toca una cuenta, claim, oferta, pago o envío de la plataforma de origen. La versión 1.7 añadió reproducción idempotente vinculada a la solicitud para compradores HTTP que proporcionan la extensión de identificador de pago x402. Una respuesta JSON exitosa se almacena en caché durante 15 minutos en el volumen privado de Railway. La clave de caché es un HMAC del ID de pago lógico, y el enlace cubre la URL canónica completa, el método HTTP, el pagador, la red, el activo, el monto y el destinatario. Los ID de pago brutos, las direcciones de pagador y las URL de solicitud no se almacenan. Una reintroducción exacta recibe la respuesta original y el recibo de liquidación firmado sin un segundo pago; entrada, pagador o términos de pago cambiados devuelven un HTTP 409 sin cargo. Las reproducciones se cuentan por separado de los nuevos eventos de pago exitoso.

Los rastreadores de agentes observados usan varias convenciones de descubrimiento. El manifiesto canónico sigue siendo /.well-known/x402, con alias compatibles en /.well-known/x402.json, /x402.json y /api/x402. El documento OpenAPI compatible con AgentCash sigue siendo /openapi.json, con /openapi.yaml y /swagger.json devolviendo el mismo documento JSON. El descubrimiento oficial de MPP usa /mpp-openapi.json, con /openapi.mpp.json como alias. GET /mcp devuelve un descriptor de transporte gratuito; el descubrimiento real de MCP y las llamadas de herramientas pagadas usan HTTP transmisible en POST /mcp. Los agentes que prefieren un contrato de instrucciones compacto pueden leer /skill.md (o /SKILL.md), mientras que /api/actions devuelve las trece acciones GET canónicas con su URL, descripción, precio atómico exacto en USDC, tipo MIME, red y payTo. Los clientes de Agent Skills pueden enviar X-SameDayDesk-Agent-Source: agent-skills-v1 en la solicitud inicial y la reproducción pagada. La telemetría reduce ese valor exacto permitido a la etiqueta segura para el público agent-skills y nunca almacena el encabezado bruto. Esto es atribución declarada y falsificable, no autenticación, y no puede cambiar el precio, el pago o el acceso. La tarjeta A2A v1.0 en /.well-known/agent-card.json anuncia una habilidad gratuita acotada, discover-x402-paid-actions. POST /a2a/message:send devuelve ese catálogo exacto como un mensaje directo A2A, lo que brinda a los clientes A2A una ruta basada en estándares desde el descubrimiento de agentes hasta las acciones x402 pagadas existentes sin reclamar ejecución arbitraria de tareas.

El agent-card.json en la raíz del repositorio es un manifiesto de compatibilidad para el importador actual de GitHub del Registro Global A2A. Apunta de vuelta a la tarjeta de agente v1.0 canónica y al documento OpenAPI; no reemplaza la tarjeta de producción. El manifiesto de propiedad generado por el propio registro se aloja por separado en https://samedaydesk.com/.well-known/agent-card.json; la tarjeta A2A v1.0 compatible con estándares sigue siendo canónica en agents.samedaydesk.com.

Observador de sombra de PreLiquidación

morpho-preliquidation-shadow.mjs es el carril de evidencia directa de solo observación seleccionado por el censo completo de Base. Observa los cinco mercados que concentran la ejecución histórica, deriva el umbral de salud real de PreLiquidación de cada mercado desde LLTV y pre-LLTV, verifica cada autorización observada directamente en un bloque de Base explícito y usa cursores de eventos por contrato.

Las nuevas transacciones de ejecución se reproducen a través del motor determinista de archivo-RPC, hasta 20 por ejecución. El registro incluye latencia de detección, incentivo bruto de activo de préstamo y gas nativo, manteniendo el límite explícito de que los costos de swap, financiamiento, fallo, competencia y MEV permanecen fuera de la reproducción. Las posiciones por debajo del piso explícito de observación de deuda de 1 USD se clasifican como polvo en lugar de oportunidades.

node morpho-preliquidation-shadow.mjs \
  --state /data/morpho-preliquidation-shadow-state.json \
  --history /data/morpho-preliquidation-shadow-history.ndjson

Los archivos de estado e historial se fuerzan al modo 0600. Un cambio material significa una autorización nueva o eliminada, una transición hacia o fuera de la ventana de riesgo específica del protocolo, un movimiento grande de liquidez o utilización, o una nueva ejecución verificada de PreLiquidación. Ninguna billetera, firmante, autorización, custodia o principal forma parte del observador.

La devolución de llamada de Agoragentic es un puente de distribución de mercado separado. El mercado maneja el enrutamiento del comprador, la liquidación y la contabilidad del vendedor, mientras que la devolución de llamada realiza la misma auditoría de preparación para búsqueda de IA de producción detrás de un límite de seguridad pequeño por IP. Los clientes de agentes directos continúan usando la ruta x402 pagada.

El puente the402 es una segunda ruta de distribución de mercado. Autentica despachos de trabajos firmados con verificación HMAC con marca de tiempo, acepta devoluciones de llamada solo en el origen oficial de la API y envía un entregable de auditoría estructurado para liquidación automática. THE402_API_KEY, THE402_WEBHOOK_SECRET y THE402_SERVICE_ID son variables de entorno solo de Railway.

El mismo servicio también aloja dos transferencias de afiliados gratuitas y divulgadas utilizadas por las guías verificadas de SameDayDesk: /go/topify y /go/manychat. Generan y almacenan en caché los enlaces firmados caducantes de Agent Hansa en el servidor, validan el host de redirección, no exponen ninguna clave de API y devuelven noindex, nofollow más no-store.

Implementación del riel original

Un servidor Node/Express que devuelve HTTP 402 Payment Required cuando no está pagado y sirve el recurso después del pago, liquidando USDC en Base mainnet directamente a nuestra propia billetera:

payTo = 0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee

Verificado en vivo (junio a agosto de 2026). El servidor arranca y devuelve respuestas 402 correctas con requisitos de pago legibles por máquina. El canario Morpho es amount=20000 = 0.02 USDC, network=eip155:8453, y asset=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 = Base USDC, payTo igual a nuestra wallet, más una extensión de descubrimiento Bazaar con esquemas de entrada y salida.

Decisión de producción actual

Ruta	¿Cuenta/API key?	¿Base mainnet?	Alcance de descubrimiento
Facilitador CDP (`api.cdp.coinbase.com/platform/v2/x402`)	Sí, cuenta Coinbase CDP más `CDP_API_KEY_ID` y `CDP_API_KEY_SECRET`	Sí	Predeterminado de producción. Catálogo CDP Bazaar, búsqueda de comerciantes y búsqueda semántica después del primer acuerdo
Facilitador público xpay (`facilitator.xpay.sh`)	Ninguna	Sí (`eip155:8453`, esquema exacto)	Ruta de acuerdo de respaldo con solo descubrimiento autopublicado
Facilitador público x402.org (`x402.org/facilitator`)	Ninguna	No, solo red de pruebas Base Sepolia	Catálogo de pruebas separado en `x402.org/facilitator/discovery/resources`

La producción usa CDP. Las primeras once rutas pasaron la verificación en vivo de CDP y completaron un acuerdo real. Las ocho originales aparecen en el descubrimiento de comerciantes de Bazaar. Las tres rutas de decisión Morpho más nuevas tienen recibos de acuerdo exitosos, y un pagador financiado distinto produjo isValid: true más el estado de extensión Bazaar processing para las tres. Aún no ingresaron al descubrimiento de comerciantes después de la ventana de caché documentada y un acuerdo fresco, por lo que esto se rastrea como un incidente de indexación downstream de CDP en lugar de una falla de metadatos de ruta. La reproducción sin secretos está adjunta al problema x402 #2156. Mantén xpay como respaldo de continuidad sin clave, no como el facilitador normal de producción.

La duodécima ruta, /work/opportunity-preflight, está en vivo a 0.05 USDC y completó un acuerdo excluyendo al propietario para QA de integración e indexación. La decimotercera ruta, /distribution/agent-discoverability-audit, está en vivo a 0.05 USDC y productiviza el benchmark de catálogo ciego a marca utilizado en SameDayDesk mismo. Consulta Bazaar, Agentic Market, Agent402, Circle, AgenticTrade, el catálogo oficial MPP, MPPScan, PayanAgent, x402.jobs y la búsqueda pública de 8004Market sin credenciales de catálogo ni pagos, preserva el orden nativo del registro e informa cobertura, rango, competidores por encima del objetivo y próximas acciones basadas en evidencia como observaciones puntuales en lugar de una puntuación compuesta. Bazaar y Agentic Market son explícitamente una familia de fuentes de Coinbase, por lo que la salida no infla el alcance independiente contando ambas vistas como canales de adquisición separados. PayanAgent está etiquetado como una superficie agregadora dependiente porque su catálogo incluye registros del ecosistema como suministro de origen Coinbase; su rango de recuperación es útil, pero no es suministro subyacente independiente. 8004Market está etiquetado como una superficie de propagación de identidad porque indexa identidades del Registro de Agentes Solana en cadena; la recuperación allí prueba la propagación pública de identidad y capacidades, no una llamada de comprador, acuerdo, o demanda independiente. Una verificación opcional y acotada de superficie de vendedor informa si una ruta exacta aparece en la Tarjeta de Agente pública del objetivo, el registro ERC-8004 y el catálogo de acciones sin debilitar el método de catálogo predeterminado sin credenciales.

La versión 1.11.42 agrega un contrato POST /work/opportunity-preflight de cuerpo JSON para compradores de flujos de trabajo de máquinas mientras preserva el contrato GET existente y el precio de 0.05 USDC. Las sondas de registro HEAD o POST vacías sin credenciales pueden inspeccionar el desafío de pago; la entrada pagada faltante o malformada sigue siendo un 400 sin cargo. Esto hace que un producto útil sea directamente invocable desde mercados de flujos de trabajo de centavos enteros sin una ruta duplicada ni un precio engañoso.

La versión 1.11.43 agrega una muestra gratuita exacta GET /work/opportunity-preflight?trial=1 para catálogos de máquinas. Devuelve aritmética fija con sample: true y charged: false, no realiza trabajo externo y no acepta entradas de llamadores. Las llamadas GET y POST personalizadas siguen sujetas a pago de 0.05 USDC.

La versión 1.11.41 refleja la oferta canónica x402 v2 Payment-Required en el cuerpo 402 que de otro modo estaría vacío para registros que aún indexan el cuerpo heredado. El preflight de oferta de pago también expone una ruta POST de cuerpo JSON equivalente para constructores de flujos de trabajo mientras preserva la ruta GET validada.

La versión 1.11.40 agrega x402.jobs como una décima vista de búsqueda pública. El adaptador usa una consulta de palabras clave compacta, determinista y divulgada porque la búsqueda de x402.jobs es léxica en lugar de semántica, luego preserva su orden de popularidad público y verifica la ruta objetivo esperada. El servidor propio verificado de SameDayDesk ahora lista las catorce rutas Base con una línea base de cero llamadas y cero valor, por lo que la actividad posterior se puede medir sin llamar a la validación ni listar la demanda de tráfico.

La versión 1.11.39 agrega la prueba pública de propiedad del servidor x402.jobs en /.well-known/x402-verification.json. El desafío es solo una reclamación de directorio público y no otorga autoridad de API, wallet o pago.

La versión 1.11.38 agrega una ruta de acceso distinta de Circle Gateway Nanopayments para el preflight de oferta de pago al mismo precio de 0.005 USDC. Usa el middleware oficial de vendedor @circle-fin/x402-batching 3.3.0, anuncia requisitos x402 GatewayWalletBatched en las redes que Circle informa en tiempo de ejecución y liquida en el saldo de Gateway del vendedor. Las rutas existentes exactas de Base, MPP nativo, MCP, implementación de producto y directas no cambian, por lo que una interrupción de Gateway no puede bloquearlas. El OpenAPI principal y el manifiesto x402 exponen la ruta alternativa; el OpenAPI de MPP no la etiqueta erróneamente como una ruta MPP.

La versión 1.11.37 agrega 8004Market como una novena vista de búsqueda pública en la auditoría de descubribilidad pagada. Coincide con el objetivo por orígenes de servicio duraderos y rutas incrustadas en los metadatos de identidad Solana indexados mientras preserva el orden semántico nativo del servidor de 8004Market.

La versión 1.11.36 expande los metadatos de identidad Solana con las capacidades reales a nivel de ruta y las superficies de descubrimiento OpenAPI, skill, x402 y MPP de Base y Solana después de que el primer benchmark congelado de 8004Market expusiera cero recuperación de capacidades desde la descripción de lanzamiento más amplia.

La versión 1.11.35 agrega /.well-known/agent-registration.json, un documento de registro duradero compatible con ERC-8004 para el Registro de Agentes Solana. Vincula las superficies MCP y A2A existentes, la tienda Solana x402 y MPP, la wallet de liquidación Solana dedicada y soporte x402 explícito. El identificador de activo en cadena se inyecta solo después de un registro exitoso, por lo que el URI permanece estable y el documento nunca inventa una identidad antes de que exista.

La versión 1.11.34 agrega la búsqueda pública de PayanAgent como una octava vista de registro con una etiqueta de dependencia explícita. La versión 1.11.33 agregó la búsqueda pública de MPPScan; su orden de búsqueda de texto público permanece separado del estado de listado directo. La versión 1.11.32 agregó AgenticTrade; el catálogo plano oficial de MPP permanece clasificado localmente.

La ruta de preflight de oferta de pago está en vivo a 0.005 USDC. Productiviza el límite de autorización del lado del comprador: obtén los encabezados no pagados de una ruta GET pública exacta, normaliza las ofertas x402 y MPP, verifica el enlace de URL y ámbito, detecta expiración y desviación entre protocolos, y devuelve una decisión acotada antes de que el comprador firme el pago objetivo.

Cómo funciona el riel (por qué "sin cuenta" es seguro)

El esquema exact liquida USDC mediante una EIP-3009 transferWithAuthorization: el comprador (agente) firma una autorización que mueve USDC directamente desde su wallet a nuestra payTo en cadena. El facilitador solo verifica la firma y transmite la transacción; nunca retiene el dinero. Entonces:

Cualquiera que sea el facilitador que elijamos, el USDC llega a nuestra wallet payTo.
Tenemos la clave de payTo; el facilitador no.
CDP y xpay son rutas de facilitador no custodiales. CDP retransmitió los ocho canarios de vendedor en vivo y los montos exactos de USDC llegaron a nuestra wallet.

Este es el mismo riel que Frantic usó para pagar USDC real de mainnet a esta wallet, por lo que ya sabemos que la liquidación a 0x8904…3Cee funciona.

Respuestas a las cinco preguntas

1. Facilitador + autonomía

El facilitador público x402.org solo admite la red de pruebas Base Sepolia (eip155:84532); su endpoint /supported no lista eip155:8453. Mainnet a través de x402.org es imposible.
La liquidación en Base mainnet no requiere estrictamente una cuenta Coinbase CDP. El facilitador público xpay (https://facilitator.xpay.sh) admite el esquema exacto eip155:8453 de Base mainnet sin cuenta ni API key (verificado contra su endpoint en vivo /supported). Este es el camino de mainnet totalmente autónomo.
El facilitador CDP requiere una cuenta CDP y claves API. Su ventaja es el descubrimiento de comerciantes de Bazaar, la búsqueda semántica y la superficie de comprador MCP de Bazaar.
La producción eligió CDP después de una matriz de solo verificación en vivo y ocho acuerdos exitosos. xpay sigue siendo el respaldo sin clave.

2. Código exacto del vendedor

Consulta server.js. Línea de paquete actual (NO el plano heredado x402-express@1.x):

@x402/express     2.16.0   paymentMiddleware, x402ResourceServer
@x402/core        2.16.0   HTTPFacilitatorClient   (import from @x402/core/server)
@x402/evm         2.16.0   ExactEvmScheme          (import from @x402/evm/exact/server)
@x402/extensions  2.16.0   declareDiscoveryExtension (import from @x402/extensions/bazaar)
@coinbase/x402    2.1.0    createFacilitatorConfig (only needed for CDP mainnet)
mppx              0.8.15   native MPP EVM charge challenge, credential, and receipt support

Cableado principal:

const facilitatorClient = new HTTPFacilitatorClient(
  createFacilitatorConfig(process.env.CDP_API_KEY_ID, process.env.CDP_API_KEY_SECRET)
);
const resourceServer = new x402ResourceServer(facilitatorClient)
  .register("eip155:8453", new ExactEvmScheme());

app.use(paymentMiddleware(
  { "GET /premium": { accepts: [{ scheme: "exact", price: "$0.01",
      network: "eip155:8453", payTo: "0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee" }],
      description: "...", mimeType: "application/json", extensions: { ... } } },
  resourceServer
));

3. Descubrimiento de Bazaar

El extensions de la ruta usa declareDiscoveryExtension({ input, inputSchema, output, outputSchema }) (already in server.js). Esto anuncia la ruta y sus esquemas JSON en el payload 402 (verificado presente en la respuesta en vivo). Aparecer en el CDP Bazaar requiere el facilitador CDP: CDP cataloga una ruta después de su primer acuerdo exitoso. La búsqueda de comerciantes de producción devuelve las ocho rutas originales de SameDayDesk; las tres rutas de decisión Morpho más nuevas tienen acuerdos CDP exitosos y extensiones Bazaar processing aceptadas, pero permanecen ausentes más allá de la ventana de caché documentada. CDP también encuentra las rutas originales de Morpho y de auditoría profunda a través de la búsqueda semántica. Usa la búsqueda de comerciantes como evidencia del estado del catálogo CDP, no como el recuento canónico de capacidades de SameDayDesk; el manifiesto propio, MCP, A2A y las superficies OpenAPI permanecen completas en catorce.

CDP rechazó tres payloads de rutas más antiguas cuyas descripciones de descubrimiento tenían 535, 581 y 629 caracteres, aunque la validación local de extensiones pasó. Las reescrituras concisas de 294, 258 y 301 caracteres pasaron. Una prueba de límite estándar de x402 2.22.0 aisló más tarde el borde de compatibilidad exacto: 501 caracteres fue rechazado, mientras que 500 caracteres alcanzaron la verificación de firma del facilitador con las cuatro extensiones intactas. Las pruebas de inicio y superficie ahora rechazan cada recurso por encima de 500 puntos de código Unicode. Ejecuta la verificación en vivo de CDP antes de un canario financiado.

4. Verificación del acuerdo

Después de una llamada pagada, confirma que el USDC llegó a payTo en Base mainnet. El flujo 402/200 también devuelve un encabezado PAYMENT-RESPONSE con datos de liquidación. De forma independiente:

# USDC balanceOf(payTo) on Base mainnet via public RPC, no key:
curl -s -X POST https://mainnet.base.org -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
    "to":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "data":"0x70a082310000000000000000000000008904df3de6dfee6a7c8cc38619d2f17806213cee"
  },"latest"]}'

El resultado es USDC atómico hexadecimal (divide por 1e6). O usa nuestro verificador de saldo existente de Base mainnet. O ve la wallet en https://basescan.org/address/0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee

5. Ruta recomendada más limpia

Despliega en CDP para la tienda de producción. Preserva la liquidación directa de USDC y agrega el catálogo, la búsqueda semántica, la búsqueda de comerciantes y la superficie de comprador MCP de Bazaar. Mantén xpay configurado como la ruta de recuperación sin clave.

Pasos de despliegue (Railway)

El repositorio es una app Node sin configuración: npm start ejecuta node server.js y se vincula a process.env.PORT (Railway lo establece).

Despliega este directorio directamente o envía el código fuente del repositorio.

Establece las variables de entorno en el servicio de Railway:

PAY_TO=0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee
NETWORK=eip155:8453
PRICE=$0.05
FACILITATOR=cdp
CDP_API_KEY_ID=<CDP API key ID>
CDP_API_KEY_SECRET=<CDP API key secret>
MPP_SECRET_KEY=<random secret of at least 32 bytes>
COMMERCE_DATA_DIR=/data
COMMERCE_ACTOR_SECRET=<random 32-byte secret>
COMMERCE_INTERNAL_TOKEN=<random owner-canary token of at least 32 UTF-8 bytes>
COMMERCE_MCP_TYPED_SINCE=<ISO timestamp for the accepted typed-MCP producer generation>
COMMERCE_EXTERNAL_SINCE=<ISO timestamp after controlled launch canaries>
COMMERCE_AGENT_SOURCE_DETAIL_SINCE=<ISO timestamp after provider taxonomy release>
COMMERCE_SETTLEMENT_EVIDENCE_SINCE=<ISO timestamp after settlement-proof release>
COMMERCE_PAYER_CLASSES='[{"address":"0x...","class":"validation"}]'

La configuración principal de pago tiene valores predeterminados seguros. La telemetría de producción usa un volumen de Railway montado en /data más las dos variables secretas anteriores. Una solicitud MCP de validación de lanzamiento se atribuye solo cuando proporciona el token interno exacto y un único x-samedaydesk-validation-marker que coincida con [A-Za-z0-9._~-]{16,128}. La fila almacenada contiene solo el resumen SHA-256 separado por dominio del marcador. Nunca reutilice un marcador, persista su valor sin procesar con telemetría, ni clasifique la fila de validación operativa del vendedor resultante como demanda independiente, liquidación, contabilidad o ingresos.

Genere un dominio público para el servicio.

Verifique:

curl https://<your-domain>/healthz          # -> {ok:true, network:eip155:8453, ...}
curl -i 'https://<your-domain>/defi/morpho-position?address=0x...' # -> HTTP 402 + WWW-Authenticate and PAYMENT-REQUIRED

Complete una liquidación limitada por ruta descubrible, luego confirme la búsqueda de comerciante y la búsqueda semántica. Registre las liquidaciones del propietario como flujo de prueba, no como ingresos.

Recurra a xpay sin cambiar el código de ruta

Si CDP no está disponible y la continuidad importa más que el descubrimiento central, configure:

FACILITATOR=xpay

Vuelva a implementar. La liquidación base de mainnet continúa, pero las nuevas llamadas ya no alimentan las señales de calidad y actividad del CDP Bazaar.

Pruebe el riel en testnet primero (opcional)

FACILITATOR=testnet
NETWORK=eip155:84532

Utiliza x402.org + Base Sepolia (USDC falso) para validar el bucle completo 402→pago→200 antes de aceptar dinero real en mainnet.

Mercado de Claude Code

La raíz de este repositorio es un mercado de Claude Code. El catálogo es .claude-plugin/marketplace.json. El plugin autocontenido es plugins/samedaydesk-extract. Esa disposición es un formato diferente del paquete Agent Plugins 1.0 en plugins/samedaydesk-x402. Mantenga ambos.

Instalación ordinaria después de que este catálogo esté en la rama pública predeterminada:

/plugin marketplace add epistemedeus/x402-url-extractor
/plugin install samedaydesk-extract@samedaydesk-claude

Luego invoque /samedaydesk-extract:web-extract con una URL HTTPS pública, o 1–5 URLs más campos deseados explícitos para el lote. El descubrimiento no es remunerado. El pago permanece en el SameDayDesk 402 en vivo. La autoridad de comprador con alcance existente puede usarse cuando ya cubre el método, cuerpo y términos exactos en vivo. El listado y la instalación no otorgan ninguno. Los resultados de pago desconocidos se concilian en lugar de reintentarse. La instalación no es prueba de invocación de modelo, pago o demanda. Para el JSON de extracción ya retenido, invoque /samedaydesk-extract:explicit-record con --input, --mapping, --schema y un directorio --out nuevo. Esa habilidad no obtiene ni paga. Esto no es un envío al directorio oficial de plugins de Anthropic. Para una verificación previa HTTP sin credenciales y una ruta de compra @x402/fetch explícitamente autorizada contra POST /extract/batch (predeterminado) y GET /extract compatible con versiones anteriores, incluido un recibo de intento sin firmar opcional antes del envío y una conciliación de solo lectura, consulte examples/customer-x402. Ese ejemplo no hace que Claude sea capaz de pagar. Los alcances de credenciales MCP y HTTP permanecen distintos.

Comprobaciones del mantenedor desde la raíz del repositorio:

npm run test:claude-marketplace
npm run test:claude-marketplace:live
claude plugin validate .
claude plugin validate ./plugins/samedaydesk-extract --strict

No coloque a Claude en el PATH del sistema desde este repositorio. Use un binario ya presente o local a la tarea. El complemento de GitHub owner/repo permanece sin verificar hasta que el catálogo esté en la rama pública predeterminada. Hasta entonces, verifique un clon local de git en un perfil aislado nuevo, sin cambiar una instalación existente:

export CLAUDE_CONFIG_DIR="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-claude.XXXXXX")"
export CLAUDE_CODE_PLUGIN_CACHE_DIR="$CLAUDE_CONFIG_DIR/plugins"
export DISABLE_AUTOUPDATER=1 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
unset ANTHROPIC_API_KEY ANTHROPIC_AUTH_TOKEN CLAUDE_CODE_OAUTH_TOKEN CLAUDE_API_KEY
claude plugin marketplace add "$PWD" --scope user
claude plugin install samedaydesk-extract@samedaydesk-claude --scope user --yes
claude plugin list --json

Después de la inspección, unset CLAUDE_CONFIG_DIR CLAUDE_CODE_PLUGIN_CACHE_DIR para dejar de usar ese perfil. Los archivos temporales se conservan; no se proporciona una utilidad de limpieza.

Configuración nativa de Goose

Los archivos complementarios de Goose streamable_http viven en goose/. No instalan Goose, mutan un perfil predeterminado ni reclaman atribución de comerciante. Pagar POST /extract/batch o GET /extract con un cliente HTTP mantenido permanece en examples/customer-x402; la instalación de Goose sola no es capacidad de pago.

Perfil aislado copiable, con Goose ya instalado:

export GOOSE_PATH_ROOT="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-goose.XXXXXX")"
mkdir "$GOOSE_PATH_ROOT/config"
cp goose/goose.config.isolated.yaml "$GOOSE_PATH_ROOT/config/config.yaml"
GOOSE_TELEMETRY_OFF=1 GOOSE_DISABLE_KEYRING=1 goose info -v

goose info -v lee esa configuración aislada. No abre la sesión MCP. El descubrimiento no remunerado en vivo es una inicialización separada más una verificación de herramientas/list (npm run test:goose-native:live). Requiera extract y extract_batch con sus esquemas de entrada/salida en vivo; se aceptan herramientas adicionales no relacionadas. Un cargador de MCP de Goose fixture no es parte de este repositorio.

El YAML predeterminado no envía encabezados de origen. El goose/goose.config.with-declared-source.yaml opcional no está autenticado, no está en la lista blanca de comerciantes y no reclama atribución de comerciante.

Indicador de sesión:

goose session --with-streamable-http-extension "https://agents.samedaydesk.com/mcp"

Enlace profundo: goose/goose.deeplink.txt.

Verificación de empaquetado del mantenedor: npm run test:goose-native. Receta de registro sin conexión: goose/record.recipe.yaml más goose/record.workflow.md. Cuando Goose ya está instalado, valide en un perfil aislado nuevo con goose recipe validate goose/record.recipe.yaml. Esa verificación no es ejecución de modelo y no obtiene ni paga.

Habilidades de Hermes Agent

Hermes Agent (Nous Research) ya carga archivos portátiles de AgentSkills SKILL.md. Este repositorio no agrega un plugin de Hermes, YAML de MCP, billetera o segundo muro de pago. La habilidad de extracción existente es plugins/samedaydesk-x402/skills/web-extract/SKILL.md. La receta de cambio de página sin conexión es plugins/samedaydesk-x402/skills/page-change/SKILL.md.

Descubrimiento aislado copiable, sin tocar ~/.hermes ni llamar a un modelo:

export HERMES_HOME="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-hermes.XXXXXX")"
HERMES_HOME="$HERMES_HOME" HERMES_AGENT_SRC=/path/to/NousResearch/hermes-agent \
  python3 hermes/check-isolated-loader.py

El comerciante también sirve las tres habilidades portátiles en el índice bien conocido oficial /.well-known/skills/index.json. Después de implementar:

export HERMES_HOME="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-hermes.XXXXXX")"
hermes skills search https://agents.samedaydesk.com --source well-known
hermes skills inspect well-known:https://agents.samedaydesk.com/.well-known/skills/web-extract
hermes skills install well-known:https://agents.samedaydesk.com/.well-known/skills/web-extract --yes

check-isolated-loader.py requiere un perfil desechable nuevo y vacío, copia las tres habilidades y usa la API de descubrimiento oficial de Hermes agent.skill_utils. No instala Hermes globalmente, inicia sesión en un proveedor de modelos, abre una billetera ni ejecuta un modelo. El descubrimiento y la ejecución de pagos son verificaciones separadas.

.hermes/skills o .agents/skills local al proyecto dentro de una copia de git no se cargan automáticamente. Hermes requiere hermes skills trust para esa raíz. Eso es una puerta de aprobación del operador. Este paquete no agrega esos directorios.

Después de que las rutas de habilidades existan en la rama pública predeterminada, un usuario que ya tenga Hermes también puede ejecutar:

hermes skills install epistemedeus/x402-url-extractor/plugins/samedaydesk-x402/skills/web-extract
hermes skills install epistemedeus/x402-url-extractor/plugins/samedaydesk-x402/skills/page-change

Esa ruta de hub copia en el perfil de ese usuario y ejecuta el escaneo de seguridad de la comunidad. No lo ejecute contra un perfil ya autenticado desde este repositorio. Pagar POST /extract/batch o GET /extract con un cliente HTTP mantenido permanece en examples/customer-x402. Ese ejemplo no hace que Hermes sea capaz de pagar. Los alcances de credenciales MCP y HTTP permanecen distintos.

Notas de instalación copiables: hermes/INSTALL.txt. Verificación de empaquetado del mantenedor: npm run test:hermes-native. Prueba del cargador oficial con HERMES_AGENT_SRC configurado: npm run test:hermes-native:loader. Reproducción del adaptador de índice del sitio web, mismas reglas de perfil aislado, nunca contra ~/.hermes y nunca con --force o allow_private_urls: npm run test:hermes-native:well-known.

Ejecución local

npm install
npm start
# then:
curl -i 'http://localhost:3000/defi/morpho-position?address=0x...' # HTTP 402

Archivos

server.js — el servidor (facilitador/red/precio impulsado por entorno).
commerce-events.mjs — telemetría de demanda duradera segura para la privacidad.
mpp-dual-stack.mjs — adaptador de autorización y recibo MPP nativo de misma ruta.
morpho-position.mjs — instantánea Morpho determinista, estrés y verificaciones RPC.
morpho-protection.mjs — montos exactos de reparación bajo estrés y plantillas de acción sin firmar.
morpho-market-underwrite.mjs — integridad de mercado de múltiples fuentes, liquidez, concentración, salud del prestatario, historial, deuda incobrable y evidencia de PreLiquidación.
morpho-preliquidation-replay.mjs — economía histórica de eventos PreLiquidate a partir de lecturas directas de estado de bloque.
morpho-preliquidation-census.mjs — censo repetible de suministro, autorización y ejecución de Base para la selección interna de mercado.
package.json — dependencias fijadas exactas (verificadas para instalar e iniciar).
.claude-plugin/marketplace.json — catálogo del mercado de Claude Code.
plugins/samedaydesk-extract/ — plugin autocontenido de Claude Code (no Agent Plugins 1.0).
goose/: configuración nativa de Goose streamable_http, recetas de extracción y registro, y copia de flujo de trabajo.
hermes/ : notas de instalación aisladas de Hermes AgentSkills y verificador del cargador oficial.
examples/customer-x402/ — verificación previa sin credenciales más un ejemplo de compra @x402/fetch explícitamente autorizado para POST /extract/batch (predeterminado) y GET /extract compatible con versiones anteriores.
README.md — esta guía.
extract.mjs — servicio preexistente sin dependencias de "URL → datos estructurados limpios". Este es un recurso pagado natural para poner detrás de /premium: en el manejador de ruta, llame a su extractor en un parámetro de consulta ?url= y devuelva el resultado estructurado en lugar del marcador de posición {value:42}. Agregue ?url al Bazaar inputSchema cuando lo conecte.

Fuentes (primarias, verificadas en agosto de 2026)

Inicio rápido del vendedor x402: https://docs.x402.org/getting-started/quickstart-for-sellers
Documentación de CDP x402: https://docs.cdp.coinbase.com/x402/welcome
Soporte de red CDP (x402.org = solo testnet; CDP = mainnet + claves): https://docs.cdp.coinbase.com/x402/network-support
CDP Bazaar: https://docs.cdp.coinbase.com/x402/bazaar
Monorepo x402: https://github.com/coinbase/x402
npm: @x402/express, @x402/core, @x402/evm, @x402/extensions, @coinbase/x402
Facilitador público xpay en vivo /supported (Base mainnet, sin clave): https://facilitator.xpay.sh/supported