> ## 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. # Prover Liquidez > Forneça liquidez a pools permissionadas criando posições por faixa (faixa total ou faixa personalizada) sob políticas institucionais. O provisionamento de liquidez fornece ativos a um pool AMM para que swaps possam ser executados com liquidação determinística on-chain. Em um ambiente Levery operado por uma instituição, a liquidez é expressa como uma **posição por faixa**: cada posição define um **preço mínimo** e um **preço máximo** e contribui com liquidez de acordo com onde o preço do pool se encontra em relação a essa banda. O mesmo mecanismo suporta: * **Posições de faixa total** (banda maximamente ampla), e * **Posições de faixa personalizada** (banda finita para maior concentração). Este guia descreve o provisionamento de liquidez como vivenciado por usuários finais de uma instância Levery operada por uma instituição. Pools disponíveis, ativos e verificações de permissão são definidos pela configuração e governança da instituição. *** ## Como posições por faixa se comportam Uma posição é definida por: * **Par**: `Token0 / Token1` * **Faixa**: **Preço Mínimo** e **Preço Máximo** * **Liquidez**: a quantidade on-chain cunhada derivada dos montantes de tokens depositados e dos ticks selecionados O acúmulo de taxas segue uma regra simples: * **Taxas de LP acumulam** quando swaps são executados enquanto a posição está **ativa**. * Uma posição está **ativa** quando o preço do pool está **dentro** da faixa selecionada. * Se o pool usa **taxas de LP dinâmicas**, a taxa efetiva de LP pode variar segundo a lógica configurada do pool. Os resultados definitivos são on-chain. Os valores da interface são derivados do estado do contrato, logs e reconciliação do indexador, e podem ser verificados de forma independente via hashes de transação e leituras de estado. *** ## Direção de preço e composição do depósito Os preços são exibidos em uma direção de cotação consistente. Os requisitos de depósito são determinados pela relação entre o preço atual e a banda selecionada: A posição requer **ambos os tokens**. A interface normalmente calcula o valor correspondente do outro lado para que o depósito corresponda à geometria da faixa selecionada. A posição se torna efetivamente **unilateral**: * **Abaixo da faixa** → somente Token0 * **Acima da faixa** → somente Token1 Se o preço atual estiver dentro da faixa selecionada e um lado for zero, a transação de criação da posição será rejeitada. Ambos os montantes de tokens devem ser fornecidos (frequentemente via preenchimento automático do segundo lado). *** ## Faixa total vs faixa personalizada Faixa total e faixa personalizada são duas estratégias sobre o mesmo modelo de posições por faixa. Usa a banda admissível mais ampla para o pool. A posição normalmente fica ativa em grande parte dos estados de mercado. Adequado quando se prioriza continuidade de atividade e minimização de eventos fora da faixa, aceitando menor densidade de taxas por unidade de capital. Define uma banda finita de Mín/Máx em torno de uma região de preço alvo. A posição fica inativa quando o preço sai da banda. Adequado quando se deseja maximizar a densidade de taxas perto de uma faixa de negociação esperada, aceitando maior probabilidade de ficar fora da faixa. ### Ticks e granularidade da faixa As faixas são implementadas usando **ticks** discretos. Cada pool define um `tickSpacing`, que limita o tamanho mínimo do passo para movimentação da faixa. Operacionalmente: * A seleção no slider se ajusta às fronteiras de tick. * Os controles de passo de Mín/Máx ajustam em incrementos de tick. * O zoom afeta apenas a visualização; não altera as fronteiras de tick selecionadas. *** ## Custos, taxas e o que acumula O provisionamento de liquidez envolve categorias contábeis distintas: Acumulam quando swaps são executados enquanto a posição está ativa. Os ganhos realizados dependem do volume executado, da configuração de taxa (estática/dinâmica) e da participação de liquidez da posição nos ticks ativos. Necessário para aprovações e para a transação de criação da posição. Taxas de serviço não são cobradas em eventos de liquidez (mint, increase, decrease, collect, close). Elas são aplicadas apenas nos fluxos de execução de swaps. O provisionamento de liquidez ainda pode estar sujeito a controles institucionais, como verificações de elegibilidade, allowlists e regras de nível de risco, aplicadas pela camada de políticas do ambiente. *** ## Camadas de precificação e origem A página Invest comumente usa duas camadas de precificação com objetivos diferentes: A geometria da faixa, o status dentro da faixa e a composição de tokens são derivados do estado on-chain do pool (por exemplo, sqrtPrice/tick). Esta é a fonte de verdade para resultados de execução. Conversões para fiat e gráficos históricos são respaldados por feeds de preços aprovados pela instituição (oracle e dados de mercado indexados), garantindo auditabilidade e consistência de relatórios. *** ## Criar uma posição de liquidez Acesse a tela de Invest do pool (geralmente via **Pools → Invest**). Valide: * a chain/rede onde o pool está implantado, * o par (`Token0 / Token1`), * e a direção de preço exibida usada para entradas de Mín/Máx. Selecione **Connect Wallet** e conecte uma carteira autorizada a interagir com o ambiente da instituição. Se a rede da carteira não corresponder à chain do pool, a execução é bloqueada até que a rede da carteira seja trocada. Alguns conectores podem solicitar a troca de rede; caso contrário, é necessária a seleção manual na carteira. Escolha **Faixa total** para uma banda máxima ou **Faixa personalizada** para uma banda finita. Para Faixa personalizada: * defina a banda usando o slider, * refine Mín/Máx usando entradas numéricas, * e aplique controles de passo por tick para precisão. Em **Deposit Tokens**, insira o montante de contribuição pretendido. A interface calcula a composição do depósito a partir de: * o estado atual do preço do pool, * as fronteiras de tick selecionadas, * e a matemática de liquidez da faixa (mapeando montantes de tokens para liquidez cunhada). Quando o preço atual estiver dentro da banda, o segundo lado do token deve ser preenchido (comumente via preenchimento automático). Quando o preço estiver fora da banda, o depósito pode ser efetivamente unilateral. Depósitos ERC-20 geralmente exigem allowances antes que os fundos possam ser movimentados durante a criação da posição. Muitas implantações Levery usam um modelo reforçado de allowances em duas camadas: 1. **Token → Permit2** (allowance do token concedida ao Permit2) 2. **Permit2 → Position Manager** (allowance do Permit2 concedida ao position manager do pool) Cada aprovação é uma transação on-chain e requer gas. Pernas em moeda nativa não exigem aprovações ERC-20. O envio transmite uma única execução on-chain que: * cunha liquidez para os ticks selecionados, e * liquida a transferência do par de tokens exigida para essa cunhagem. A interface normalmente realiza uma simulação prévia para indicar falhas comuns antecipadamente (aprovações ausentes, saldo insuficiente, ordenação inválida de ticks ou aplicação de políticas). Após a confirmação: * a posição se torna visível em **Positions**, * o status dentro da faixa e a composição são acompanhados ao longo do tempo, * e o acúmulo de taxas é exposto por meio de contabilidade on-chain. Muitas implantações Levery representam posições como **tokens de posição intransferíveis** (soulbound), vinculando o controle à carteira do proprietário em vez de permitir transferências. *** ## Solução de problemas Causas típicas: carteira não conectada, rede incompatível, estado do pool não carregado ou metadados de token ausentes necessários para calcular depósitos. Se o preço atual estiver dentro da banda selecionada, ambos os lados devem ser diferentes de zero. Depósitos unilaterais só têm sucesso quando o preço está fora da banda. Uma ou ambas as camadas de allowance podem estar ausentes. Conclua as aprovações Token → Permit2 e Permit2 → Position Manager e, em seguida, tente novamente após as confirmações. Alguns pools restringem provedores de liquidez. Se o provisionamento estiver bloqueado por política ou allowlist, um administrador institucional deve habilitar a permissão de liquidez para a conta. Causas comuns: saldo insuficiente, estado de allowance desatualizado, ordenação inválida de ticks ou aplicação por políticas do pool e módulos de permissão. Atualizar o estado após confirmações pode resolver sintomas de latência do indexador. A rede da carteira deve corresponder à chain do pool. Se a troca pelo conector falhar, é necessária a seleção manual da rede na carteira antes de tentar novamente. Quando a escalada for necessária, forneça: chain id, pool id, Mín/Máx selecionados, montantes de depósito e hashes de transação para aprovações e a tentativa de criação de posição. *** ## Notas de risco Provisionamento de liquidez é exposição ao mercado, não rendimento garantido. Quando o preço sai da banda selecionada, a posição deixa de ganhar taxas até que o preço retorne. Bandas mais estreitas podem aumentar a densidade de taxas, mas aumentam a probabilidade de saída da faixa. A composição de tokens muda conforme o preço atravessa a banda. Em relação a manter os tokens, o desempenho pode ser inferior dependendo do caminho de preço e da captura de taxas (dinâmica de perda impermanente). Os resultados dependem do comportamento do contrato, da finalidade da rede e das condições de execução. Instituições normalmente mitigam riscos por meio de auditorias, implantações controladas e monitoramento operacional. Verificações de elegibilidade, allowlists e controles em nível de pool podem restringir o provisionamento de liquidez. Se o provisionamento estiver bloqueado, a resolução requer uma ação do operador sob o processo de governança e conformidade da instituição.