Autor original: Hendrix, investigador de Web3Caff Research
¿Cómo dominar fácilmente los puntos críticos del mercado, tendencias tecnológicas, avances en ecosistemas, situaciones de gobernanza... que están ocurriendo en la industria Web3? La columna «Análisis del Pulso del Mercado» lanzada por Web3Caff Research se adentra en la primera línea para explorar y filtrar los eventos candentes actuales, ofreciendo interpretación de valor, comentarios y análisis de principios. Ver la esencia a través de los fenómenos, síganos ahora para capturar rápidamente la dirección del mercado de primera línea de Web3.
Con la creciente capacidad de los agentes de IA para cubrir cada vez más tareas de extremo a extremo, la construcción de sistemas de pago orientados a agentes se ha convertido en un cambio que comerciantes tradicionales y proveedores de servicios deben realizar. Sin embargo, las soluciones existentes tienen sus propias limitaciones: los sistemas de pago tradicionales, como tarjetas de crédito o plataformas de pago de terceros, fueron diseñados originalmente para usuarios humanos reales, requiriendo complejos procesos de verificación de identidad y evaluación de riesgos, lo que no es aplicable para agentes; mientras que los nuevos protocolos de pago para agentes, como x402 (desarrollado y promovido por Coinbase) o MPP (Machine Payment Protocol, desarrollado por Tempo y Stripe), parecen crear un portal completamente nuevo, construido íntegramente para pagos on-chain, donde todo el pago se procesa en cadena y la seguridad se garantiza mediante la validación on-chain, lo que obliga a los proveedores de servicios a construir un sistema de pago diferente además de los canales de pago tradicionales, aumentando la barrera de entrada. Las soluciones de pago tradicionales y los nuevos protocolos de pago para agentes parecen carriles paralelos que no se fusionan bien, lo que también limita los servicios que los agentes pueden comprar de manera autónoma, generalmente dentro del ámbito amigable para Web3, impidiendo así la conexión masiva de flujos de trabajo. Para abordar esto, la Solana Foundation y Google Cloud han lanzado conjuntamente Pay.sh, posicionado como "la pasarela de pago entre los agentes y las infraestructuras de servicios empresariales", para conectar el último paso que permite a los agentes acceder a más servicios.
Aviso de cumplimiento normativo: El siguiente contenido es solo un análisis objetivo de Pay.sh, sus principios técnicos y reglas de diseño, y no constituye ninguna propuesta u oferta. No tome decisiones basadas en esta información y cumpla estrictamente con las leyes y regulaciones de su país y región (se recomienda encarecidamente a los lectores de China continental leer «Recopilación de leyes y regulaciones relevantes relacionadas con blockchain y criptomonedas en China continental y puntos clave»), y no participe en ningún comportamiento financiero relacionado que esté prohibido por las leyes de su país y región.
Pay.sh permite a los usuarios recargar rápidamente una cartera de Solana mediante tarjeta de crédito o stablecoins. Posteriormente, la cartera de Solana puede actuar como identidad y proxy de cuenta de pago para agentes en el mundo de recursos Web2. Cuando un agente necesita invocar un servicio, ya no es necesario registrar una cuenta o ingresar una clave API. La pasarela Pay.sh declarará la identidad legítima del agente, similar al sistema de identidad de Google, permitiendo al agente usar una identidad de cuenta unificada para comprar recursos de desarrollo, como Google Cloud o Alibaba Cloud, que antes eran difíciles de obtener.
API services compatibles actualmente con Pay.sh Fuente: Sitio web oficial del proyecto
El flujo de pago de Pay.sh es similar al muy comentado protocolo x402: ambos se basan en el código de estado HTTP 402. Cuando un agente identifica un servicio externo que necesita invocar, solicita el recurso de pago. El servidor responde con el código de estado 402 (Pago requerido), adjuntando al mismo tiempo detalles del pago, como el monto, el plan de tarifas, la dirección del beneficiario, la validez del pago, etc. Pay.sh analiza este contenido y solicita autorización a la cartera. Una vez completado el pago y generado el comprobante por la cartera, Pay.sh vuelve a realizar la solicitud de servicio portando el comprobante para obtener una respuesta normal. Para cubrir varios escenarios de uso de API, Pay.sh es compatible tanto con la lógica de pago de x402 como de MPP: cuando un servidor devuelve el código de estado 402, Pay.sh evalúa además el método de pago del servicio objetivo. Si se trata de un acceso único a datos (el pago otorga un permiso de acceso) o un tipo de acceso basado en uso (el pago otorga una cantidad fija de acceso), Pay.sh construye una transferencia única de cantidad fija y la transmite on-chain; si se trata de facturación continua o basada en sesión (pago único de una factura consolidada según el uso), Pay.sh admite el comprobante de autorización de sesión introducido por el protocolo MPP (Machine Payment Protocol), escribiendo el límite presupuestario en la autorización y devolviéndolo al servidor. Esto permite al agente invocar repetidamente un servicio en un corto período, evitando autorizaciones frecuentes del mismo tipo. Pay.sh actualizará el saldo restante en cada invocación, y cuando se agote la cuota o expire el servicio, automáticamente reiniciará la autorización de sesión. Pay.sh selecciona automáticamente la vía de pago más adecuada según los requisitos del servicio objetivo, lo que puede reducir costos de uso y gestión. Pay.sh también garantiza que la cartera siempre se almacene de forma segura localmente, solicitando confirmación al usuario solo cuando se necesita un pago. Cuando se devuelve información, Pay.sh distingue entre datos e instrucciones. Todo contenido externo devuelto por el proveedor de servicios (incluyendo títulos, cuerpo y descripciones de API) es considerado por Pay.sh como entrada no confiable; el agente no debe ejecutar directamente las instrucciones devueltas por el proveedor para evitar inyecciones maliciosas de prompts u otros ataques.
La mayor ventaja de Pay.sh es que también ofrece a los proveedores de servicios una pasarela fácil de implementar. Los proveedores de servicios no necesitan modificar masivamente su infraestructura de pago o API para integrar la pasarela de pago en su red de servicios. Solo necesitan proporcionar un archivo declarativo que especifique los parámetros relacionados con el pago para adaptarse a diversos escenarios de uso complejos. Por ejemplo, definiendo reglas de enrutamiento, se puede permitir que un agente use un servicio de forma gratuita hasta cierta cantidad, comenzando a cobrar después de exceder un límite, o incluso implementar tarifas escalonadas (diferentes precios según el uso). Además, Pay.sh ofrece funcionalidad de división de pagos: los fondos recibidos por el proveedor de servicios pueden enviarse automáticamente a múltiples direcciones, por ejemplo, un 2% para derechos de datos, un 5% para costos de nube, y el resto para operaciones propias. El proveedor solo necesita definir diferentes porcentajes o montos al configurar la dirección de recepción para lograr una liquidación multi-cuenta de una sola vez. Después del registro, los proveedores pueden publicar los datos de sus servicios API en el Pay Skill Registry, permitiendo a los agentes descubrir y seleccionar servicios API adecuados consultando el registro.
Pay.sh en sí no es un competidor de x402 y MPP. Mientras que los protocolos x402 y MPP buscan hacer que los pagos on-chain para agentes sean lo más confiables posible, Pay.sh pretende conectar los ecosistemas de pago Web2 y Web3, otorgando a los agentes la identidad correspondiente para acceder a recursos. La cartera del agente es tanto su identidad como su método de pago; ya no necesita registrarse por sí mismo en el sitio web del proveedor para obtener el servicio (actualmente, algunos proveedores podrían tratar el registro de agentes que imitan a humanos como una violación de sus términos). Además, la colaboración de Pay.sh con Google permite que la ejecución del proxy de API y la programación de tráfico del agente se realicen en Google Cloud, garantizando el cumplimiento de controles de acceso y registros, manteniendo el comportamiento del agente dentro de límites razonables. Pay.sh puede proporcionar un directorio de servicios filtrado y descubrimiento de precios, evitando que los agentes descubran servicios aleatoriamente en entornos de red sin protección, y permitiendo invocar diferentes métodos de pago de x402 y MPP. El proceso de servicio puede cumplir con los requisitos de cumplimiento empresarial en Google Cloud, completando así las capacidades de pago para agentes que los canales únicos de pago como x402 y MPP no cubren, al mismo tiempo que abre una entrada para que el comercio de agentes fluya hacia Web3. Además, Pay.sh también puede complementar el eslabón final de pago para varios protocolos comerciales de agentes lanzados por Google, como A2A (Agent2Agent Protocol) para comunicación y delegación de tareas entre agentes, AP2 (Agent Payments Protocol) para verificación de cumplimiento, UCP (Universal Commerce Protocol) para descubrimiento y ejecución de servicios, mientras que Pay.sh se encarga de la liquidación final sin fricciones del valor del servicio. La aparición de Pay.sh también perfecciona los eslabones del comercio de agentes Web2, convirtiéndose en el punto de convergencia del flujo de valor entre ambos mundos. Este paso también representa una oportunidad de mejora para el propio ecosistema de la cadena pública Solana. En el entorno del protocolo x402 existen muchas API de caparazón, donde los proveedores de servicios pueden violar los términos de servicio del proveedor original y revender sus servicios, como extraer datos de sitios web de bases de datos de manera maliciosa para revender, o encapsular API de modelos grandes para revender a otros. En este entorno, los agentes no pueden distinguir qué servicios están autorizados y cuáles son servicios maliciosos o basura. Mediante la pasarela de pago Pay.sh y la colaboración con Google, se espera que los agentes reduzcan los riesgos potenciales al usar servicios a través de Pay.sh. El lanzamiento de Pay.sh marca la entrada de la cadena pública Solana para respaldar y proporcionar infraestructura para los pagos de agentes, lo que no solo puede atraer más flujo de pagos Web2 a Solana, sino también mejorar las capacidades de las carteras de Solana y acelerar su adopción.
Sin embargo, Pay.sh está aún lejos de ser una solución de pasarela de pago perfecta. El registro de proveedores de servicios de Pay.sh carece actualmente de mecanismos de admisión y verificación descentralizada, lo que dificulta distinguir eficazmente servicios de caparazón de terceros no autorizados y servicios maliciosos. Los agentes corren un gran riesgo de conectarse a servicios falsos, causando pérdidas a los usuarios. Además, dado que Pay.sh no diseña el protocolo de pajo subyacente, la seguridad del proceso de pago recae más en el diseño del protocolo subyacente, introduciendo riesgos externos incontrolables para Pay.sh, y posibles fallos de pago debido a una adaptación insuficiente a diferentes protocolos. Desde la perspectiva del proveedor de servicios, a pesar del respaldo de la plataforma de Google, proveedores de API en diferentes países y regiones aún podrían mostrarse reacios a los servicios ofrecidos por Pay.sh debido a sus propios requisitos de cumplimiento normativo para la gestión de privacidad de datos y para los pagos. Esto no solo limitaría la cantidad de proveedores que usan Pay.sh, sino que también podría requerir que Pay.sh realice más esfuerzos de cumplimiento en el futuro. Sin embargo, en cualquier caso, el lanzamiento de Pay.sh marca un paso hacia la integración y aplicación de la infraestructura de pago para agentes, fusionando Web2 y Web3. Las carteras on-chain tendrán la oportunidad de convertirse en el respaldo para que los agentes participen en diversas tareas. Por lo tanto, podemos seguir observando los desarrollos posteriores de Pay.sh.
Diagrama de estructura de puntos clave:
Exención de responsabilidad: Este informe ha sido elaborado por Web3Caff Research. La información contenida es solo para referencia y no constituye ningún pronóstico, consejo de inversión, propuesta u oferta. Los inversores no deben basarse en dicha información para comprar, vender valores, criptomonedas o adoptar cualquier estrategia de inversión. La terminología utilizada y los puntos de vista expresados en el informe tienen como objetivo ayudar a comprender las tendencias de la industria y promover el desarrollo responsable de Web3, incluida la industria blockchain, y no deben interpretarse como puntos de vista legales explícitos o la opinión de Web3Caff Research. Las opiniones en el informe reflejan únicamente las opiniones personales del autor en la fecha indicada, son independientes de la posición de Web3Caff Research y pueden cambiar según circunstancias posteriores. La información y opiniones contenidas en este informe provienen de fuentes propias y no propias que Web3Caff Research considera confiables, y no cubren necesariamente todos los datos ni garantizan su precisión. Por lo tanto, Web3Caff Research no otorga ninguna garantía de su exactitud y fiabilidad, ni asume responsabilidad por errores y omisiones que surjan de cualquier otra manera (incluida la responsabilidad por negligencia hacia cualquier persona). Este informe puede contener información "prospectiva", que puede incluir predicciones y pronósticos; este artículo no constituye una garantía de ninguna predicción. Depender de la información contenida en este informe es completamente responsabilidad del lector. Este informe es solo para fines informativos y no constituye consejo de inversión, propuesta u oferta para comprar o vender valores, criptomonedas o adoptar cualquier estrategia de inversión, y le recomendamos cumplir estrictamente con las leyes y regulaciones relevantes de su país o región.
