Services et exploitation

Le dépôt contient deux processus indépendants : un keeper qui envoie des appels permissionless et un relais d’événements qui peut préparer des publications. Une configuration locale ne prouve pas qu’un service tourne en continu.

Le keeper

Le keeper vérifie le réseau et les liaisons Hook/Lens, puis consulte le snapshot. Dans le parcours documenté, il privilégie le rebalance lorsqu’il est éligible, sinon le placement des fonds, puis le burn isolé lorsque les autres opérations ne sont pas disponibles.

Il simule avant l’envoi et traite au plus une action par bloc. Les refus d’éligibilité attendus sont des résultats normaux ; les erreurs RPC et les simulations inattendues doivent remonter comme erreurs exploitables.

Commencer en dry-run

Depuis services/, après installation et configuration locale conforme au README :

DRY_RUN=true pnpm keeper:once

Ce mode permet de vérifier le réseau, le déploiement, les adresses résolues, les éligibilités et les estimations sans soumettre de transaction.

Le wallet d’exploitation doit être dédié au gas. Il n’a pas besoin d’être le deployer, l’équipe ou le guardian. Les paramètres de gas maximum et de prime minimum limitent l’exécution ; ils ne garantissent pas un bénéfice.

Journal de transaction et reprise

Le keeper sépare les états par chaîne, hook, wallet et mode dry-run/live. Il utilise un verrou de processus local et un journal durable d’intention, de nonce et de hash.

Après un timeout ou un redémarrage, il reprend le suivi de la transaction existante avant de préparer une nouvelle action. Une intention sans hash est ambiguë : comparez les nonces pending et minés du wallet avant de modifier le journal.

Un fichier .lock ne doit être retiré qu’après confirmation que son ancien processus ne tourne plus. Ces verrous sont locaux ; ils ne coordonnent pas plusieurs machines. Utilisez un wallet et un état adaptés à chaque instance.

Évolution des modules

Le Lens courant est résolu depuis le registre. Conservez l’identité du cœur et le contexte de révision pendant toute l’opération.

La version multi-murs exige une mise à jour des ABI, des prévisualisations, des motifs de refus et des événements. Un keeper adapté au mur unique ne doit pas être présenté comme validé pour cette nouvelle version sans sa recette.

Le relais d’événements

services/floor-bot lit les événements, prépare un texte et conserve un curseur ainsi que les clés de déduplication transactionHash:logIndex.

Le mode dry-run et le mode publication ont des états séparés. Les curseurs incluent le contexte de chaîne et de hook ; les blocs finalisés sont utilisés sur les réseaux prévus par le service. Une réorganisation ou un checkpoint incohérent doit être réconcilié avant reprise.

Le relais persiste un pendingPost avant publication. Si le service externe accepte le message mais que le processus s’arrête avant l’enregistrement du succès, il faut vérifier l’existence du message avant de relancer : une base locale et un réseau social ne peuvent pas committer ensemble.

Le GitBook n’exécute aucune publication. L’activation réelle du relais relève d’une configuration et d’une autorisation opérationnelles distinctes.

Adapter le vocabulaire aux murs fixes

L’ancien relais annonçait des événements FloorRaised. Avec la politique instantanée, un financement peut créer un mur à un prix inférieur au dernier financement tout en conservant les anciens niveaux.

Le relais doit donc citer le mur concerné, son niveau et les fonds ajoutés, sans déduire une hausse globale du seul nom de l’événement. Les anciens messages « le floor monte toujours » ne décrivent pas cette politique.

Contrôles d’exploitation utiles

Suivez les erreurs RPC, les écarts de configuration, les reçus en attente, les échecs de simulation, le solde gas du keeper et l’âge du dernier bloc traité. Conservez les journaux de reprise et les identités de version, sans données de signature privées.

Une supervision qui redémarre les processus ne remplace pas la résolution d’un nonce ambigu ou d’un changement de registre.

Sources : services/keeper/README.md, services/floor-bot/README.md, services/keeper/src/index.ts et services/shared.