Seguridad en Blockchain0x.
Los pagos de agentes mueven dinero real. Las decisiones arquitectónicas que protegen los fondos de los clientes, la postura de auditoría tal como está hoy y cómo contactarnos si encuentras algo incorrecto.
Lo que puede esperar de esta página.
Somos una empresa en etapa temprana que construye infraestructura a la que los clientes confiarán autoridad de pago. La confianza se construye sobre lo que puedes verificar, no sobre lo que te dicen. Esta página documenta cuatro cosas que los clientes y los investigadores de seguridad pueden verificar o exigirnos: las garantías arquitectónicas que se mantienen incluso si nos equivocamos en todo lo demás, el estado actual de nuestra postura de auditoría (incluido lo que aún no hemos hecho), el alcance de nuestra política de divulgación de vulnerabilidades y exactamente lo que recibe un reportante (reconocimiento, no dinero), y la vía de contacto para una divulgación responsable.
What this page is not: a marketing surface designed to look maximally serious about security. We did not invent security certifications we do not hold, did not list "compliance" with frameworks we have not audited against, and did not put trust badges on the page that we did not earn. When we have a SOC 2 attestation or a third-party penetration test report, those will be referenced here with the auditing firm, the date, and the scope. Until then, this page says so plainly.
Cuatro propiedades que se mantienen por construcción.
Las garantías a continuación son arquitectónicas: son propiedades de cómo se construye el sistema, no de cómo se opera. La seguridad operativa puede fallar (una clave filtrada, un despliegue mal configurado); las garantías arquitectónicas no dependen de que las operaciones diarias sean perfectas. Estas son las partes de la historia de seguridad en las que puedes confiar incluso en la peor semana de operaciones.
No custodial a nivel de plataforma
Blockchain0x no retiene fondos de clientes. Las billeteras son propiedad del agente (o del proveedor de custodia subyacente que el cliente ha conectado, como las Billeteras Programables de Circle o la Coinbase Smart Wallet). El servicio de Blockchain0x opera la superficie de desarrollo sobre esas billeteras - APIs, panel, identidad, política de gasto - y nunca tiene autoridad de firma sobre los saldos.
Política de gasto aplicada del lado del servidor, no en el agente
Los límites diarios, los techos por pago, las listas de permitidos de contrapartes y las ventanas de tiempo son evaluados por la API de billetera Blockchain0x en cada intención de pago antes de la liquidación. El tiempo de ejecución del agente no puede acceder al almacenamiento de políticas; un agente que recibe inyecciones de prompt aún no puede aumentar sus propios límites.
Confirmación de pago validada por recibo
Los recibos de pago presentados por la API son validados del lado del servidor contra la transacción emisora antes de que confirmen. Un cliente no puede falsificar un recibo localmente y presentarlo como prueba de pago; el paso de validación del recibo es el mismo modelo de confianza que utilizan las firmas de webhook de Stripe.
Firmas de webhook, no secretos compartidos en URLs
Cada evento de webhook que emitimos está firmado con HMAC-SHA256 sobre el cuerpo sin procesar utilizando un secreto de firma por inquilino. El secreto de firma nunca se envía en la URL o en la cadena de consulta. Los clientes verifican las firmas al recibirlas; proporcionamos implementaciones de referencia en la documentación.
Dónde estamos hoy, honestamente.
The table below is the current state of external audits, third-party reviews, and certifications. We update this page when any line changes - dates are real, scopes are real, and "planned" means scheduled with a firm, not aspirational.
Prueba de penetración de terceros
Planificado para el cuarto trimestre de 2026La primera prueba de penetración externa está programada para la segunda mitad del año. Alcance: aplicación web, APIs públicas, superficie de webhook, autenticación del panel. El resumen del informe completo se publicará aquí cuando esté completo.
SOC 2 Tipo I
Objetivo para 2027No estamos auditados por SOC 2 hoy. La ventana esperada honesta para una atestación de Tipo I es la primera mitad de 2027; el Tipo II sigue después de un período de observación de 6 a 12 meses.
Auditorías de contratos inteligentes
Hereditado de upstreamHoy no operamos nuestros propios smart contracts. Las primitivas on-chain son Circle Programmable Wallets, Coinbase Smart Wallet y los contratos subyacentes de Base / USDC, todos los cuales cuentan con sus propios informes de auditoría independientes emitidos por los equipos correspondientes. Si en el futuro lanzamos nuestros propios contratos (funciones de account-abstraction), serán auditados antes del despliegue en mainnet.
Revisión de seguridad interna anual
En cursoRotación de secretos trimestral, revisión de escaneo de dependencias y auditoría de control de acceso. Lista de verificación de endurecimiento previa al lanzamiento documentada en nuestra [guía de asegurar tu billetera de agente](/learn/guides/secure-your-agent-wallet) para clientes; la versión interna la refleja.
No পরিচালamos un bug bounty remunerado.
Para ser completamente claros: Blockchain0x no tiene un programa de bug bounty y no paga dinero, criptoactivos, créditos, merchandising ni ninguna otra compensación por vulnerabilidades reportadas. No hay niveles de severidad, ni rangos de pago, ni negociación sobre esto - cualquiera que te diga lo contrario no nos está citando. Preferimos decirlo abiertamente antes que dejar que un investigador pase un fin de semana en nuestros sistemas esperando un cheque que no existe.
Lo que sí operamos es un proceso de divulgación coordinada sin compensación. Los informes se envían a nuestro correo de seguridad y los lee una persona. Confirmamos por correo electrónico la recepción de cada informe, y para los hallazgos que confirmamos como válidos ofrecemos un certificado de divulgación responsable y, si lo deseas, tu nombre o alias en nuestra lista pública de reconocimientos. Ese es el alcance total de lo que ofrecemos hoy. Si eso cambia, esta página cambiará con ello.
En alcance
- Autenticación y gestión de sesión en el dashboard o API.
- Escalada de privilegios entre workspaces o agentes de la misma cuenta.
- Server-side request forgery, inyección de comandos o ejecución remota de código en la API.
- Bypass de la firma del webhook o bypass de la validación del recibo.
- Bypass de la política de gasto que permite a un agente mover dinero fuera de sus límites configurados o allowlist.
- Exposición significativa de datos (transacciones de otros tenants, secretos, registros de auditoría).
Fuera de alcance
- Self-XSS o ataques que requieren que la víctima escriba o pegue entrada maliciosa en su propia consola.
- Informes que dependen de ingeniería social a personal o contratistas.
- Los reportes contra servicios de terceros con los que Blockchain0x se integra (Coinbase, Circle, etc) - deben dirigirse al programa propio del tercero.
- Hallazgos sobre endpoints de prueba (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia).
- Faltan encabezados de seguridad sin un impacto demostrado.
- Problemas teóricos sin una prueba de concepto funcional.
| Qué recibe un reportante | Detalles |
|---|---|
| Confirmación por correo electrónico | Cada informe recibe una respuesta humana de [email protected], tanto si el hallazgo resulta válido como si no, además del resultado del triaje cuando lo tengamos. |
| Certificado de divulgación responsable | Para hallazgos confirmados, reproducibles y dentro del alcance: un certificado firmado con tu nombre (o alias), la clase de problema y la fecha de divulgación. Se emite después de que la corrección se publique. |
| Reconocimiento público | Con tu permiso, tu nombre o alias se añadirá a la lista de reconocimientos publicada en esta página una vez que el problema esté corregido. Si prefieres, permanece anónimo - solo dínoslo. Sujeto a las condiciones de confidencialidad que aparecen abajo. |
| Recompensa monetaria | Ninguna. No pagamos por vulnerabilidades reportadas en ninguna severidad, y enviar un informe no genera derecho a pago alguno. |
Las decisiones sobre validez las toma el responsable de ingeniería en conversación con el fundador y son definitivas. El reconocimiento se otorga por hallazgos confirmados y reproducibles dentro del alcance; cuando el mismo problema se reporta más de una vez, se acredita al primer reportante. No requerimos un NDA para presentar un reporte, y las condiciones siguientes son las únicas restricciones.
Condiciones asociadas al reconocimiento
Tanto el certificado de divulgación responsable como el reconocimiento público dependen de que mantengas el reporte en confidencialidad. No publiques la vulnerabilidad, el reporte ni ninguno de sus detalles - pasos de reproducción, código de prueba de concepto, capturas de pantalla, endpoints afectados o nuestra correspondencia al respecto - en ningún medio. Eso incluye entradas de blog, informes, publicaciones de texto o imagen en cualquier red social o foro, video, audio, podcasts, charlas de conferencias, boletines, grupos de chat y derivados generados por IA de cualquiera de los anteriores. Si quieres publicar después de que la corrección se haya lanzado, consúltanos primero y normalmente acordaremos por escrito una fecha y un nivel de detalle. Publicar sin ese acuerdo por escrito invalida el certificado y el reconocimiento, y nos reservamos cualquier otro recurso disponible.
Por separado, y sin excepción: cualquier intento de extorsionarnos dinero o chantajearnos de cualquier forma - exigiendo un pago para retener, retrasar o eliminar un reporte, amenazando con publicar o vender un hallazgo si no pagamos, o presionándonos con un plazo respaldado por una amenaza - no es investigación de seguridad. No pagaremos. Tales intentos se tratarán estrictamente conforme a la legislación aplicable, incluido el reporte del asunto a las autoridades policiales y la cooperación plena con cualquier investigación o proceso resultante. Los investigadores de buena fe no tienen nada que temer aquí; este párrafo no va dirigido a ustedes.
Reconocimientos públicos
Los investigadores que reportaron una vulnerabilidad confirmada y pidieron ser acreditados se enumeran aquí, del más reciente al más antiguo, una vez que la corrección se haya publicado. Aún no hay nadie en la lista - si eres el primero, lo diremos aquí con tu nombre o alias y el mes del reporte. Una inclusión aquí está sujeta a las condiciones de confidencialidad establecidas arriba.
Cómo reportar un problema de seguridad.
Envía un correo a [email protected] con: una descripción del problema, una reproducción paso a paso, la URL o endpoint afectado, el impacto que observaste y el nombre o alias que quieres que aparezca en el certificado y en la lista de reconocimientos (un alias es suficiente; no se requiere nombre real, y puedes pedir permanecer en el anonimato). Los informes cifrados son bienvenidos - nuestra clave PGP está disponible previa solicitud.
Nos comprometemos a acusar recibo de tu reporte en un plazo de dos días hábiles, a clasificarlo en un plazo de cinco y a publicar una corrección o una decisión de aceptación del riesgo en un plazo de treinta días para hallazgos confirmados (o antes en caso de incidencias críticas). No amenazamos con acciones legales a la investigación de seguridad de buena fe que siga las normas de divulgación responsable - exponiendo datos solo en la medida necesaria para demostrar el problema, sin extraer datos de clientes, sin ejecutar pruebas disruptivas que afecten a usuarios en producción y sin publicar el hallazgo antes de haber acordado por escrito cuándo y cómo puede publicarse.
Para problemas que no son de seguridad (soporte general, facturación, asociaciones), utiliza /contact. El correo de seguridad se monitorea solo para informes de seguridad.
Lo que decimos si algo sale mal.
Los incidentes de producción que afectan los fondos de los clientes, los datos de los clientes o la disponibilidad de la API de pago reciben un análisis post-mortem público dentro de los treinta días posteriores a la resolución, independientemente de la gravedad. Los incidentes más pequeños (rendimiento degradado, interrupciones parciales en la región) se comunican a través de actualizaciones de estado a los clientes afectados, pero no necesariamente reciben un análisis post-mortem.
No culpamos a los clientes en los análisis post-mortem. No culpamos a proveedores externos si la causa raíz fue nuestra. Nombramos las causas raíz de manera clara, enumeramos lo que estamos cambiando como resultado y mantenemos el análisis post-mortem disponible indefinidamente. La expectativa que los clientes deben tener es que les diremos lo que sucedió antes de que tengan que preguntar.
Contacto de seguridad
Informes de vulnerabilidades: [email protected]. Clave PGP previa solicitud. Los informes se acusan de recibo, no se pagan.