> ## Documentation Index
> Fetch the complete documentation index at: https://docs.levery.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Segurança

> Explore nossos guias e exemplos para aproveitar ao máximo a Levery.

## Segurança em primeiro lugar, com auditoria comprovada

A Levery é projetada para ambientes regulados em que **autorização**, **controles** e **auditabilidade** são inegociáveis.
Segurança é tratada como uma parte explícita e governável do sistema: a aplicação acontece **antes de mudanças de estado**, a propriedade é
**fortemente vinculada**, e mudanças de configuração são **observáveis e revisáveis**.

***

## Auditoria de segurança independente

A suíte de smart contracts da Levery foi auditada pela **Runtime Verification**, uma empresa de segurança reconhecida por combinar técnicas
convencionais de auditoria com **métodos matematicamente fundamentados** (incluindo análise orientada a propriedades e execução simbólica) para validar
comportamentos críticos do sistema.

* **Relatório entregue:** 3 de outubro de 2025
* **Janela de auditoria:** 16 de julho → 15 de agosto de 2025
* **Commit auditado:** `970ec76`

### Baixe o relatório

* **[Relatório de Auditoria de Segurança da Levery](https://amp.runtimeverification.com/public-report/levery)**

### Escopo da auditoria (contratos in-scope)

* `src/Levery.sol`
* `src/CompliantRouter.sol`
* `src/SoulboundPositionManager.sol`
* `src/utils/PermissionManager.sol`
* `src/utils/BaseSwapRouterPermit2.sol`
* `src/utils/PositionDescriptor.sol`
* `src/libraries/Descriptor.sol`

<Warning>
  Esta documentação intencionalmente **não** enumera achados de auditoria. O relatório de auditoria é a fonte autoritativa
  para escopo, pressupostos, metodologia e resultados.
</Warning>

***

## Salvaguardas do ledger confiável

A Levery herda propriedades centrais da execução on-chain que reduzem materialmente o risco institucional:

* **Liquidação atômica:** ações ou liquidam totalmente ou revertem com estado inalterado.
* **Execução determinística:** entradas idênticas produzem resultados idênticos entre validadores.
* **Histórico à prova de adulteração:** validação, transferências e contabilidade são registradas permanentemente, permitindo reconstrução pós-evento.

Isso remove modos comuns de falha de contraparte e reconciliação encontrados em caminhos de execução intermediados. Os riscos residuais tornam-se
**programáticos**, o que os torna mensuráveis, testáveis e governáveis por meio de controles explícitos.

***

## Padrão global de segurança

A postura da Levery é construída em torno de **invariantes explícitos** e comportamento **fail-closed** sob condições anormais.

### Invariante 1 — Autorização precede mudança de estado

Cada swap ou mutação de liquidez é protegido por checagens de autorização e política **antes de qualquer transição de estado**. Se uma pré-condição falha,
a execução reverte e deixa o estado inalterado.

Pré-condições típicas incluem:

* entrada por uma superfície de execução aprovada (router / position manager)
* extração determinística de identidade a partir dos dados da requisição
* validação de permissão e (opcional) papéis exigidos pelo pool
* checagens de pausa global e por pool

### Invariante 2 — Propriedade de liquidez é fortemente vinculada

Posições de liquidez são emitidas como **tokens intransferíveis (soulbound)**, vinculando a propriedade a entidades verificadas e prevenindo
transferência não autorizada de direitos de liquidez.

Impacto em segurança:

* impede transferências secundárias não aprovadas de propriedade de LP
* suporta governança institucional e políticas em nível de entidade
* permite atribuição determinística de propriedade em ferramentas de monitoramento, risco e auditoria

### Invariante 3 — Guardrails informados por oráculos (opcional)

Oráculos, quando configurados, fornecem inputs para guardrails de desvio e dinâmica de taxas. A política de oráculos é relevante para segurança e deve ser
tratada como configuração governada:

* fontes de oráculo aceitáveis por pool
* expectativas de frescor e política de obsolescência
* procedimentos de resposta a incidentes (pausar/rotacionar/fallback)

<Warning>
  Inputs de oráculos podem afetar a qualidade da execução e o comportamento do mercado. Trate a configuração de oráculos como uma superfície de controle
  monitorada com um playbook documentado.
</Warning>

### Invariante 4 — Dinâmica de taxas com limites

Taxas são expressas em **partes por milhão (ppm)** e são limitadas por design.

Um modelo mental útil:

$$
F_{dynamic} = clamp\big(F_{base} + \alpha \cdot deviation,\ 0,\ MAX\_PPM\big)
$$

Onde:

* `MAX_PPM = 1,000,000` (100%)
* `F_base` é a taxa base configurada (global ou por pool)
* `α` é o fator de desvio
* `deviation` é derivado do preço do pool vs. oráculo (quando habilitado)

Isso mantém o comportamento de taxas previsível e revisável mesmo sob inputs extremos.

### Invariante 5 — Circuit breakers impõem comportamento fail-closed

A Levery suporta circuit breakers operacionais projetados para contenção rápida:

* **Pausa global** (emergências em nível de protocolo)
* **Pausa por pool** (incidentes específicos de venue como anomalias de oráculo, risco de ativos, condições anormais de mercado)

Quando em pausa, o sistema se comporta como **fail-closed**: ações de usuário que mutariam estado não prosseguem.

### Invariante 6 — Aritmética e arredondamento determinísticos

Comportamento de aritmética e arredondamento é tratado de forma determinística para evitar resultados ambíguos e suportar análises pós-evento reproduzíveis.

***

## Limites de confiança e superfície de governança

Uma implantação segura começa com um modelo claro de limites de confiança: liquidação vs. política vs. inputs externos vs. administração.

<Mermaid
  chart={`flowchart LR
subgraph settlement ["Settlement"]
CORE["AMM settlement & accounting"]
end

subgraph policy_enforcement ["Policy Enforcement"]
POLICY["Levery policy & fee logic"]
PERM["Permission registry"]
end

subgraph external_inputs ["External Inputs"]
ORC["Oracles (optional)"]
end

subgraph operations ["Operations"]
ADM["Admin keys / multisig"]
VAULT["Fee vault / distribution"]
end

PERM --> POLICY
ORC --> POLICY
ADM --> POLICY
POLICY --> CORE
POLICY --> VAULT
`}
/>

Uma questão prática de governança surge imediatamente:

> Quem pode mudar inputs de política, e com que rapidez a instituição consegue detectar e responder a configurações ou inputs anormais?

***

## Segurança operacional

A Levery foi projetada para ser **governada**, não “configurada e esquecida”. Configuração sensível à segurança deve seguir gestão de mudanças em produção.

### Segregação de funções

Uma baseline forte para implantações institucionais:

* **Autoridade do provedor:** controles em nível de protocolo, gestão crítica de endereços, política global, procedimentos de emergência
* **Autoridade da instituição:** configuração de pool, toggles de venue, definições de papéis, parâmetros de mercado
* **Operador de compliance:** atribuição de permissões e direitos, idealmente isolada do controle de parâmetros de taxa/pool

### Gestão de chaves

Postura recomendada para produção:

* multisig para papéis privilegiados com política de assinatura explícita
* chaves com hardware e acesso de menor privilégio
* revisão periódica de acesso e procedimentos de rotação de chaves

### Resposta a incidentes

Tenha playbooks testados para:

* incidente de oráculo → pausa do pool + rotação/fallback de oráculo
* padrões de execução anormais → pausa + investigação + rollback
* comprometimento de chave admin → pausa de emergência + rotação de chaves

***

## Monitoramento contínuo e atestações

Como a aplicação de políticas e mudanças de parâmetros são registradas on-chain, instituições podem se apoiar em **evidências verificáveis** em vez de afirmações.

Monitore continuamente:

* mudanças de permissão/papel (quem / o quê / quando)
* mudanças de configuração de pool (taxas, atribuições de oráculo, estado de pausa)
* ativações de circuit breaker e violações de limites
* fluxos de roteamento de taxas (destinatários + valores)
* taxas de reversão anormais e anomalias de execução

Isso permite:

* alertas automatizados e dashboards de compliance
* atestações automatizadas (por exemplo, “apenas entidades aprovadas interagiram com o pool X durante o período Y”)
* reconstrução pós-evento precisa para comitês de risco e supervisores

***

## Escopo e não objetivos

O modelo de segurança on-chain da Levery **não** substitui:

* produtos de custódia e gestão de chaves
* integridade de provedores de identidade e garantias de screening AML
* hardening de infraestrutura (RPC, indexação, hospedagem)
* segurança de endpoints/dispositivos (phishing, malware, comprometimento de conta)

O papel da Levery é fornecer **aplicação determinística e execução auditável**, integrando-se de forma limpa aos controles institucionais.

***

## Próximas páginas

* [Arquitetura](/pt/architecture) — componentes, limites de confiança e fluxo de execução
* [Guia do administrador](/pt/admin/introduction) — governança e controles operacionais para implantações em produção