> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/vaults/infrastructure/automation.md). # Automation At scale, continuous, real-time curation cannot rely solely on manual intervention. KPK uses deterministic agents to support curation. These agents operate within tightly defined permissions and do not exercise discretion. Their role is to execute predefined actions when specific conditions are met. Automation is deliberately limited. Agents can act quickly, but only within clearly defined bounds. They cannot introduce new strategies, expand exposure beyond approved limits, or bypass risk constraints. ### Process Every KPK agent follows the same shape: it monitors onchain conditions, is triggered by a [Hypernative](https://www.hypernative.io/) alert, and autonomously executes a transaction within predefined bounds, as per our [permissions policy](https://docs.kpk.io/vaults/infrastructure/automation#policies). What that action is depends on the agent. The rebalance agent, for example, runs the most involved loop: 1. It continuously monitors onchain conditions and is triggered by a Hypernative alert 2. It fetches all relevant data for all markets 3. It estimates projected market APYs or market utilisations for all feasible allocations 4. It calculates the optimal new allocation across markets within predefined risk boundaries that maximises vault APY or minimises exposure 5. If there's a sufficiently high marginal increase, or a decrease in risk (according to a predefined parameter), it builds the transactions and executes them onchain The exit and replenishment agents follow the same monitor-and-act shape but skip the optimisation steps: the exit agent drains a market on a risk alert, and the replenishment agent tops up agent gas balances.
KPK rebalancing agent loop: monitor onchain conditions, fetch market data, compute optimal allocation within risk bounds, build and execute the transaction onchain
Each agent operates through an externally owned account (EOA) that is unique per vault and whitelisted in the Curator Safe's Roles Modifier for a narrow set of functions, targets, and parameter values. Every transaction an agent builds is checked against that allow-list onchain before the Safe will act on it, and reverts if it falls outside. The private keys are generated and stored in a dedicated ETH signer vault, with no human access to the keys. See [Signer architecture](/vaults/infrastructure/signer-architecture.md) for the full permission model. To ensure these EOAs always have sufficient gas to cover transactions, a script monitors their ETH balance and automatically tops them up. ### Policies Policies define the set of onchain permissions that the Curator Safe delegates to agents. Because the Curator role itself operates under strict permissions and timelocks at the vault level, the permissions it can delegate to agents are narrow in scope — ensuring that no single agent represents a critical point of failure. In the event an agent is compromised or acts outside its intended behavior, the blast radius is contained by design. For example, a Shutdown Agent can only set market caps to zero. Should such an agent be compromised, the Curator can promptly restore the caps and revoke the agent's permissions — resulting in funds remaining idle for only a brief window before normal operations resume. For a detailed breakdown of how permissions are configured, refer to the [permissions article](https://kpk.io/blog/permissions-layer). ### Agents Vault agents monitor borrow utilisation, APY shifts, price divergence relative to reference venues, oracle liveness, and liquidity depth to keep allocations within risk limits and support competitive yields.
AgentTriggerAction
RebalanceAPY shifts, deposits, withdrawals, or utilisation changesReallocates across approved markets to improve yield, within tier and cap limits
ExitRisk alerts (oracle staleness, liquidity stress, a collateral pause, price divergence)De-risks a market: soft shutdown (drains, caps untouched, reversible) or hard shutdown (caps to 0, drains, permanent)
ReplenishAn agent EOA's ETH balance falls below its minimumTops the EOA back up so it can keep paying gas
MonitoringAbnormal forceDeallocate activity detected (griefing)Sets forceDeallocateFee to 0.5% (default is 0.01%) to deter further abuse, and triggers an immediate rebalance to restore allocations
#### Rebalance agent The **rebalancing agent** improves capital efficiency in normal conditions, allocating and rebalancing across approved markets using tier- and cap-aware rules, subject to safety checks. It has only the permission to call the reallocate function on the vault contract.
Example: rebalance on deposit (USDC Yield, Arbitrum) **Trigger event**: On [3 February 2026 at 09:42:56 UTC](https://arbiscan.io/tx/0x05484ef801ffb22dc441ac0a278f283de5b0f3a24a07ed8c9ba07a17fe2ffe70), a large deposit is made into the KPK USDC Yield vault on Arbitrum. **Process**: The agent checks the vault's total assets and runs an algorithm to determine the optimal allocation for each market, based on the parameters the curation team sets per market, for example, a maximum allocation per market (from the risk team's due diligence) and a minimum withdrawable fraction per market (which ensures liquidity). **Output**: On [3 February 2026 at 09:43:25 UTC](https://arbiscan.io/tx/0xe99cb5ee8e176d3eb534a911e67e09a0797bf6bff53a56c841488a063c736ee1), the agent rebalanced the vault's allocations after identifying a higher yield, built the transaction, and executed it with the ETH signer. The curation team is notified that a rebalance has taken place.
#### Exit agent The **exit agent** is triggered by risk alerts such as oracle staleness, liquidity stress, a collateral pause, or severe price divergence. It reduces or disables a market's exposure, drains the liquidity into the vault's idle buffer, and prioritises safe exits. Exit agents are a family of responses graded to the severity and reversibility of the alert. {% columns %} {% column %} **Soft shutdown** applies to softer signals that may prove to be false positives, such as a precautionary pause on a collateral asset. The agent stops the vault allocating to the affected market and drains its current exposure, while leaving the market's onchain caps untouched. Because the caps are never changed, re-enabling the market does not require a time-locked governance transaction: once the team confirms the signal was benign, the curation team restores the market, and the vault resumes allocating within minutes. Only the affected market is de-risked, so the rest of the vault continues to earn. {% endcolumn %} {% column %} **Hard shutdown** applies to confirmed or terminal risk, and to the permanent offboarding of a market. The agent zeroes the market's onchain caps so the vault can no longer allocate to it, then drains the position out. Setting a cap to zero is not timelocked, so the exit is immediate; re-enabling the market is a governance-class change that runs through the Curator Safe timelock and takes 72 hours. {% endcolumn %} {% endcolumns %} In both cases, the agent only reduces exposure. Exit agents are most developed on KPK's Morpho Vaults and also run on KPK's Euler Vaults.
Example: soft shutdown (USDC Yield, Cap pause) **Trigger event**: On 9 June 2026 at 22:23 UTC, Cap [paused its cUSD stablecoin](https://etherscan.io/tx/0x9d7eee1581865a470bc9d6aecd877bea0440afcfe81cb79149dcb26dad222945). A Hypernative alert and a PagerDuty page reached the risk curation team within seconds. **Process**: A soft shutdown was triggered across the markets with exposure to Cap (stcUSD, DUSD, and srRoyUSDC). The exit agent stopped the vault allocating to those markets and drained the available liquidity back to idle, with the [first deallocation](https://etherscan.io/tx/0x5c15f1ea3873bd1d74f74fb1251568a701edee4b5fee56dd401b4c3ebfb0c828) executing around 15 seconds after the alert. Where a market's liquidity was partly committed to borrowers, the agent withdrew what was available, and the rest followed as borrowers repaid. The onchain caps were left untouched throughout. **Output**: Around 5 minutes after the pause, Cap confirmed it was a false positive triggered by MEV activity, and unpaused roughly 20 minutes after the original pause. Because no onchain caps had been changed, the markets were re-enabled after human review, and the vault resumed allocating without a curator unpause.
Example: hard shutdown (ETH Prime, market delisting) **Trigger event**: On 10 February 2026, the curation team wanted to delist a collateral market on the ETH Prime vault on mainnet. **Process**: The vault held 13.03 WETH in the market, against \~22 WETH in available liquidity, so the full position could be withdrawn in a single move. The exit agent set the market's supply cap to 0, which stops any new allocation, then withdrew the entire 13.03 WETH position to idle. **Output**: On [10 February 2026 at 10:18:35 UTC](https://etherscan.io/tx/0x79981b9fc9a003414f27ab36d8adf22f95449adc5c8a692fb9ad2933598d9789), the agent successfully executed. The supply cap was reduced from 1b to 0. The curation team has been notified that an exit action has occurred.
#### Replenish agent The **replenishment agent** ensures that every agent EOA always has enough ETH to operate. It monitors a list of registered accounts and tops them up whenever a balance drops below its threshold: * Rebalance agents require a minimum of 0.01 ETH and are topped up to 0.03 ETH * Exit agents require a minimum of 0.05 ETH and are topped up to 0.05 ETH
Example: gas top-up (USDC Yield rebalancing agent) **Trigger event**: On 4 May 2026, the agent ran its routine check of the ETH balance on every agent EOA. **Process**: The [USDC Yield rebalancing agent](https://etherscan.io/address/0x7a35f5dcd3faa4bd617b7d7c3cc9b9ea6353291f) had fallen below its 0.01 ETH minimum, so it was queued for a top-up to the 0.03 ETH target. **Output**: On [4 May 2026 at 16:00:47 UTC](https://etherscan.io/tx/0xabee740b3cfb4b6ae13d9c98ea08f4a92184b61904f40a51c17ab7b4be8c2dab), the agent sent 0.03 ETH to the USDC Yield rebalancing agent, restoring it to the operating balance.
#### Monitoring agent The **monitoring agent** detects griefing attacks against the vault and automatically sets the `forceDeallocateFee` to 0.5% (the default is 0.01%) to deter repeated abuse of the `forceDeallocate` function. It also triggers an immediate rebalance, so allocations disrupted by the attack are restored without waiting for the next scheduled cycle.
Example: forceDeallocate griefing campaign (Jun 2026) **Trigger event**: On 21 June 2026, an external actor ran an ecosystem-wide `forceDeallocate` griefing campaign — 58 calls across 26 Morpho V2 vaults. KPK vaults were a subset of the targets. Each call temporarily routed allocated liquidity back to idle, disrupting active allocations until the next rebalancing cycle (\~15 minutes). **Process**: The monitoring agent detected the abnormal volume of `forceDeallocate` calls onchain and identified the attack pattern. **Output**: The agent [raised the `forceDeallocateFee` from 0% to 0.5%](https://etherscan.io/tx/0x6601b8ffa2a8b6b302f45f3f30e999fcdc3920579e041e4990c0d1b46579ef4b#eventlog) on the USDC Yield vault, making further griefing economically prohibitive. The curation team was notified of the intervention.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kpk.io/vaults/infrastructure/automation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.