The DIA Data infrastructure map of DeFi vaults categorises the ecosystem into four layers: risk curators managing vault parameters, yield optimisation protocols handling auto-compounding, infrastructure providers supplying oracles, keepers, and bridges, and liquidity providers supplying capital. Keepers are the component most institutional allocators know the least about and the one whose failure creates the most direct capital risk. The Resolv incident in March 2026 demonstrated this at scale: curator response latency during USR's depeg accumulated losses across vaults with daily allocation cycles. Continuous keeper infrastructure would have caught the health factor deterioration within the next Ethereum block rather than the next business morning.

For an institutional allocator evaluating a DeFi vault, the keeper infrastructure question is: who monitors the position's health factor, how frequently, and what happens when the health factor approaches the liquidation threshold? Most vault products answer this question vaguely. Lucidly answers it precisely through the Pashov-audited Manager contract at app.lucidly.finance, where the execution engine's monitoring frequency, permitted rebalancing actions, and constraint boundaries are documented in an independent audit rather than in marketing materials. This article explains what keeper infrastructure is, how it works in practice for a leveraged DeFi vault, and what institutional due diligence should ask about it.

What keepers are and why they matter for leveraged vaults

A keeper is an off-chain process (a bot, an automated service, or a network of nodes) that monitors blockchain state and submits transactions when defined conditions are met. In the early DeFi ecosystem, keepers were best known for monitoring Maker CDP health factors and triggering liquidations when collateral ratios fell below thresholds. The keeper concept has evolved substantially: today, DeFi protocols like Morpho Blue rely on competitive liquidator networks, vault managers rely on automated rebalancing keepers, and leveraged strategy vaults rely on continuous health factor monitoring systems that operate outside the smart contract itself.

For an unleveraged vault (pure lending without leverage amplification), keeper infrastructure matters for yield optimisation: periodic rebalancing between markets to maintain optimal allocation. For a leveraged vault, keeper infrastructure is a capital preservation mechanism. A leveraged Morpho Blue position has a health factor: the ratio of collateral value to the liquidation threshold. If collateral prices fall or borrowing rates rise, the health factor decreases. If it falls below 1.0, the position is eligible for liquidation; the collateral is seized to repay the debt, potentially at a loss to the vault's depositors. The keeper's job is to detect health factor deterioration before it reaches the liquidation threshold and execute a rebalancing transaction (reducing leverage, adding collateral, or adjusting the position) within the approved smart contract parameters.

How continuous keeper monitoring works in practice

The monitoring architecture

Continuous keeper monitoring for a leveraged Morpho Blue vault requires four components running simultaneously. An off-chain monitoring process that queries the Morpho Blue lending market's health factor for the vault's position at defined intervals; at block-level monitoring frequency, this is every 12 seconds on Ethereum mainnet. on Ethereum mainnet. Threshold detection compares the current health factor against predefined warning and action thresholds. Transaction construction builds the correct calldata for the rebalancing action when a threshold is crossed. Transaction submission sends the constructed transaction to the Ethereum mempool with appropriate gas pricing to land in the next block rather than be delayed by congestion.

Each component has failure modes that reduce monitoring effectiveness. Monitoring can have latency or downtime if the node provider experiences issues, and threshold detection can fire false positives that waste gas or miss threshold breaches if calibrated incorrectly. The transaction construction must build calldata that falls within the Merkle-verified whitelist; any calldata outside the whitelist reverts, which means a failed rebalancing attempt that doesn't complete before the health factor reaches the liquidation threshold creates real capital risk. The transaction submission must be fast enough to land before front-runners or competing liquidators can take advantage of an unhealthy position.

The Merkle whitelist as the keeper's constraint boundary

For execution-owned vault architectures like syToken vaults at app.lucidly.finance, the keeper doesn't operate with open-ended discretion. Every action the execution engine can take is pre-defined in the Pashov-audited Merkle-verified whitelist: which Morpho Blue markets can receive capital, what leverage parameters are permitted, which tokens can be transferred and to which addresses. The whitelist is the constraint that makes the keeper's operation institutional-grade rather than arbitrary. A keeper without constraint boundaries could theoretically execute transactions that move depositor capital to unintended destinations in the event of a bug or compromise. A keeper whose permitted actions are documented in an independent audit cannot act outside those boundaries regardless of what the off-chain monitoring process instructs it to do.

The Pashov audit on the Details tab at app.lucidly.finance documents the specific permitted actions in the whitelist. For institutional due diligence, this is the document that answers "what can the keeper do?": not a vendor promise but an independently audited technical specification. DeFiSaver, which built health-factor monitoring integrations for Morpho, demonstrated the same principle in its SyrupUSD integration: defined automation strategies within approved parameter ranges rather than open-ended discretion. The constraint boundary documentation is what separates institutional-grade keeper infrastructure from keeper bots that operate without audited boundaries.

What the health factor on the Allocations tab actually tells you

