Consulta à Comunidade — · Processo de Recovery · Snapshot bloco — · Polygon
Carregando…
Prazo da votação · registrado no contrato
Sobre esta consulta
Comunidade WEbdEX, durante as validações realizadas pela Engenharia, a partir de uma série de solicitações realizadas pelos operadores através do feedback, identificamos uma possibilidade de reestruturação da infraestrutura operacional enquanto o processo de Remint permanece em andamento. Antes de qualquer alteração, entendemos que essa decisão deve ser apresentada à comunidade de forma clara e submetida à sua avaliação.
Recovery é o processo. Remint e Reestruturação são caminhos.
Opção 1
Autorizar a Reestruturação Operacional
Autorizar a Engenharia a prosseguir com as validações para uma eventual substituição dos contratos Payments e Network, criando uma nova estrutura operacional enquanto o processo de Recovery continua. O contrato Payments é justamente o contrato-alvo do incidente original — substituí-lo, e não reabri-lo como estava, é parte do próprio desenho de segurança desta proposta.
Na prática, o desenho prevê reabrir os fluxos operacionais em uma estrutura nova, utilizando exclusivamente os valores em USDT já registrados para cada usuário e suas respectivas SubAccounts. O LOOP permanece fora das novas execuções enquanto seu contrato estiver desligado.
Importante: autorizar esta opção não significa remint imediato, distribuição imediata ou transferência automática. Durante a validação, poderá ser necessário alternar entre a nova estrutura e contratos anteriores para testar e validar o Recovery/remint.
Opção 2
Aguardar exclusivamente o Remint
Não realizar, neste momento, a substituição dos contratos Payments e Network. A Engenharia mantém a estrutura atual e concentra os esforços exclusivamente na continuidade das validações necessárias para o caminho de Recovery através do remint.
Em resumo: não se cria um novo fluxo operacional enquanto o processo de remint continua sendo validado.
Escopo operacional da Opção 1 · proposta em análise
Caso a comunidade autorize a Reestruturação Operacional, o desenho atualmente em validação prevê um fluxo restrito às operações em USDT. O colateral LOOP não será utilizado para execução operacional, pois o contrato do token LOOP permanece desligado pela Engenharia após o incidente.
Este bloco descreve o desenho operacional em análise. Ele não executa operações, não movimenta valores e não autoriza nenhuma alteração on-chain por si só.
Se a Opção 1 for autorizada · visão prática
O que muda para o operador?
A decisão agora é:
› Autorizar a Engenharia a avançar pela via da Reestruturação Operacional enquanto o Remint é desenvolvido? ou
› Manter a estrutura atual e aguardar exclusivamente a conclusão do caminho de Remint?
Entenda a diferença entre Remint e Reestruturação
É importante estabelecer uma distinção. Recovery é o gênero — o processo abrangente de recuperação e tratamento do estado dos contratos afetado pelo incidente. Dentro desse processo existem diferentes espécies de abordagem técnica, entre elas:
- Remint por reivindicação de posições — caminho destinado à reconstituição técnica dos registros representados pelos tokens afetados, mediante as condições e validações necessárias.
- Reestruturação operacional — caminho destinado ao desenvolvimento de uma estrutura operacional, incluindo a possibilidade de substituição dos contratos Payments e Network, permitindo trabalhar determinados fluxos registrados nas SubAccounts enquanto o Remint continua sendo desenvolvido.
Portanto, Remint e Reestruturação não são a mesma coisa e não são caminhos excludentes. A existência de uma possibilidade de reestruturação não encerra, substitui ou elimina o processo de remint por reivindicação de posições ou qualquer outra forma de remint que vier a ser desenvolvida — como, a título de curiosidade, o caso Transit Swap, em que a Tether congelou os tokens e ela mesma reemitiu novos.
A WEbdEX continuará conduzindo qualquer alternativa sob validação técnica, gestão de risco e transparência on-chain. A decisão sobre qual caminho operacional seguir pertence à comunidade.
Seu peso no snapshot
O peso do voto é o registrado para a sua carteira no snapshot público do bloco — (fontes e metodologia na trilha de auditoria). Conecte a carteira que estava no fluxo do protocolo — ou consulte qualquer endereço sem conectar.
Fonte: snapshot.json · root · — · CSV de origem ↗
Votar
Seu voto
Calculando o custo da transação…
Um voto por carteira, sempre com o peso integral do snapshot. Você envia o voto e paga o gas da rede — o custo estimado aparece acima, antes de você confirmar na carteira. O protocolo não opera relayer: ninguém registra voto em seu nome por padrão. Se preferir que outra pessoa envie por você, assine o voto: a assinatura prende proposta, opção, peso e endereço, e quem enviar não consegue alterar nenhum deles. O voto é público e não pode ser mudado depois.
O que esta votação faz
Ela registra on-chain, com o peso do snapshot, a decisão de cada operador sobre o caminho técnico a ser seguido no Recovery. E só isso. A votação:
- não movimenta USDT, LOOP nem qualquer outro ativo;
- não executa operações no protocolo;
- não realiza remint;
- não altera o saldo de nenhuma carteira ou subconta;
- não exige envio de ativo nem aprovação (approve) de token;
- não dá ao protocolo acesso à sua chave privada — a carteira só assina uma mensagem;
- não significa renúncia de direitos, posição ou valores;
- não produz resultado financeiro pelo simples ato de votar.
A decisão é sobre qual caminho técnico será autorizado para o processo de recuperação — Recovery é o gênero; Remint e Reestruturação são espécies dentro dele.
Resultado parcial
Fonte: eth_call getProposal(id) · bloco — · contrato no PolygonScan ↗ ·
Calculado a partir do snapshot público desta consulta, ordenando as carteiras por peso. O voto é ponderado pelo capital que cada carteira tinha antes do ataque — e esse capital é concentrado. Isto não é regra da votação, é o retrato do que existia.
Trilha de auditoria
- Contrato
- —
- Merkle root (on-chain)
- —
- Merkle root (snapshot.json)
- —
- Bloco do snapshot
- —
- Peso total do snapshot
- —
- Carteiras elegíveis
- —
- Snapshot URI
- —
- Metodologia
- —
- Reproduzir o root
- node scripts/build-snapshot.mjs --source lp_snapshot_combined.csv --block — --exclude exclude.txt
- —
Perguntas frequentes
Por que meu voto não vale 1, como o de todo mundo?
A política de governança do protocolo é por voto qualitativo: quem tinha mais capital no protocolo tem mais peso na decisão. O peso de cada carteira é o saldo de LP que ela tinha no bloco 85.653.578 — o pico, antes da queima — somando os quatro contratos de LP (USDT e LOOP, nos ambientes V5 e CS) por endereço. Só LP entra na conta. Saldo em subconta de USDT não é somado: o LP é a prova de liquidez, e é ele que o snapshot mede. O peso é fixo, público e verificável no snapshot.json e no CSV de origem. Se o número não bater com o que você esperava, confira seu endereço no campo de consulta acima antes de abrir chamado.
Posso mudar meu voto depois?
Não. O contrato aceita um voto por carteira por proposta e o registra on-chain de forma imutável. Confira a opção antes de confirmar.
Quanto custa votar?
O custo é o gas da rede Polygon, pago por você. Na medição feita em 30/08/2026 uma transação de voto custava cerca de 0,06 POL — em torno de US$ 0,006. A página calcula o valor do momento e mostra logo abaixo dos botões, antes de você confirmar na carteira; a própria carteira mostra o valor de novo na hora de assinar. Não há relayer: o protocolo não paga o gas por você. POL se compra em qualquer corretora ou se recebe de outra carteira — a quantia necessária para votar é de centavos.
Qual a diferença entre "Votar agora" e "Assinar o voto"?
Votar agora envia a transação da sua própria carteira: você paga o gas e o voto entra na Polygon em segundos. É o caminho normal.
Assinar o voto não envia nada — produz uma mensagem assinada (EIP-712) com proposta, opção, peso, seu endereço e um prazo. Serve para quando outra pessoa vai enviar por você: ela paga o gas e não consegue mudar nenhum desses campos, porque qualquer alteração invalida a assinatura e o contrato rejeita. Se você assinar e ninguém enviar, seu voto não existe — confira em "Últimos votos on-chain" se ele foi registrado.
Como verifico se o snapshot é o mesmo que está no contrato?
Esta página compara o Merkle root do snapshot.json com o root gravado na proposta (getProposal(id).merkleRoot). Você pode reproduzir o root a partir do CSV público com o script build-snapshot.mjs — se bater, o arquivo é íntegro.
Minha carteira não aparece no snapshot. E agora?
O snapshot lista as carteiras com saldo no bloco de referência. Se você acredita que deveria constar, registre formalmente sua posição pelo Canal de Ouvidoria Técnica ↗ com endereço, TXIDs e o saldo no bloco do snapshot. A blockchain é a única fonte de verdade aceita.
Como funciona a operação proposta na Reestruturação?
Se a Opção 1 for autorizada e as validações técnicas forem concluídas, o desenho em análise prevê operações exclusivamente em USDT, utilizando os valores correspondentes de cada usuário já registrados no protocolo. LOOP não será utilizado para novas execuções enquanto seu contrato permanecer desligado. O operador deverá manter POL para gas, e eventual liquidação operacional prevista seria direcionada à wallet correspondente do próprio usuário, em USDT, sempre respeitando as regras e validações que forem efetivamente aprovadas.
Voltar a operar elimina o risco?
Não. A retomada operacional, caso aprovada e implementada, não elimina os riscos próprios da blockchain, dos smart contracts, da execução ou das condições de mercado. A decisão deve continuar baseada em Risco · Responsabilidade · Retorno.