> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Recompensas por errores > El programa de divulgación coordinada de Intention para investigadores de seguridad: alcance, clasificación de severidad, rangos de recompensa, reglas de participación y cómo enviar un hallazgo. Esta página es la puerta de entrada para los investigadores de seguridad. El programa de divulgación coordinada de Intention existe para encontrar y remediar vulnerabilidades en el protocolo antes de que se usen contra quienes operan en él. Queremos que investigadores serios miren todas las capas del sistema, desde el kernel determinista que ejecuta las órdenes hasta los contratos del puente que custodian el colateral, y estamos dispuestos a pagar en consecuencia cuando encuentren algo real. El programa se está formalizando. El marco, el alcance, el modelo de severidad y el proceso de envío que describe esta página son la estructura de trabajo que entrará en vigor con la primera versión auditada de mainnet. Los importes concretos de recompensa están marcados como preliminares hasta que el programa abra oficialmente, pero la estructura en sí es estable, y **todo hallazgo legítimo divulgado de forma responsable durante el periodo previo al lanzamiento se honrará bajo el marco de esta página**. Los rangos de recompensa de abajo son preliminares y se sustituirán por valores finales cuando el programa se lance junto con la primera versión auditada. El alcance, el modelo de severidad y las reglas de envío no son preliminares: esas son las reglas que hay que seguir hoy.

Alcance

Dentro del alcance

Cualquier cosa que un actor malicioso pudiera usar para robar fondos de usuarios, detener el protocolo, corromper estado ya firme o romper las propiedades de las que depende la arquitectura está dentro del alcance por defecto. Esas propiedades son la [ejecución](/es/protocol/architecture/kernel) reproducible, los [precios certificados en el bloque que los consume](/es/protocol/architecture/oracle), el [riesgo que se ejecuta atómicamente con la casación](/es/protocol/architecture/clearinghouse) y los [cambios de estado rastreables hasta la transacción que los causó](/es/protocol/architecture/state/model). En concreto: * **[IntentionKernel](/es/protocol/architecture/kernel)**: la semántica de ejecución, el conjunto de instrucciones de mundo cerrado, la disciplina de secuenciación, el determinismo byte a byte. Cualquier cosa que permita que la ejecución de un validador diverja de la de otro, o que una transacción produzca un efecto que no esté en la especificación del protocolo. * **[IntentionBFT](/es/protocol/architecture/intention-bft)**: la seguridad y la vivacidad del consenso, la elección de líder, los compromisos de secuenciación canónica, la agregación de firmas y la ruta de migración poscuántica. * **[Oráculo y quórum de precios](/es/protocol/architecture/oracle)**: el envío de observaciones, el rechazo de valores atípicos basado en MAD, la envolvente de precio certificado y cualquier vía que permita a una transacción leer un precio que no se haya confirmado en el mismo evento de consenso. * **[Puente entre cadenas](/es/protocol/architecture/bridge)**: el flujo de depósito y retiro atestado por los validadores, los contratos on-chain del puente en las cadenas de destino admitidas, el proceso de firma de umbral y de gestión de claves, y los controles operativos a su alrededor. * **Motor de trading**: la casación, el cálculo del precio de marca, las cascadas de liquidación, el fondo de seguro, el ADL, el cobro de la financiación y la cadena de riesgo nativa del protocolo. * **Superficies públicas de API**: los endpoints REST y WebSocket, la autenticación, la firma, el límite de solicitudes y cualquier ruta de código alcanzable desde internet. * **Software de validador**: el binario del nodo, el manejo de claves, el transporte peer-to-peer y cualquier herramienta operativa que un validador ejecute en producción.

Fuera del alcance

Las siguientes categorías quedan excluidas de forma explícita del programa de recompensas. Se acusará recibo de los informes contra estos objetivos, pero no son elegibles para recompensa. * Ataques volumétricos de denegación de servicio contra la infraestructura de los validadores o contra los endpoints RPC públicos. La defensa contra ellos vive en la mitigación operativa en el borde de la red, no en parches del protocolo. * Problemas en software, dependencias o servicios de terceros que Intention no controla. * Hallazgos que dependan del acceso físico al hardware de un validador, de ingeniería social contra empleados de Intention Labs o de ataques a la cadena de suministro de herramientas que el equipo usa internamente. * Self-XSS, suplantación de contenido sin impacto de seguridad, cabeceras de seguridad ausentes y otros problemas de bajo impacto contra el sitio de marketing o contra este sitio de documentación. * Errores en software que se ha retirado formalmente y que ya no se ejecuta en ningún validador ni en ningún servicio de producción. * Ataques teóricos que exigen precondiciones improbables (por ejemplo, comprometer el 51% del stake honesto) sin una vía concreta para provocar esas precondiciones.

