Upkeep

A common DeFi upkeep that automatically claims and compounds rewards from liquidity pools or staking protocols at optimal intervals. This maximizes yield by reducing transaction costs and timing inefficiencies.

• Logic: Checks if accrued rewards exceed a gas cost threshold.
• Action: Executes the harvest and reinvestment transactions.
• Example: Compounders on Aave or Uniswap V3 that re-stake accrued interest.

Upkeeps monitor lending positions and trigger liquidation or safety actions when collateral ratios fall below a threshold. This protects both borrowers and the protocol's solvency.

• Logic: Continuously queries oracle prices for collateral assets.
• Action: If a position is undercollateralized, calls the protocol's liquidation function.
• Example: Keepers on MakerDAO or Compound that liquidate vaults/CDPs.

Upkeeps act as relayers in cross-chain architectures, monitoring events on one chain and initiating corresponding actions on another. They are crucial for message-passing bridges and omnichain applications.

• Logic: Listens for a MessageSent event on the source chain.
• Action: Submits a transaction with proof to the destination chain's bridge contract.
• Example: Chainlink's CCIP relies on a decentralized network of upkeeps for cross-chain transaction execution.

Upkeeps enable evolving NFTs and off-chain game logic by periodically or conditionally updating token metadata or on-chain state based on external data.

• Logic: Checks real-world events, time elapsed, or player actions.
• Action: Calls the NFT contract's updateMetadata or game's resolveRound function.
• Example: An NFT that changes appearance based on weather data or a play-to-earn game that finalizes battle outcomes.

Core infrastructure upkeeps are responsible for periodically pushing data from off-chain sources to on-chain oracle contracts. They ensure data freshness and reliability for DeFi price feeds.

• Logic: Fetches aggregated price data from multiple centralized and decentralized exchanges.
• Action: Submits the median price and timestamp to the on-chain aggregator.
• Example: Chainlink Data Feeds are updated by a decentralized network of node operators running upkeeps.

Upkeeps automate portfolio rebalancing for on-chain funds and parameter adjustments for algorithmic protocols based on market conditions or governance votes.

• Logic: Evaluates current asset allocations against target weights or checks governance execution conditions.
• Action: Executes swaps via a DEX or calls an admin function to update protocol parameters (e.g., interest rates).
• Example: An index fund like an ETF on-chain or an algorithmic stablecoin adjusting its collateral ratio.

Upkeeps enable time-based and condition-based automation for smart contracts. This removes the need for users or developers to manually trigger functions, which is critical for protocols requiring regular maintenance.

• Time-based: Execute a function every N blocks or at a specific timestamp (e.g., a weekly rewards distribution).
• Condition-based (Custom Logic): Execute when an on-chain condition is met (e.g., rebalancing a liquidity pool when price deviates).

The upkeep ecosystem relies on a decentralized network of nodes and a central registry.

• Upkeep Registry: A smart contract where tasks are registered, funded, and managed. It tracks the balance and configuration of each upkeep.
• Automation Nodes (Performers): Decentralized nodes that monitor the registry, check upkeep conditions, and execute transactions when needed. They are compensated in native tokens for successful work.

To create an upkeep, a developer must register it on the network and pre-fund it with the native token (e.g., LINK).

• Registration: Defines the target contract, trigger conditions, gas limit, and admin address.
• Pre-funding: The upkeep contract holds a balance used to pay Automation Nodes for execution gas costs and their service premium. The upkeep becomes inactive if the balance is depleted.

Upkeeps are foundational for DeFi, NFTs, and DAO operations.

• DeFi: Auto-compounding yield, liquidating undercollateralized loans, and executing limit orders.
• NFTs: Releasing randomized traits or unlocking content after a specific date.
• DAO Governance: Automatically executing a passed proposal after a timelock expires.
• Data Feeds: Periodically updating an on-chain price oracle with fresh data.

Using a decentralized network for upkeeps mitigates critical risks.