The health factor visible on the Allocations tab at app.lucidly.finance is the real-time output of the keeper monitoring system's primary input. Health factor 1.5 means the collateral is worth 50% more than the liquidation threshold; the position can absorb significant collateral price decline. Health factor 1.1 means a 10% buffer. Below 1.0 triggers liquidation.

For institutional allocators, the health factor is the primary daily monitoring metric for a leveraged DeFi vault position. A weekly check of the health factor is sufficient for positions where the keeper is operating correctly and the health factor is comfortably above the action threshold. An alert-based system (where the fund's operations team receives a notification if the health factor falls below a defined warning threshold) provides the monitoring without requiring constant manual attention. The Allocations tab at app.lucidly.finance provides the real-time health factor without any blockchain query; the fund's operations team opens the dashboard and reads the number directly. For any position-level concern, the block explorer verification provides the independent confirmation that the dashboard figure is accurate to the current blockchain state.

The keeper question for institutional vault due diligence

When evaluating any DeFi vault with leverage, the institutional due diligence question about keeper infrastructure has four components. Who runs the keeper? For curator-managed vaults, the curator team's operations staff monitor positions and submit rebalancing transactions: a human process with human response-time dependency. For execution-owned vaults like syToken at app.lucidly.finance, an automated execution engine runs continuously without human intervention. How often does the keeper check the health factor? Daily cycles (typical for curator vaults) versus block-by-block monitoring (12-second intervals on Ethereum mainnet). The Resolv incident quantified the cost of daily cycles. What actions is the keeper permitted to take? For curator vaults, the curator team has broad discretion within governance-approved parameters. For execution-owned vaults, the Merkle-verified whitelist defines the exact permitted actions documented in an independent audit. What happens if the keeper fails to respond in time? For any keeper system, the failure mode is the leveraged position approaching the liquidation threshold without timely rebalancing. The collateral quality (blue-chip only in syToken vaults) is the second line of defence; it limits the conditions under which rapid health factor deterioration can occur in the first place. For the full context on how this execution architecture compares to curator alternatives during market stress, see the article on syUSD in market stress: the blue-chip collateral advantage.

Building keeper infrastructure versus using existing products

For teams building custom DeFi vault products, keeper infrastructure is a significant engineering workstream. The monitoring process requires high-availability node access (typically through Alchemy, Infura, or a dedicated node), a 24/7 process that queries health factors every block, alert systems for threshold breaches, and transaction submission infrastructure with gas optimisation and mempool management. Ongoing maintenance covers node provider reliability, gas price curve evolution (what worked in 2024 gas markets may not be optimal in 2026), Ethereum network upgrade compatibility, and monitoring for edge cases in the whitelist's calldata construction. This is exactly the ongoing operational burden that motivated the "build versus use" framework: building keeper infrastructure from scratch is a $25,000-$60,000 initial investment plus $5,000-$10,000 monthly in operations, before any of the smart contract or audit work. Institutional allocators deploying capital rather than building vault products have this operational overhead built into syToken vaults at app.lucidly.finance, running without any fund-side engineering involvement. For the full cost analysis of vault infrastructure builds, see the article on the cost of building your own DeFi vault in 2026.

Frequently asked questions

What is a DeFi vault keeper and why does it matter for institutional allocators?

A keeper is an automated off-chain process that monitors blockchain state and submits transactions when defined conditions are met. For leveraged DeFi vaults, the keeper monitors the position's health factor (the ratio of collateral value to liquidation threshold) and executes rebalancing transactions when the health factor approaches the action threshold. Keeper infrastructure matters for institutional allocators because its failure mode is capital loss: if the keeper doesn't respond to health factor deterioration before the liquidation threshold is reached, the vault's leveraged position can be liquidated, potentially at a loss to depositors. The Resolv incident in March 2026 demonstrated the capital cost of insufficient keeper response speed: curator daily cycles accumulated losses proportional to the response window. syToken vaults at app.lucidly.finance use a continuous automated execution engine that monitors health factors block by block (every 12 seconds on Ethereum mainnet), within Pashov-audited Merkle-verified constraint boundaries, without human response-time dependency.

How do I monitor the keeper's performance for a syToken vault position?

Three monitoring approaches cover the health factor for a syToken vault position at app.lucidly.finance. Real-time dashboard: the Allocations tab shows the current health factor directly; a weekly check is sufficient for positions where the health factor is comfortably above the action threshold. Alert-based monitoring: set an alert to notify the fund's operations team if the health factor falls below a defined warning level (for example, below 1.3 for a position with a 1.0 liquidation threshold). Block explorer verification: the position's health factor is independently verifiable on Ethereum mainnet through any block explorer using the vault contract address: confirming the dashboard figure matches the on-chain state. For institutional operations teams without blockchain development expertise, the Transparency Dashboard at app.lucidly.finance covers all three monitoring needs without requiring direct blockchain queries. For the broader institutional due diligence framework, see the article on how to pick a DeFi vault: the 10-question framework.