Ir para o conteúdo
Financial Context Wiki

Rug pulls

Rug pull é um golpe de saída em que pessoas do projeto usam o controle da liquidez, dos contratos ou de posições concentradas para extrair valor e causar grandes perdas.

Atualizado

Somente para fins educacionais; não é recomendação de investimento. Criptoativos podem perder todo o valor e transferências podem ser irreversíveis.

Resposta direta

Rug pull é um golpe de saída: pessoas do projeto extraem valor controlando liquidez, contratos, tesouraria ou grandes posições. Pode ser súbito, com a retirada da liquidez de um AMM, ou gradual, com vendas repetidas enquanto o trabalho prometido é abandonado.

As rotas comuns incluem retirar ativos por posições de liquidez, cunhar ou transferir oferta inesperada, impor restrições de venda ou taxas extremas exceto a endereços privilegiados, atualizar contratos e desviar fundos tidos como protegidos. Código malicioso, poderes administrativos comuns ou transações sem backdoor podem bastar.

Intenção e controle importam. Queda de preço, exploit, produto fracassado ou equipe inativa não são automaticamente rug pull. Golpe de saída, honeypot e pump-and-dump se sobrepõem, mas descrevem mecanismos diferentes.

Rug pulls
0 / 5
0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

Como funciona

Em um AMM, provedores depositam um par de ativos e recebem uma posição ou tokens de liquidez. Quem controla uma posição resgatável pode retirar sua parte. Se pessoas do projeto dominam a liquidez removível, podem retirar o ativo necessário à saída e vender no pool reduzido; preço e valor executável podem despencar.

Rugs contratuais usam privilégios: a lógica pode cunhar, congelar endereços, mudar taxas e limites, redirecionar transferências ou impedir vendas via transfer e transferFrom. Um administrador proxy pode trocar a implementação. Funções, multisig e timelock só protegem se a configuração implantada restringir todos os poderes.

Rugs transacionais ou “suaves” usam transferências comuns: vendem alocações, esvaziam tesourarias, falseiam um bloqueio ou encerram desenvolvimento e comunicação após captar. Identidades, auditorias e roteiros aumentam a responsabilização, mas não provam restrições técnicas.

A blockchain mostra estado e fluxos, mas não prova sozinha o controlador real ou a intenção. Revisões e detectores cobrem código, estado e padrões específicos em um momento; a pesquisa distingue várias causas e alerta que nenhum detector cobre tudo.

Revisão antes da operação

  • Confirme rede, token, pool e implementação proxy ativa em fontes independentes; nome ou símbolo não bastam.

  • Mapeie o controle das posições: detentor, ativos e pool bloqueados, beneficiário, vencimento e rotas capazes de contornar o bloqueio.

  • Liste proprietários, funções, regras multisig, timelocks, administradores, poderes de cunhagem e taxas, listas, pausa e saques da tesouraria conforme o estado atual on-chain.

  • Examine concentração, vínculos de financiamento, transferências da tesouraria, mudanças de liquidez e vendas reais independentes; compare o tamanho às reservas e ao resultado executável.

  • Verifique auditorias, vesting, bloqueios, parcerias e identidades de forma independente; depois teste apenas uma pequena ida e volta cuja perda total seja suportável. O sucesso vale só naquele momento e valor.

A revisão é um mapa de controles, não uma nota de segurança. Uma rota sem restrição pode superar muitos sinais positivos; a ausência de um alerta conhecido não prova segurança.

Sinais de alerta e resposta

  • Liquidez rasa, recente, concentrada, desbloqueada ou com contrato, beneficiário, ativos ou vencimento não verificáveis.

  • Código ou proxy ativo incerto, ou contas privilegiadas capazes de cunhar, bloquear vendas, mudar taxas, atualizar, mover tesouraria ou retirar liquidez sem atraso real.

  • Oferta e liquidez concentradas, carteiras internas conectadas ou distribuição e vesting muito diferentes do publicado.

  • Marketing garante retorno ou cria urgência, mas equipe, auditoria, parceria, receita e bloqueio não podem ser confirmados.

  • Vendas independentes ausentes ou falhas, scanners discordantes, transferências inexplicadas a pessoas do projeto ou perguntas sobre permissões e liquidez de saída desencorajadas.

Um bloqueio comprova apenas posição, ativos, contrato, beneficiário e período identificados. Sem limites separados, não impede cunhagem, bloqueios ocultos, roubo da tesouraria, vendas internas, outro pool ou atualização. Auditoria também não é garantia.

Se suspeitar de rug pull, pare de enviar fundos e não assine transações de “recuperação” do projeto. Guarde endereços, hashes, mensagens e sites; revogue aprovações desnecessárias por interface confiável e informe plataforma ou autoridades. Revogar não desfaz transferências nem recupera liquidez.

Equívocos comuns

  • “Liquidez bloqueada impede rug pull.” O bloqueio pode ser parcial, curto, falso ou alheio ao pool ativo; outras rotas podem permanecer.

  • “Renunciar à propriedade elimina privilégios.” Outras funções, administradores proxy, controladores externos ou lógica pré-configurada podem manter poder.

  • “Código verificado ou auditoria prova segurança.” A verificação liga fonte e bytecode, e a auditoria tem escopo e data; nenhuma prova honestidade ou controles limitados.

  • “Um scanner ou venda pequena descarta o rug pull.” Ferramentas omitem causas, e permissões, estado, liquidez, implementação, remetente, rota ou tamanho mudam o resultado.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...