Services and operations
The repository contains two independent processes: a keeper that sends permissionless calls and an event relay that can prepare posts. Local configuration does not prove that a service runs continuously.
The keeper
The keeper checks the network and Hook/Lens connections, then reads the snapshot. In the documented workflow, it prioritizes rebalance when eligible, otherwise fund placement, then isolated burning when the other operations are unavailable.
It simulates before sending and processes at most one action per block. Expected eligibility rejections are normal results; RPC errors and unexpected simulations must surface as actionable errors.
Starting in dry-run
From services/, after installation and local configuration according to the README:
DRY_RUN=true pnpm keeper:once
This mode checks the network, deployment, resolved addresses, eligibility and estimates without submitting a transaction.
The operations wallet should be dedicated to gas. It does not need to be the deployer, team or guardian. Maximum gas and minimum bounty parameters limit execution; they do not guarantee profit.
Transaction journal and recovery
The keeper separates states by chain, hook, wallet and dry-run/live mode. It uses a local process lock and a durable journal of intent, nonce and hash.
After a timeout or restart, it resumes tracking the existing transaction before preparing a new action. An intent without a hash is ambiguous: compare the wallet’s pending and mined nonces before changing the journal.
Remove a .lock file only after confirming that its old process is no longer running. These locks are local; they do not coordinate multiple machines. Use a suitable wallet and state for each instance.
Module changes
The current Lens is resolved from the registry. Preserve the core identity and revision context throughout the operation.
The multiple-wall version requires updated ABIs, previews, rejection reasons and events. A keeper adapted to a single wall must not be presented as validated for this new version without acceptance testing.
The event relay
services/floor-bot reads events, prepares text and keeps a cursor along with transactionHash:logIndex deduplication keys.
Dry-run and publication modes have separate states. Cursors include chain and hook context; finalized blocks are used on networks supported by the service. A reorganization or inconsistent checkpoint must be reconciled before resuming.
The relay persists a pendingPost before publication. If the external service accepts the message but the process stops before success is recorded, check whether the message exists before retrying: a local database and a social network cannot commit together.
The GitBook publishes no posts. Actually enabling the relay requires separate operational configuration and authorization.
Adapting terminology to fixed walls
The old relay announced FloorRaised events. With the current-time policy, funding can create a wall below the last funded level while preserving older levels.
The relay must therefore name the relevant wall, its level and funds added, without inferring a global increase from the event name alone. Older “the floor always rises” messages do not describe this policy.
Useful operational checks
Track RPC errors, configuration mismatches, pending receipts, simulation failures, keeper gas balance and the age of the last processed block. Keep recovery logs and version identities without private signing data.
Supervision that restarts processes does not replace resolving an ambiguous nonce or a registry change.
Sources: services/keeper/README.md, services/floor-bot/README.md, services/keeper/src/index.ts and services/shared.