Segurança na LiquitX

Esta página descreve o trabalho de segurança por trás do protocolo LiquitX como ele está hoje: a disciplina de engenharia, o arco de auditorias internas e o que ainda está à frente. Tudo aqui é trabalho interno. Nenhuma auditoria externa foi concluída ainda, e dizemos isso com clareza.

Disciplina de Desenvolvimento

Todo contrato começa como uma especificação. Comportamentos esperados, comportamentos indesejados, casos extremos e vetores de ataque são registrados primeiro, e os testes que codificam essa especificação são escritos antes da implementação que eles restringem.

A suíte de testes do protocolo é organizada em cinco categorias: unit, security, fuzz, adversarial e integration. Cada categoria roda separadamente no CI, e mudanças não são integradas enquanto qualquer categoria falhar.

Arco de Auditorias Internas

De abril a junho de 2026 o protocolo passou por auditorias internas de segurança multi-agente: passes repetidos de revisão sobre a superfície dos contratos, com cada achado acompanhado até a correção. Duas ondas de remediação resultaram desse trabalho:

INTEGRADO EM 2026-04-24

Lote de remediação 1

6 achados críticos e 8 de severidade alta corrigidos, além de um conjunto de correções de severidade média.

INTEGRADO EM 2026-06-10

Lotes de remediação 2 e 3

4 achados críticos, 5 de severidade alta e 2 de severidade média corrigidos.

Esses números são achados que nós mesmos encontramos e corrigimos, antes de qualquer revisão externa. Nós os publicamos porque um código é melhor descrito por como os problemas são encontrados e fechados do que por uma alegação de que eles não existem.

Modelo de Ameaças

Um modelo de ameaças documentado é mantido para o protocolo: superfícies de ataque, premissas de confiança, papéis privilegiados e os invariantes que cada contrato deve preservar. Ele é revisado conforme o sistema evolui, em vez de escrito uma vez e arquivado.

Auditoria Externa e Implantação Atual

Uma auditoria externa está planejada antes de qualquer implantação em mainnet. O protocolo atualmente opera apenas na testnet Base Sepolia.

Princípios de Design

Algumas regras valem em todo o código:

Ordem checks-effects-interactions em toda função que altera estado.
Erros customizados em vez de reverts com strings, para que os modos de falha sejam explícitos e decodificáveis por máquina.
Máquinas de estado explícitas para o ciclo de vida dos ativos: transições são enumeradas e testadas, nunca implícitas.
Superfícies administrativas fail-closed: operações privilegiadas negam por padrão quando as precondições não são atendidas.

Perguntas sobre qualquer um desses pontos são bem-vindas. Fale conosco