Serviços e operação

O repositório contém dois processos independentes: um keeper que envia chamadas permissionless e um retransmissor de eventos que pode preparar publicações. Uma configuração local não prova que um serviço funciona continuamente.

O keeper

O keeper verifica a rede e as conexões Hook/Lens e consulta o snapshot. No percurso documentado, prioriza o rebalanceamento quando elegível, depois a alocação dos fundos e, por fim, a queima isolada quando as outras operações não estão disponíveis.

Ele simula antes do envio e processa no máximo uma ação por bloco. As recusas de elegibilidade esperadas são resultados normais; erros RPC e simulações inesperadas devem aparecer como erros que permitam ação operacional.

Começar em dry-run

Em services/, após instalação e configuração local conforme o README:

DRY_RUN=true pnpm keeper:once

Esse modo permite verificar a rede, a implantação, os endereços resolvidos, as elegibilidades e as estimativas sem enviar transação.

A carteira operacional deve ser dedicada ao gas. Ela não precisa ser o deployer, a equipe ou o guardian. Os parâmetros de gas máximo e recompensa mínima limitam a execução; não garantem lucro.

Registro de transação e recuperação

O keeper separa os estados por cadeia, hook, carteira e modo dry-run/live. Usa uma trava de processo local e um registro durável de intenção, nonce e hash.

Após um timeout ou reinício, retoma o acompanhamento da transação existente antes de preparar nova ação. Uma intenção sem hash é ambígua: compare os nonces pendentes e minerados da carteira antes de alterar o registro.

Um arquivo .lock só deve ser removido após confirmar que seu processo antigo não está mais em execução. Essas travas são locais; não coordenam várias máquinas. Use carteira e estado adequados a cada instância.

Evolução dos módulos

O Lens atual é resolvido pelo registro. Mantenha a identidade do núcleo e o contexto de revisão durante toda a operação.

A versão de múltiplos muros exige atualizar ABI, prévias, motivos de recusa e eventos. Um keeper adaptado ao muro único não deve ser apresentado como validado para a nova versão sem seus testes de aceitação.

O retransmissor de eventos

services/floor-bot lê os eventos, prepara um texto e mantém um cursor e as chaves de deduplicação transactionHash:logIndex.

O modo dry-run e o modo de publicação têm estados separados. Os cursores incluem o contexto de cadeia e hook; blocos finalizados são usados nas redes previstas pelo serviço. Uma reorganização ou um checkpoint inconsistente deve ser conciliado antes da retomada.

O retransmissor persiste um pendingPost antes da publicação. Se o serviço externo aceitar a mensagem, mas o processo parar antes de registrar o sucesso, é preciso verificar se a mensagem existe antes de reenviar: um banco local e uma rede social não podem confirmar uma operação juntos.

O GitBook não publica mensagens. Colocar o retransmissor em funcionamento exige configuração e autorização operacionais separadas.

Adaptar o vocabulário aos muros fixos

O retransmissor antigo anunciava eventos FloorRaised. Com a política instantânea, um financiamento pode criar um muro em preço inferior ao último financiamento, preservando os níveis antigos.

O retransmissor deve citar o muro envolvido, seu nível e os fundos acrescentados, sem deduzir uma alta global apenas pelo nome do evento. Mensagens antigas como “o floor sempre sobe” não descrevem essa política.

Verificações operacionais úteis

Acompanhe os erros RPC, as diferenças de configuração, os recibos pendentes, as falhas de simulação, o saldo de gas do keeper e a idade do último bloco processado. Guarde registros de recuperação e identidades de versão, sem dados privados de assinatura.

Uma supervisão que reinicia processos não substitui a resolução de um nonce ambíguo ou de uma mudança de registro.

Fontes: services/keeper/README.md, services/floor-bot/README.md, services/keeper/src/index.ts e services/shared.