> ## 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.
# Bug bounty
> O programa de divulgação coordenada da Intention para investigadores de segurança — âmbito, classificação de gravidade, intervalos de recompensa, regras de participação e como submeter uma vulnerabilidade.
Esta página é a porta de entrada para investigadores de segurança. O programa de divulgação coordenada da Intention existe para encontrar e corrigir vulnerabilidades no protocolo antes que sejam usadas contra quem negoceia nele. Queremos que investigadores sérios olhem para todas as camadas do sistema, do kernel determinista que executa as ordens até aos contratos da ponte que detêm colateral, e estamos dispostos a pagar à altura quando encontrarem algo real.
O programa está a ser formalizado. O enquadramento, o âmbito, o modelo de gravidade e o processo de submissão descritos nesta página são a estrutura de trabalho que entrará em vigor com a primeira versão auditada de mainnet. Os montantes específicos das recompensas estão marcados como preliminares até o programa abrir oficialmente, mas a estrutura em si é estável, e **qualquer vulnerabilidade legítima divulgada de forma responsável durante o período pré-lançamento será honrada ao abrigo do enquadramento desta página**.
Os intervalos de recompensa abaixo são preliminares e serão substituídos por valores finais quando o programa for lançado, juntamente com a primeira versão auditada. O âmbito, o modelo de gravidade e as regras de submissão não são preliminares — são as regras a seguir hoje.
Âmbito
Dentro do âmbito
Tudo aquilo que um ator malicioso possa usar para roubar fundos de utilizadores, parar o protocolo, corromper estado definitivo ou quebrar as propriedades de que a arquitetura depende — [execução](/pt/protocol/architecture/kernel) reproduzível, [preços certificados no bloco que os consome](/pt/protocol/architecture/oracle), [risco a correr atomicamente com o matching](/pt/protocol/architecture/clearinghouse) ou [alterações de estado rastreáveis até à transação que as causou](/pt/protocol/architecture/state/model) — está no âmbito por omissão. Concretamente:
* **[IntentionKernel](/pt/protocol/architecture/kernel)** — semântica de execução, o conjunto de instruções fechado, a disciplina de sequenciação, o determinismo ao byte. Tudo o que permita que a execução de um validador divirja da de outro, ou que uma transação produza um efeito ausente da especificação do protocolo.
* **[IntentionBFT](/pt/protocol/architecture/intention-bft)** — segurança e vivacidade do consenso, eleição do líder, os compromissos de sequenciação canónica, a agregação de assinaturas e o caminho de migração pós-quântica.
* **[Oráculo e quórum de preços](/pt/protocol/architecture/oracle)** — submissão de observações, rejeição de valores atípicos baseada em MAD, o envelope de preço certificado, e qualquer caminho que permita a uma transação ler um preço que não foi confirmado no mesmo evento de consenso.
* **[Ponte entre cadeias](/pt/protocol/architecture/bridge)** — o fluxo de depósito e levantamento atestado por validadores, os contratos on-chain da ponte nas cadeias de destino suportadas, o processo de assinatura por limiar e de gestão de chaves, e os controlos operacionais em torno deles.
* **Motor de negociação** — matching, cálculo do preço de marcação, cascatas de liquidação forçada, o fundo de seguro, o ADL, a cobrança do funding e o pipeline de risco nativo do protocolo.
* **Superfícies públicas de API** — endpoints REST e WebSocket, autenticação, assinatura, rate limits e qualquer caminho de código alcançável a partir da Internet.
* **Software de validador** — o binário do nó, o tratamento de chaves, o transporte peer-to-peer e qualquer ferramenta operacional que um validador corra em produção.
Fora do âmbito
As categorias seguintes estão explicitamente excluídas do programa. Os relatos sobre estes alvos serão confirmados, mas não são elegíveis para recompensa.
* Ataques volumétricos de negação de serviço contra a infraestrutura de validadores ou contra endpoints RPC públicos. A defesa contra estes está na mitigação operacional na fronteira da rede, não em correções ao protocolo.
* Problemas em software, dependências ou serviços de terceiros que a Intention não controla.
* Vulnerabilidades que dependam de acesso físico ao hardware dos validadores, de engenharia social contra colaboradores da Intention Labs, ou de ataques à cadeia de fornecimento das ferramentas que a equipa usa internamente.
* Self-XSS, falsificação de conteúdo sem impacto de segurança, cabeçalhos de segurança em falta e outros problemas de baixo impacto contra o site de marketing ou este site de documentação.
* Bugs em software que tenha sido formalmente descontinuado e já não corra em nenhum validador nem em nenhum serviço de produção.
* Ataques teóricos que exijam precondições improváveis (por exemplo, o comprometimento de 51% do stake honesto) sem um caminho concreto para as desencadear.
Classificação de gravidade
As vulnerabilidades são graduadas numa escala de quatro níveis. O nível é determinado pela combinação de **impacto** (o que um atacante consegue alcançar) e **probabilidade** (o grau de realismo do cenário de ataque, incluindo as precondições e os recursos necessários). O valor em risco é o fator de impacto dominante em qualquer vulnerabilidade que toque em fundos de utilizadores.
| Nível | O que significa | Exemplos representativos |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Crítica** | Roubo direto, perda permanente ou emissão não autorizada de fundos de utilizadores; violação da segurança do consenso; falsificação do oráculo que possa ser persistida. | Um caminho através do kernel que permita a uma transação creditar uma conta que não pagou. Uma falha na agregação de assinaturas que permita a `$f$` validadores confirmar um bloco. Um levantamento da ponte que emita tokens no destino sem um bloqueio correspondente. |
| **Alta** | Perda limitada a um subconjunto de utilizadores ou a um mercado específico; paragem da vivacidade do consenso; ataques de griefing sobre a ponte; liquidação forçada dirigida. | Um caminho do motor de liquidação que possa ser ativado contra uma posição específica sem uma verdadeira quebra de margem. Uma máquina de estados da ponte que possa ser encravada de modo a que os levantamentos deixem de ser processados para uma cadeia. Escalada de privilégios contra o software de validador, aquém do comprometimento do consenso. |
| **Média** | Sem perda direta de fundos, mas com uma quebra significativa das garantias do protocolo ou da integridade operacional. | Leitura não autorizada de estado que deveria ser privado. Um contorno do rate limit que aumente materialmente o custo de operar a cadeia. Uma forma de fazer o [fluxo de execução](/pt/help/glossary) emitir eventos inconsistentes com o estado definitivo. |
| **Baixa** | Problemas de impacto limitado, sem caminho para perda de fundos ou perturbação do consenso. | Divulgação de informação sem impacto. Respostas de erro inconsistentes na API pública. Pequenos problemas operacionais sem caminho de exploração. |
A gravidade é decidida pela equipa de segurança da Intention em consulta com quem reporta. A equipa fundamenta o nível atribuído por escrito em cada vulnerabilidade, e quem reporta pode contestá-lo com novas provas.
Intervalos de recompensa
Todas as recompensas são pagas em **USDC** para um endereço de carteira indicado por quem reporta. Não há qualquer token nativo envolvido.
| Nível | Intervalo de recompensa preliminar |
| ------- | ------------------------------------ |
| Crítica | `TBD — high five to six figures` |
| Alta | `TBD — mid four to low five figures` |
| Média | `TBD — low four figures` |
| Baixa | `TBD — symbolic / swag` |
Os intervalos são provisórios até o programa abrir. A matriz final será publicada nesta página quando a primeira versão auditada for entregue.
Algumas regras aplicam-se a todos os pagamentos:
* **Uma recompensa por vulnerabilidade única.** Se a mesma causa raiz produzir várias vulnerabilidades, a equipa consolida-as numa única atribuição, com a gravidade mais alta aplicável.
* **Ganha quem reportar primeiro.** Relatos duplicados de um problema já em triagem são confirmados, mas não recompensados.
* **Sem recompensa para problemas conhecidos.** As vulnerabilidades que correspondam a itens já no backlog interno da equipa de segurança, ou já cobertos por uma auditoria publicada, não são elegíveis. A equipa partilhará a referência relevante quando isso acontecer.
* **A recompensa depende de cooperação.** A divulgação pública antes da correção, a exploração para além de uma prova de conceito mínima ou qualquer dano causado a utilizadores anulam a recompensa.
Regras de participação
Os investigadores que participam no programa aceitam as restrições seguintes. Existem para proteger os utilizadores, para proteger os outros investigadores e para manter o programa como algo que a Intention consiga continuar a operar.
* **Não testar em produção com fundos reais de utilizadores.** Use a testnet pública (quando estiver ativa) ou um fork privado. Se uma vulnerabilidade só puder ser reproduzida em produção, contacte primeiro `contact@intention.xyz` e não execute a prova de conceito até a equipa de segurança ter confirmado o pedido.
* **Não recorrer a engenharia social.** Não vise colaboradores, prestadores de serviços, validadores ou parceiros da Intention Labs com phishing, pretexting ou outros ataques sociais.
* **Não realizar ataques volumétricos.** Sem negação de serviço por inundação de tráfego, sem ataques de exaustão de recursos contra infraestrutura partilhada.
* **Apenas prova de conceito mínima.** Demonstre o impacto com a menor ação possível. Não exfiltre dados de utilizadores, não movimente fundos para além do montante necessário para provar o problema e não permaneça no sistema depois de a prova de conceito estar concluída.
* **Não divulgar publicamente antes da correção.** A divulgação coordenada é a regra por omissão. A equipa de segurança acordará consigo um calendário de divulgação pública assim que a correção estiver implantada.
* **Cumprir a lei aplicável.** A cláusula de porto seguro (safe harbor) abaixo aplica-se à investigação de boa-fé conduzida ao abrigo destas regras. As atividades que violem leis sobre uso indevido de sistemas informáticos em qualquer jurisdição relevante não estão protegidas.
Como submeter
Um relatório completo inclui: uma descrição escrita e clara da vulnerabilidade, o componente e a versão afetados, a reprodução passo a passo, uma prova de conceito mínima (código ou hashes de transação), o impacto que atribui ao problema e qualquer correção sugerida. Quanto mais claro for o relatório, mais rápida é a triagem.
Envie o relatório por e-mail para `contact@intention.xyz` com **Security** na linha de assunto. Uma chave PGP para submissões cifradas será publicada com o lançamento do programa — até lá, envie a mensagem inicial em texto simples; a equipa passará os detalhes sensíveis para um canal cifrado logo na primeira troca. Não publique qualquer parte da vulnerabilidade antes de a equipa a ter confirmado.
A equipa de segurança confirma todas as submissões no prazo de dois dias úteis. A confirmação acusa a receção, pede a informação em falta e atribui um responsável pela triagem. Se não tiver recebido confirmação ao fim de 72 horas, reenvie.
As vulnerabilidades validadas passam para correção. A equipa de segurança trabalha com os responsáveis de engenharia para entregar uma correção e vai partilhando o progresso com quem reportou. A equipa pode pedir esclarecimentos ou passos de reprodução adicionais; as respostas chegam normalmente no prazo de um dia útil.
Assim que a correção estiver implantada e o problema deixar de ser explorável, a recompensa é paga em USDC para o endereço indicado por quem reportou. Quem reportou é creditado no post-mortem e em qualquer divulgação subsequente, com o seu consentimento. Os post-mortems completos são publicados quando isso não expõe os utilizadores a risco residual.
Porto seguro
A investigação de segurança de boa-fé conduzida dentro das regras acima não será alvo de ação judicial por parte da Intention Labs. O compromisso de porto seguro cobre os investigadores que:
* Se mantenham dentro do âmbito e das regras de participação desta página
* Não acedam, alterem nem destruam dados de utilizadores para além do estritamente necessário para demonstrar o impacto
* Reportem as vulnerabilidades em privado e cumpram o calendário de divulgação coordenada
* Não explorem as vulnerabilidades para benefício próprio nem para qualquer fim que ultrapasse o programa
As atividades que caiam fora destas regras — por exemplo, exfiltrar saldos de utilizadores, exigir resgate por uma vulnerabilidade ou torná-la pública antes da correção — não estão cobertas pelo porto seguro e podem dar origem a ação judicial, independentemente da validade da vulnerabilidade em causa. O texto jurídico específico acompanhará o lançamento formal do programa, e esta página passará a remeter para ele.
O programa ainda não está formalmente aberto. Reporte mesmo assim tudo o que encontrar. Qualquer vulnerabilidade legítima divulgada de forma responsável durante o período pré-lançamento será honrada ao abrigo do enquadramento desta página, e quem a reportar será pago segundo a mesma matriz quando o programa entrar em vigor.
**E-mail:** `contact@intention.xyz`. Coloque **Security** na linha de assunto para reportar uma vulnerabilidade; tudo o resto — questões de apoio, imprensa, parcerias ou perguntas sobre o programa que não sejam divulgações — segue para o mesmo endereço sem esse assunto.
Obrigado pelo tempo dedicado a olhar para isto. O protocolo fica melhor com cada investigador honesto que o lê.