Pular para o conteúdo principal
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:

Preço dentro da faixa 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.

Preço fora 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.

Faixa total

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.

Faixa personalizada

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:

Taxas de LP (ganhas)

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.

Gas de rede (pago)

Necessário para aprovações e para a transação de criação da posição.

Taxas de serviço e restrições de política

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:

Preço do pool relevante para execução

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.

Valoração em fiat e histórico

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

1

Abrir Invest para o pool alvo

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.
2

Conectar uma carteira e alinhar a rede

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.
3

Selecionar a estratégia de faixa e definir a banda

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.
4

Inserir os montantes de depósito

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.
5

Concluir aprovações de tokens (apenas ERC-20)

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.
6

Enviar e confirmar a criação da posição

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).
7

Verificar e monitorar a posição

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

Botão Create desativado

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.

Ambos os montantes de token são obrigatórios

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.

Aprovação necessária

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.

Provisionamento não autorizado

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.

Simulação falhou / transação revertida

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.

Rede incompatível

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.

Informações úteis para suporte e reconciliação

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.

Risco de faixa e atividade

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.

Risco de composição e performance

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).

Risco de contrato inteligente e rede

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.