Clasificación de severidad

Los hallazgos se gradúan en una escala de cuatro niveles. El grado lo determina la combinación de **impacto** (qué puede conseguir un atacante) y **probabilidad** (cuán realista es el escenario de ataque, incluidas las precondiciones y los recursos necesarios). El activo en riesgo es el factor de impacto dominante en cualquier hallazgo que toque fondos de usuarios. | Nivel | Qué significa | Ejemplos representativos | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Crítica** | Robo directo, pérdida permanente o emisión no autorizada de fondos de usuarios; violación de la seguridad del consenso; falsificación del oráculo que se pueda persistir. | Una vía a través del kernel que permita a una transacción abonar una cuenta que no pagó. Un fallo en la agregación de firmas que permita a `$f$` validadores confirmar un bloque. Un retiro del puente que emita tokens en destino sin un bloqueo correspondiente. | | **Alta** | Pérdida limitada a un subconjunto de usuarios o a un mercado concreto; parada de la vivacidad del consenso; ataques de griefing sobre el puente; liquidación forzada dirigida. | Una vía del motor de liquidación que se pueda activar contra una posición concreta sin un incumplimiento real de margen. Una máquina de estados del puente que se pueda atascar de modo que dejen de procesarse los retiros de una cadena. Escalada de privilegios contra el software de validador sin llegar a comprometer el consenso. | | **Media** | Sin pérdida directa de fondos, pero con una vulneración relevante de las garantías del protocolo o de la integridad operativa. | Lectura no autorizada de estado que debería ser privado. Un salto del límite de solicitudes que eleve de forma material el coste de operar la cadena. Una forma de hacer que el [flujo de ejecución](/es/help/glossary) emita eventos incoherentes con el estado ya firme. | | **Baja** | Problemas de impacto limitado, sin vía hacia la pérdida de fondos ni hacia la interrupción del consenso. | Divulgación de información sin impacto. Respuestas de error incoherentes en la API pública. Problemas operativos menores sin vía de explotación. | La severidad la decide el equipo de seguridad de Intention en consulta con quien reporta. El equipo explicará su calificación por escrito en cada hallazgo, y quien reporta puede discutirla aportando nuevas pruebas.

Rangos de recompensa

Todas las recompensas se pagan en **USDC** a una dirección de billetera que designe quien reporta. No hay ningún token nativo de por medio. | Nivel | Rango de recompensa preliminar | | ------- | ------------------------------------ | | Crítica | `TBD — high five to six figures` | | Alta | `TBD — mid four to low five figures` | | Media | `TBD — low four figures` | | Baja | `TBD — symbolic / swag` | Los rangos son marcadores de posición hasta que el programa abra. La matriz final se publicará en esta página cuando se entregue la primera versión auditada. Unas pocas reglas se aplican a todo pago: * **Una recompensa por vulnerabilidad única.** Si la misma causa raíz produce varios hallazgos, el equipo los consolida en un único premio con la severidad más alta aplicable. * **Gana quien reporta primero.** Los informes duplicados de un problema que ya está en triaje reciben acuse de recibo, pero no recompensa. * **Sin recompensa por problemas conocidos.** Los hallazgos que coincidan con elementos que ya están en el backlog interno del equipo de seguridad o que ya cubre una auditoría publicada no son elegibles. El equipo compartirá la referencia correspondiente cuando ocurra. * **La recompensa depende de la cooperación.** La divulgación pública antes de la remediación, la explotación más allá de una prueba de concepto mínima o cualquier daño a los usuarios anulan la recompensa.

Reglas de participación

