Segurança

Visão geral

A segurança na Rede Carrot opera em dois níveis: segurança de smart contracts protegendo ativos on-chain, e segurança de governança protegendo a rede contra manipulação e ações hostis.

Segurança de smart contracts

Os smart contracts da Rede Carrot implementam múltiplas camadas de segurança:

Controle de Acesso Baseado em Funções (RBAC)

Funções privilegiadas são restritas por papel, e a separação de responsabilidades é validada na inicialização de cada contrato, de modo que os cinco papéis começam em cinco endereços distintos. Essa verificação roda apenas na inicialização: o DEFAULT_ADMIN_ROLE pode conceder qualquer papel depois, então mantê-los separados é disciplina de governança, não algo que o contrato reimponha. Pontos de entrada públicos como purchase e retire são abertos a qualquer chamador, mas só executam contra uma ordem assinada por um signatário autorizado do backend (veja EIP-712 abaixo). O sistema define cinco funções padrão:

• DEFAULT_ADMIN_ROLE — Propriedade do contrato e gestão de funções. Esta função pode conceder ou revogar qualquer outra função.
• UPGRADER_ROLE — Pode atualizar implementações de contratos via proxy UUPS. Separada da função admin para limitar o raio de impacto.
• OPERATOR_ROLE — Operações cotidianas como minting de MassIDs, emissão de certificados e execução de revogações.
• PAUSER_ROLE — Mecanismo de pausa padrão para interrupções operacionais ordenadas.
• EMERGENCY_PAUSER_ROLE — Disjuntor para falhas críticas. Uma pausa emergencial tem expiração de 48 horas, mas ela não se encerra sozinha: passada a expiração, qualquer conta — não apenas um detentor de papel — pode chamar checkAndUnpause() para encerrá-la. Uma conta emergencial comprometida pode pausar de novo assim que uma pausa é encerrada, então a contenção é revogar o EMERGENCY_PAUSER_ROLE, não esperar a janela passar.

A governança é distribuída entre esses papéis distintos, cada um hoje com detentores separados, de modo que a operação cotidiana exige mais de uma parte. Operações críticas — atualização de contrato e mudança de parâmetro crítico — exigem aprovação multipartes antes de serem executadas.

Pausabilidade

Os contratos podem ser pausados em modo padrão ou emergencial, interrompendo operações se uma vulnerabilidade ou ataque for detectado. Pausas padrão requerem o PAUSER_ROLE e persistem até serem explicitamente despausadas. Pausas emergenciais, acionadas pelo EMERGENCY_PAUSER_ROLE, expiram após 48 horas, de modo que um respondente de emergência agindo sozinho não consegue manter uma pausa aberta indefinidamente. Enquanto uma pausa emergencial está ativa, o PAUSER_ROLE pode estendê-la para uma pausa indefinida (extendPause), que é como um incidente real é mantido aberto além dessa janela.

Atualizabilidade UUPS

Os contratos utilizam o Universal Upgradeable Proxy Standard, permitindo correções de bugs e melhorias mantendo os mesmos endereços de contrato e estado. O ContractRegistry fornece descoberta centralizada de serviços para que as atualizações se propaguem de forma limpa pelo sistema.

Assinaturas de dados tipados EIP-712

Operações críticas como compras e aposentadorias de créditos requerem dados estruturados assinados criptograficamente antes de serem executadas on-chain. Isso significa que cada ordem deve ser assinada digitalmente por uma parte autorizada — o smart contract verifica essa assinatura antes do processamento, rejeitando qualquer transação que não tenha sido devidamente autorizada. Isso impede que partes não autorizadas executem operações e garante que ordens assinadas não possam ser reproduzidas (usadas mais de uma vez).

Especificamente:

• CreditPurchaseManager e CreditRetirementManager usam assinaturas de dados tipados EIP-712 para autorizar ordens de compra e aposentadoria.
• RewardsVault usa EIP-712 para autorização de retiradas, garantindo que as distribuições de recompensas sejam explicitamente aprovadas.

Custódia soulbound

Todos os NFTs (MassIDs, certificados, recibos) são soulbound e mantidos pelo smart contract Vault. Não podem ser transferidos, negociados ou roubados. Este design é intencional pelas seguintes razões:

• Integridade da proveniência — A cadeia desde a coleta de resíduos, passando pela certificação até a emissão de créditos, permanece permanente e verificável on-chain.
• Sem negociação especulativa — Os registros de auditoria ambiental devem refletir trabalho real de reciclagem, não especulação de mercado.
• Modelo de segurança simplificado — Eliminar transferências remove uma classe inteira de vetores de ataque relacionados a interações de marketplace, exploits de aprovação e movimentação não autorizada de tokens.

Proteção contra reentrância

Um ataque de reentrância ocorre quando um contrato malicioso interrompe uma operação no meio da execução — por exemplo, acionando uma retirada repetidamente antes que o saldo seja atualizado, drenando fundos que não deveriam mais estar disponíveis. Todas as operações que movimentam valor na Rede Carrot são protegidas contra esta classe de ataque usando o ReentrancyGuard da OpenZeppelin, que garante que cada operação seja concluída completamente antes que qualquer nova chamada possa começar.

Segurança de governança

A Carrot Foundation implementa mecanismos sistemáticos de recompensa e punição que escalam o custo do comportamento malicioso mais rápido do que qualquer receita que ele poderia gerar:

• Rastreamento de reputação de participantes (planejado) — Um mecanismo futuro para rastrear o comportamento dos participantes em toda a rede, identificando padrões que indicam maus atores, para que operações sensíveis possam ser restringidas por limites de reputação. Não está implementado hoje.
• Verificação de carteira — Etapas adicionais de verificação podem ser implementadas conforme necessário para aumentar a segurança, o que pode trocar facilidade de onboarding por proteções mais fortes.
• Moderação — A equipe de supervisão da Foundation pode sinalizar comportamentos que violam as diretrizes da comunidade e limitar o acesso para reduzir riscos. Moderadores também trabalham para detectar e penalizar tentativas de manipulação automatizada (anti-botting).
• Medidas punitivas — Quando violações são confirmadas, penalidades são emitidas por meio de decisões de governança. A Foundation pode revogar a associação de um participante à plataforma, removendo o acesso ao dashboard e à API; o papel de operador pode revogar um MassID ou certificado já emitido. Não existe congelamento por carteira nem blocklist em nenhum contrato — uma pausa interrompe toda movimentação de saldo do contrato de uma vez, nunca o saldo de um detentor isoladamente.

Filosofia de design

A estratégia de segurança segue um princípio: fazer com que o custo de atacar a rede sempre exceda a recompensa potencial. À medida que o ecossistema cresce e mais participantes constroem reputação genuína, a barreira para manipulação coordenada escala proporcionalmente — protegendo a integridade da rede conforme ela se torna mais valiosa.

Saiba mais sobre smart contracts · Saiba mais sobre governança