• Censorship Resistance: No single entity can prevent task execution.
• High Uptime: A network of nodes ensures tasks are performed even if some nodes are offline.
• Verified Execution: All performed upkeeps are recorded on-chain, providing transparency and auditability.
• Gas Optimization: Networks can use techniques like gas price hedging to execute tasks cost-effectively.

The registration of an upkeep on a decentralized oracle network like Chainlink is a critical security step. It defines the execution parameters, funding source, and authorized upkeep administrators. A key vulnerability is improper access control, where an attacker could register a malicious upkeep or modify an existing one. Best practices include using multi-signature wallets for administrative actions and regularly auditing the on-chain registration data.

The performUpkeep function typically contains a conditional check (e.g., checkUpkeep) to determine if execution is needed. Security risks include:

• Insufficient gas limits: If the gas limit set during registration is too low, complex upkeep logic may run out of gas and fail, potentially causing protocol insolvency.
• Faulty condition logic: A bug in the condition check can cause the upkeep to be executed when it shouldn't be, or fail to execute when required.
• Gas price spikes: During network congestion, the allocated gas may be insufficient, leading to missed executions.

The performUpkeep function executes the core logic. It must be hardened against common smart contract vulnerabilities:

• Reentrancy attacks: The function should follow the checks-effects-interactions pattern, especially when transferring funds or calling external contracts.
• Input validation: Any parameters decoded or passed into the function must be rigorously validated.
• Access control: The function should verify the caller is the authorized Automation Network to prevent unauthorized execution.
• Error handling: Robust try/catch or error propagation is needed to ensure one failed upkeep doesn't halt others in a batch.

Upkeeps are funded with LINK tokens (or the native token of the automation network) to pay for execution. Key economic risks are:

• Balance depletion: If the upkeep's balance runs out, executions will stop. This requires active monitoring and top-up mechanisms.
• Withdrawal security: Mechanisms to withdraw unused funds must have strict access controls to prevent theft.
• Oracle network incentives: The security model relies on a decentralized network of nodes being economically incentivized to perform work correctly. A lack of sufficient node operators or rewards can impact reliability.

Relying on a single entity or a small, permissioned set of nodes to perform upkeep creates centralization risk. A truly secure automation system should be:

• Decentralized in execution: Multiple independent nodes should be able to compete to perform the upkeep, preventing censorship or manipulation.
• Transparent and verifiable: All upkeep performances and condition checks should be verifiable on-chain.
• Node operator diversity: The network should be operated by a geographically and jurisdictionally diverse set of entities to reduce systemic risk.

Proactive monitoring is essential for upkeep security. This involves:

• Balance alerts: Monitoring the LINK balance of each upkeep contract to prevent depletion.
• Execution logs: Tracking successful and failed performUpkeep transactions to identify patterns or attacks.
• Condition monitoring: Independently verifying that the off-chain or on-chain conditions for execution are being evaluated correctly.
• Having a manual override: In case of a critical bug or attack, protocols should have a secure, timelocked emergency pause or manual execution function to bypass the automated upkeep.

The specific on-chain event or state that initiates the execution of an Upkeep. This is the "if" statement in the automation logic. Common triggers include:

• Time-based: Executing at a specific timestamp or interval (e.g., every 24 hours).
• State-based: Executing when a on-chain metric reaches a threshold (e.g., price deviation).
• Event-based: Executing in response to a specific emitted log.

The calldata executed on the target smart contract when an Upkeep condition is met. It is generated by the Keeper Network after verifying the conditional trigger. This data encodes the specific function call and arguments needed to carry out the automated task, such as calling a performUpkeep function on a yield harvesting vault.

A smart contract designed to work with an external Keeper Network. It must implement specific interfaces, such as the KeeperCompatibleInterface for Chainlink Automation, which includes two key functions:

• checkUpkeep: Returns a boolean if the conditional trigger is met and the perform data.
• performUpkeep: Executes the logic using the provided perform data. This pattern separates condition checking from execution for gas efficiency.