Quienes participan en el programa aceptan las siguientes restricciones. Existen para proteger a los usuarios, para proteger a otros investigadores y para que el programa siga siendo algo que Intention pueda mantener en marcha. * **Nada de pruebas contra producción con fondos reales de usuarios.** Usa la testnet pública (cuando esté activa) o un fork privado. Si un hallazgo solo se puede reproducir en producción, escribe primero a `contact@intention.xyz` y no ejecutes la prueba de concepto hasta que el equipo de seguridad haya acusado recibo de la petición. * **Nada de ingeniería social.** No apuntes a empleados, contratistas, validadores ni socios de Intention Labs con phishing (suplantación de identidad), pretexting u otros ataques sociales. * **Nada de ataques volumétricos.** Nada de denegación de servicio por inundación de tráfico, nada de ataques de agotamiento de recursos contra infraestructura compartida. * **Solo pruebas de concepto mínimas.** Demuestra el impacto con la acción más pequeña posible. No exfiltres datos de usuarios, no muevas más fondos de los necesarios para demostrar el problema y no te mantengas en el sistema una vez completada la prueba de concepto. * **Nada de divulgación pública antes de la remediación.** La divulgación coordinada es lo predeterminado. El equipo de seguridad acordará contigo un calendario de divulgación pública una vez desplegada la corrección. * **Cumple la ley aplicable.** El texto de puerto seguro de abajo se aplica a la investigación de buena fe realizada bajo estas reglas. Las actividades que violen las leyes sobre uso indebido de sistemas informáticos en cualquier jurisdicción relevante no están protegidas.

Cómo enviar un informe

Un informe completo incluye: una descripción escrita y clara de la vulnerabilidad, el componente y la versión afectados, la reproducción paso a paso, una prueba de concepto mínima (código o hashes de transacción), el impacto que crees que tiene el problema y cualquier remediación sugerida. Cuanto más claro sea el informe, más rápido irá el triaje. Envía el informe por correo a `contact@intention.xyz` con **Security** en el asunto. Se publicará una clave PGP para envíos cifrados junto con el lanzamiento del programa: hasta entonces, manda el primer correo en texto plano y el equipo llevará los detalles sensibles a un canal cifrado en el primer intercambio. No publiques ninguna parte del hallazgo antes de que el equipo haya acusado recibo. El equipo de seguridad acusa recibo de cada envío en dos días hábiles. El acuse confirma la recepción, pide la información que falte y asigna un responsable de triaje. Si no has recibido acuse de recibo pasadas 72 horas, vuelve a enviarlo. Los hallazgos validados pasan a remediación. El equipo de seguridad trabaja con los responsables de ingeniería correspondientes para entregar una corrección, y comparte el avance con quien reporta a una cadencia regular. El equipo puede pedir aclaraciones o pasos de reproducción adicionales; las respuestas suelen llegar en un día hábil. Una vez desplegada la corrección y cuando el problema ya no sea explotable, la recompensa se paga en USDC a la dirección que haya facilitado quien reporta. Se le acredita en el post-mortem y en cualquier divulgación posterior, con su consentimiento. Los post-mortem completos se publican cuando hacerlo no expone a los usuarios a un riesgo residual.

Puerto seguro

Intention Labs no emprenderá acciones legales contra la investigación de seguridad de buena fe realizada dentro de las reglas anteriores. El compromiso de puerto seguro cubre a quienes investigan y: * Se mantienen dentro del alcance y de las reglas de participación de esta página * No acceden, modifican ni destruyen datos de usuarios más allá de lo estrictamente necesario para demostrar el impacto * Reportan los hallazgos en privado y siguen el calendario de divulgación coordinada * No explotan los hallazgos en beneficio propio ni para ningún fin ajeno al programa de recompensas Las actividades que quedan fuera de estas reglas (por ejemplo, exfiltrar saldos de usuarios, retener un hallazgo pidiendo un rescate o hacerlo público antes de la remediación) no están cubiertas por el puerto seguro y pueden dar lugar a acciones legales con independencia de la validez del hallazgo. El texto legal concreto acompañará al lanzamiento formal del programa y se enlazará desde esta página. El programa de recompensas todavía no está abierto formalmente. Aun así, reporta cualquier cosa que encuentres. Todo hallazgo legítimo divulgado de forma responsable durante el periodo previo al lanzamiento se honrará bajo el marco de esta página, y quien lo reporte cobrará con la misma matriz cuando el programa entre en funcionamiento.

Contacto

**Correo:** `contact@intention.xyz`. Pon **Security** en el asunto si se trata de un informe de vulnerabilidad; cualquier otra cosa (dudas de soporte, prensa, alianzas o preguntas sobre el programa que no sean divulgaciones) va a la misma dirección sin eso. Gracias por dedicar tiempo a mirarlo. El protocolo es mejor gracias a cada investigador honesto que lo lee.