> For the complete documentation index, see [llms.txt](https://novacont.gitbook.io/nova-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novacont.gitbook.io/nova-docs/novacont-docs/portugues/seguranca-e-desenvolvedores/modelo-de-seguranca.md). # Modelo de segurança ### Arquitetura de pagamento pull O NovaCont não envia fundos forçosamente para os destinatários. Em vez disso, todas as distribuições de fundos são registradas como créditos em um mapeamento `pendingWithdrawals`, e os destinatários iniciam suas próprias retiradas explicitamente. Esta é uma escolha de segurança deliberada. Os sistemas de pagamento baseados em push — onde o contrato envia ETH diretamente para os endereços dos destinatários — são vulneráveis a ataques de reentrada se o destinatário for um contrato malicioso que reentra na função de envio antes que o estado seja atualizado. Ao separar a etapa de crédito da etapa de retirada, o NovaCont elimina completamente essa superfície de ataque. Cada função de retirada é adicionalmente protegida pelo modificador `nonReentrant` como camada secundária de defesa.
### Proteção contra reentrada Todas as funções que interagem com saldos de ETH ou ERC-20 são marcadas com o modificador `nonReentrant` do ReentrancyGuard da OpenZeppelin. Este modificador usa uma variável de bloqueio para garantir que nenhuma função no contrato possa ser chamada recursivamente — se uma chamada reentrante for tentada, a transação é revertida imediatamente. As transferências de ERC-20 usam o wrapper `SafeERC20` da OpenZeppelin, que lida graciosamente com implementações de tokens não padrão e reverte em transferências com falha em vez de ter sucesso silenciosamente com um valor de retorno falso. ### Controle de acesso **Proprietário** — O endereço de implantação. Pode pausar o contrato, atualizar taxas, registrar tokens, definir feeds de preços e gerenciar a configuração do resolvedor e do sistema de júri. As transferências de propriedade requerem duas etapas para evitar transferências acidentais. **Resolvedor** — Um endereço designado autorizado a resolver disputas no modo administrador. Por padrão é o proprietário na implantação. Pode ser alterado pelo proprietário a qualquer momento. Quando o sistema de júri é ativado, o resolvedor é automaticamente definido para o endereço do contrato NovaJury. **onlyJuryContract** — Um modificador que restringe certas funções de liquidação exclusivamente ao endereço registrado do NovaJury. Não pode ser chamado pelo proprietário, resolvedor ou qualquer ator externo. **Acesso baseado em partes** — A maioria das funções do fluxo de trabalho é restrita aos endereços específicos registrados como cliente ou fornecedor na criação do contrato. Nenhum outro endereço pode aceitar, entregar, aprovar, disputar ou cancelar em nome de uma parte. #### Pausa de emergência O proprietário do contrato pode invocar `pause()` a qualquer momento para interromper todas as operações que modificam o estado. Isso é destinado como medida de emergência no caso de uma vulnerabilidade descoberta ou um ataque em andamento. Quando pausado: * Nenhum novo contrato pode ser criado * Nenhuma transição de estado pode ser acionada * As retiradas de `pendingWithdrawals` permanecem totalmente funcionais — os usuários sempre podem recuperar os fundos creditados O contrato pode ser despausado pelo proprietário a qualquer momento via `unpause()`. ### Limitações e suposições conhecidas **Seleção pseudoaleatória de jurados:** A atribuição de jurados usa um mecanismo pseudoaleatório on-chain baseado em `blockhash`, `prevrandao`, `gasleft` e um nonce incremental. Isso não é aleatoriedade criptograficamente segura. Um validador com controle suficiente sobre a produção de blocos poderia teoricamente influenciar os resultados de seleção de jurados. Para a escala atual do protocolo, esse risco é considerado aceitável, mas é reconhecido como uma limitação. A integração com uma solução de aleatoriedade verificável como Chainlink VRF é uma possível atualização futura. **Dependência de oráculo:** O NovaCont depende dos feeds de preços da Chainlink para cálculos de depósito. O contrato realiza múltiplas validações em cada chamada ao oráculo: verifica que o preço é maior que zero, que os dados de rodada estão completos e que o preço não tem mais de 24 horas. Uma interrupção prolongada do oráculo ou um feed comprometido ainda poderia afetar a precisão das conversões de USD para tokens, mas essas múltiplas verificações reduzem significativamente o risco. **Sem mecanismo de apelação:** Os veredictos de disputas — seja emitidos pelo administrador ou pelo júri — são definitivos e irreversíveis uma vez executados on-chain. Não há processo de apelação. Os usuários devem abordar as disputas com evidências completas e bem organizadas desde o início. **Evidência fora da cadeia:** Os URIs de evidência apontam para recursos fora da cadeia. O NovaCont não pode garantir a permanência ou integridade desses recursos. Um fornecedor ou cliente que envie um link que posteriormente se torne inacessível arcará com as consequências dessa inacessibilidade em qualquer avaliação de disputa. ### Análise de superfície de ataque Entender onde um contrato inteligente é mais vulnerável é tão importante quanto entender o que ele faz. A seguir está uma avaliação honesta das principais superfícies de ataque do NovaCont e as mitigações em vigor para cada uma. #### **cancelContract — Caminho de acesso do proprietário e lógica pós-entrega** A função `cancelContract` tem dois comportamentos importantes: **Autoridade de cancelamento do proprietário.** O proprietário do contrato pode cancelar qualquer acordo a qualquer momento, independentemente do estado ou do consentimento das partes: ``` require(canCancel || msg.sender == owner(), "Cannot cancel"); ``` Esta é uma capacidade administrativa intencional — existe para lidar com casos extremos como endereços sancionados, obrigações legais ou bugs críticos que requerem intervenção manual. No entanto, representa uma suposição de centralização da qual os usuários devem estar cientes. Os cancelamentos iniciados pelo proprietário sempre resultam em um reembolso completo ao cliente sem aplicar nenhuma penalidade. #### **settleDispute — Validação de divisão** A função de liquidação do administrador aplica um invariante estrito: ``` require(_clientRefund + _grossProviderPayment == c.totalLocked) ``` Isso garante que o valor total distribuído sempre seja igual ao valor total bloqueado — nenhum fundo pode ser criado ou destruído durante a liquidação. Qualquer resolução que não contabilize cada wei do saldo bloqueado será revertida. Esta é uma verificação de correção crítica que previne tanto a alocação incorreta acidental quanto maliciosa de fundos durante a resolução de disputas. #### **claimTimeout — Dependência de tempo** O mecanismo de tempo limite depende de `block.timestamp` para sua verificação de janela de 7 dias. Mineradores e validadores têm um pequeno grau de influência sobre os timestamps dos blocos — tipicamente dentro de um intervalo de alguns segundos a alguns minutos. Isso não é um vetor de ataque significativo para uma janela de 7 dias, mas vale a pena notar como uma propriedade geral da lógica dependente de timestamp. O NovaCont não usa timestamps para nada onde a precisão no nível de segundos seja crítica para a segurança. ### Considerações de front-running O front-running ocorre quando um ator malicioso observa uma transação pendente no mempool e envia sua própria transação com uma taxa de gas mais alta para ser processada primeiro. **Front-running do preço do oráculo:** Quando um cliente chama `createContract`, o preço ETH/USD é obtido da Chainlink naquele bloco exato. Um ator sofisticado poderia teoricamente observar uma transação `createContract` pendente, prever o preço do oráculo no momento da inclusão e elaborar um ataque em torno disso. No entanto, não há exploit significativo disponível aqui — o cliente é quem bloqueia seus próprios fundos, e o preço do oráculo afeta apenas quanto ETH ele deve enviar, não se os fundos podem ser roubados. **Front-running de disputa:** Um fornecedor que vê a transação `disputeWork` do cliente no mempool não pode fazer front-running dela de uma forma que o beneficie — o estado do contrato permite apenas que uma disputa seja aberta, e a disputa só pode ser aberta enquanto está no estado "Entregue". Não há condição de corrida que poderia permitir que um fornecedor impedisse uma disputa legítima. ### Casos extremos de ERC-20 **Condição de corrida na aprovação:** A função padrão ERC-20 `approve` é tecnicamente vulnerável a uma condição de corrida onde um gastador pode observar uma aprovação sendo alterada e fazer front-running para gastar tanto o limite antigo quanto o novo. O NovaCont mitiga isso usando `safeTransferFrom` via `SafeERC20`, e os usuários são aconselhados a definir os limites para zero antes de aumentá-los se estiverem interagindo com os contratos diretamente em vez de através da interface do aplicativo. **Valores de retorno não padrão:** Alguns tokens ERC-20 não retornam um valor booleano de `transfer` e `transferFrom`, contrariamente à especificação EIP-20. O wrapper `SafeERC20` da OpenZeppelin lida com isso graciosamente verificando o comprimento dos dados de retorno e tratando valores de retorno ausentes como sucesso apenas quando a própria chamada não foi revertida. Isso garante compatibilidade com uma gama mais ampla de implementações de tokens. ### Riscos de centralização O NovaCont não é totalmente sem confiança em sua forma atual. As seguintes capacidades do proprietário representam suposições de centralização que os usuários devem avaliar antes de usar o protocolo: | Capacidade | Função | Impacto | | -------------------------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Pausar todas as operações | `pause()` | Interrompe a criação de contratos e transições de estado. As retiradas não são afetadas. | | Cancelar qualquer contrato | `cancelContract()` | O proprietário pode cancelar forçosamente qualquer acordo. O cliente sempre recebe um reembolso completo. | | Alterar a taxa de plataforma | `setPlatformFee()` | A taxa pode ser alterada até um máximo de 10%. Afeta apenas liquidações futuras. | | Alterar o resolvedor | `setResolver()` | Pode redirecionar a autoridade de resolução de disputas para qualquer endereço. | | Ativar ou desativar o júri | `activateJurySystem()` / `deactivateJurySystem()` | Pode alternar entre modos de disputa administrado e descentralizado a qualquer momento. | | Adicionar ou remover tokens suportados | `addSupportedToken()` / `removeSupportedToken()` | Pode expandir ou restringir as opções de pagamento. Não é possível remover ETH ou USDT. | | Atualizar feeds de preços | `setPriceFeed()` | Pode alterar a fonte do oráculo para qualquer token. Um feed malicioso poderia afetar os cálculos de depósito. | Essas capacidades são necessárias para que o protocolo opere com segurança durante seu estágio atual de desenvolvimento. À medida que o protocolo amadurece, a intenção é reduzir progressivamente a autoridade do proprietário através de timelocks, requisitos de multisig e eventualmente governança on-chain. Qualquer mudança no modelo de privilégios do proprietário será documentada e anunciada com antecedência. ### Status de auditoria O NovaCont ainda não passou por uma auditoria de segurança formal de terceiros. Os contratos foram desenvolvidos seguindo as melhores práticas de segurança estabelecidas e fazem uso extensivo de bibliotecas auditadas da OpenZeppelin, mas a ausência de uma auditoria formal significa que vulnerabilidades desconhecidas podem existir. Os usuários devem tratar o protocolo como experimental até que uma auditoria formal seja concluída e suas descobertas publicadas. Não deposite fundos que você não pode se dar ao luxo de perder. Um compromisso de auditoria está planejado como parte do caminho do protocolo para a implantação na rede principal. Os relatórios de auditoria serão publicados na íntegra e vinculados a partir desta documentação quando disponíveis.