> 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/vaults/morpho.md). # Morpho How KPK curates its Morpho v2 vaults, covering the Markets V1 Adapter, withdrawal liquidity and forceDeallocate, custody and encumbrance, agents, 3/7/14-day timelocks, and Security Council roles.
Cover imageCover image (dark)
KPK USDC Prime CoreEthereumMorpho_USDC_Prime_L.pngUSDC Prime CoreMorpho_USDC_Prime_D.png
KPK USDC PrimeEthereumMorpho_USDC_Prime_L.pngUSDC PrimeMorpho_USDC_Prime_D.png
KPK USDT PrimeEthereumMorpho_USDT_Prime_L.pngUSDT PrimeMorpho_USDT_Prime_D.png
KPK ETH PrimeEthereumMorpho_ETH_Prime_L.pngETH PrimeMorpho_ETH_Prime_D.png
KPK USDC YieldEthereumMorpho_USDC_Yield_L.pngUSDC YieldMorpho_USDC_Yield_D.png
KPK USDC Yield RWAEthereumMorpho_USDC_Yield_L.pngUSDC Yield RWAMorpho_USDC_Yield_D.png
KPK ETH YieldEthereumMorpho_ETH_Yield_L.pngETH YieldMorpho_ETH_Yield_D.png
KPK wARS YieldEthereumMorpho_wARS_Yield_L.pngwARS YieldMorpho_wARS_Yield_D.png
KPK wARS YieldArcMorpho_wARS_Yield_L.pngwARS Yield
KPK USDC YieldBaseMorpho_USDC_Yield_L.pngUSDC YieldMorpho_USDC_Yield_D.png
KPK EURe YieldArbitrumKPK-shader-light.pngEURe YieldKPK-shader-dark.png
### Protocol overview [Morpho](https://morpho.org/) is a lending environment enabling ERC-4626 vaults that accept a single deposit asset and allocate it across underlying isolated lending markets. Depositors supply liquidity and earn lending yield; curators decide allocation eligibility and set safeguards. {% hint style="success" %} **Live metrics:** Track TVL, borrow APY, supply APY, utilisation and more for KPK Morpho vaults on Dune: {% endhint %} {% hint style="info" %} **Vault architecture:** KPK curation runs on **Morpho v2 vaults**, which allocate directly into Morpho v1 markets via the [**Markets V1 Adapter**](https://docs.morpho.org/get-started/resources/contracts/morpho-market-v1-adapter-v2#morphomarketv1adapterv2). The v2 layer adds function-specific timelocks and supports MORPHO rewards. See [Vault Architecture](#vault-architecture). {% endhint %} ### Curator model Morpho uses a curator model: curators decide which lending markets a vault can allocate to and set safeguards. KPK acts as curator for selected Morpho vaults, defining safe operating conditions, selecting eligible markets, and reallocating liquidity when needed.\ \ **KPK’s curation focuses on three areas:** market selection, operational scalability through automation, and bespoke market deployments (where needed). All decisions follow the [Risk Framework](/vaults/infrastructure/risk-framework.md), which governs eligibility criteria, risk-tiering, and monitoring cadence.
1. **Market selection and withdrawal reliability**\ KPK sets market eligibility, exposure limits, and liquidity buffers. Only markets that pass [due diligence](/vaults/infrastructure/risk-framework.md) are enabled. Each approved market receives a **risk tier** and a **per-market supply cap** to limit concentration. Vaults maintain idle buffers designed to support smooth withdrawals. 2. **Real-time automation (agents) and monitoring**\ Vaults are monitored continuously by agents operated by KPK. They are deterministic programs that execute **whitelisted functions** through KPK’s [Permissions Layer](https://kpk.io/blog/permissions-layer). Agents monitor utilisation, liquidity depth, APY shifts, oracle health, and price divergence versus reference venues. When conditions change, they can reduce or disable exposure to a market, increase idle funds, or rebalance across enabled markets within predefined limits. * **Rebalancing agent:** improves capital efficiency by reallocating across approved markets using a rules-based approach (e.g. tier- and cap-aware water-filling), subject to liquidity and safety checks. * **Exit agent:** responds to risk alerts (e.g. oracle staleness or divergence) within seconds by reducing or disabling exposure, increasing withdrawable liquidity, and prioritising safe exits within predefined limits.\ \ This combination delivers fast incident response and steady, rules-driven allocation. For the technical design and allowed actions, see [Automation](/vaults/infrastructure/automation.md). 3. **Custom market deployments**\ Where needed, KPK works with counterparties (e.g. asset issuers or interested borrowers) to deploy bespoke markets and terms under the same risk framework. ### Vault architecture KPK curation is delivered on **Morpho v2 vaults**, which sit at the top of the stack and route deposits into individual Morpho v1 markets through a single configured adapter: * **v2 vaults** are the canonical, curated product. Each holds depositor assets, enforces function-specific timelocks, supports MORPHO rewards, and exposes one or more **adapters** that define which allocation targets the vault can use. * **Markets V1 Adapter** is the adapter currently configured on every KPK v2 vault. It allocates **directly into individual Morpho v1 markets**, the venues where the underlying lending liquidity is held. There is no intermediate v1 MetaMorpho vault in the path: the v2 vault holds positions in v1 markets directly. * **v1 (MetaMorpho) vaults** were the legacy curated layer, wound down in May 2026. They are no longer curated; new deposits go to the v2 vaults.
How a KPK Morpho vault works: a depositor deposits into and withdraws from the KPK vault, a Morpho v2 vault with a Markets V1 Adapter; the vault allocates to Morpho v1 markets, which return interest and withdrawal liquidity; the KPK Curator Safe (2/5, curator and allocator) sets caps and markets under timelock and reallocates; KPK's rebalancing, exit and monitoring agents act through the Curator Safe with scoped calls only; the KPK Security Council (5/8) owns the vault and, as sentinel, can veto pending changes.

How a KPK Morpho vault works.

{% hint style="info" %} **Why this design:** v2 separates curation policy from allocation venue. Timelocks, role hierarchy, and reward routing live at the v2 layer; the Markets V1 Adapter is one allocation venue and can be replaced or supplemented by v2-native adapters in the future without touching depositor positions or vault governance. {% endhint %} ### Liquidity and `forceDeallocate` Withdrawals on Morpho v2 vaults are served first from the vault's idle balance, then from the **liquidity adapter**, a per-vault setting that designates a **single market** as the withdrawal venue. The liquidity adapter is configured on top of the Markets V1 Adapter and points at one of the v1 markets the adapter holds positions in. Withdrawals beyond idle pull from that one market until either the request is filled or that market's available liquidity is exhausted. This is a structural difference from the previous Vault V1 Adapter setup, where the v2 vault sat above a v1 MetaMorpho vault that could draw from any of its enabled markets in a single transaction. With the Markets V1 Adapter, KPK selects which market backs withdrawals at any given time; the design favours allocator control over default withdrawal breadth. KPK aims to keep the liquidity adapter pointed at the market with the largest combination of vault exposure and underlying available liquidity, and is building monitoring to support more dynamic rotation. `forceDeallocate` covers the remaining case: a withdrawal large enough to exhaust both idle and the liquidity adapter. In practice, only very large exits reach this path. A depositor can call `forceDeallocate` on the v2 vault to pull liquidity from any other market in the adapter back to idle; Morpho's frontend uses it automatically, stitching a single-transaction withdrawal across the full set of listed markets. The call burns vault shares worth a fixed fraction of the amount deallocated, the **`forceDeallocate` penalty**, set per-adapter; the burned value remains in the vault and accrues to remaining depositors. KPK's standard value is **0.01%**. The penalty applies only to forced deallocations: withdrawals served from idle or the liquidity adapter incur no fee, and a large exit can be split into smaller withdrawals served through the normal path, as the rebalancing agent replenishes the liquidity adapter between withdrawals. The **liquidity target** on each vault page is the share of assets a depositor can withdraw straight away, counting idle, the liquidity adapter and what `forceDeallocate` can reach in the other markets. A depositor planning a large withdrawal can also ask KPK to move more liquidity into idle or the liquidity adapter beforehand. The non-zero penalty is a deliberate curation choice. Because the penalty is charged against the caller's own shares (or shares of an address that has approved the caller), a non-zero value is restricted `forceDeallocate` to vault depositors and contracts acting with their approval. At the protocol default of zero, the call is fully permissionless and third parties can rearrange a vault's allocations at no cost. KPK's monitoring agent tracks deallocation activity; upon detecting a pattern of fragmented allocations against the curator's policy, it raises the penalty to **0.5%** and triggers an immediate rebalance to restore allocations. See [Automation](/vaults/infrastructure/automation.md#monitoring-agent) for details. The penalty in force on each vault is listed on that vault's page. ### Custody and encumbrance Depositor assets in a KPK-curated Morpho vault are held in two places only: the idle balance in the vault contract, and supply positions in Morpho v1 markets held through the vault's single Markets V1 Adapter. Both can be read onchain at any block. * **No custodian.** KPK never holds depositor assets, and no bank, exchange or offchain custodian is involved. * **No encumbrance.** Vault assets are not pledged or lent outside Morpho, and no lien or creditor claim attaches to them, from KPK or anyone else. * **No withdrawal path for KPK.** No KPK role can send vault assets to an address of its choosing. Curator and allocator roles only move assets between enabled markets and the idle balance. A new allocation venue needs `addAdapter`, which accepts only adapters in Morpho's adapter registry and runs behind a 3-day timelock that the sentinel can revoke. Fees are the only way value can reach KPK, and each vault's fee is listed on its page. * **Borrower collateral.** Collateral posted by borrowers sits in the Morpho contract, not in the vault. It moves only when the borrower withdraws it or a liquidator seizes it, and it is not reused. Depositors have no direct claim on borrowers or collateral issuers; recovery runs through Morpho liquidation. * **Segregation.** Each vault is a separate ERC-4626 contract with its own adapter, Curator Safe and Permissions Layer configuration. Assets are never pooled across vaults. * **Withdrawals cannot be gated.** The setters for the share-transfer and asset-receipt gates, and for the adapter registry, are permanently abdicated, so no owner or curator can ever restrict withdrawals. Deposit gating remains possible. * **Losses.** Bad debt realised in a market is shared pro rata by all depositors through the share price. There is no insurance and no loss reserve in the vault. KPK keeps its own capital in its vaults and commits it to be the last capital to leave in a bad-debt scenario. KPK Digital Assets, Inc. curates the vaults. Depositors' contractual rights, if any, arise under the Morpho Protocol Terms of Service; see the [Morpho disclaimer](/vaults/resources/legal/morpho-disclaimer.md). No legal opinion on bankruptcy remoteness has been obtained: the structure relies on KPK never holding the assets. The single adapter, the 3-day `addAdapter` timelock and the abdications above were verified onchain on 15 October 2026 for every KPK Morpho vault on Ethereum, Base, Arbitrum and Arc. ### Governance and control Critical actions follow a layered process designed for transparency, security, and timely response. {% tabs %} {% tab title="Governance changes (timelocked)" %} **v2 vault (curated product):** changes that can expand permissions or increase risk (e.g., role updates, enabling a new market, raising allocation ceilings, adding or removing an adapter, or changing risk parameters) execute via KPK multisigs under **function-specific timelocks** (KPK’s 3/7/14-day schedule, detailed under Key settings and roles below). The Guardian can intervene during the timelock window if required. **v1 vaults (legacy):** KPK wound down v1 curation at the end of May 2026. The vaults remain onchain and still hold a small number of depositor positions, but KPK no longer rebalances them or makes governance changes to them. {% endtab %} {% tab title="Operational changes (not timelocked)" %} Operational actions within pre-approved bounds, such as `reallocate()` between enabled markets, increasing the idle buffer, or setting a market cap to zero, execute under scoped roles and are not timelocked, allowing agents to respond within seconds. {% endtab %} {% endtabs %} **Key settings and roles** The following roles and settings apply across all KPK vaults: * **Owner and sentinel:** Security Council Safe (5/8), [`0x8b884f80B3B839F52b6cE168f133e7a5D1f0A537`](https://app.safe.global/transactions/history?safe=eth:0x8b884f80B3B839F52b6cE168f133e7a5D1f0A537). The same address on Ethereum, Arbitrum, Base and Arc. The exception is the legacy v1 vaults, which KPK no longer manages: they are still owned by KPK's previous Security Council Safe, `0x354C92aF243d53A24feb3dFF20372Af7b7c47478` * **Curator and allocator:** Curator Safe, with a Permissions Layer for agents (2/5). As well as the KPK Deployer 1 (`0xF0Cf1e3Ec6264b03241826f5b2aBda17B4352A75`), KPK Deployer 2 (`0x331D9C769185AE25233314859d53c2b9203a1204`) and KPK Deployer 3 (`0xAF150c6d108D0C2c96BbFc3CeF9B4848b5D99440`) holding Allocator roles for emergency scenarios. Visit each vault page for the specific address. * **Timelocks:** * **3 days:** add adapter; increase absolute or relative cap * **7 days:** remove adapter, update gates, increase timelock * **14 days:** adjust management or performance fees KPK Morpho v2 vaults apply function-specific timelocks to wrapper configuration (adapter, fee, and risk-parameter changes), and are controlled by the same KPK Safes that governed the corresponding legacy v1 vaults. For detailed configuration, see [Morpho v2 Roles and Timelocks](https://docs.morpho.org/curate/concepts/roles/#morpho-vaults-v2-roles), the [Changelog page](https://docs.kpk.io/changelog), and the individual vault pages. For protocol-level context on Morpho v2 versus v1, see Morpho [documentation](https://docs.morpho.org/learn/concepts/vault-v2/#key-feature-comparison-morpho-vaults-v1-vs-morpho-vaults-v2). {% hint style="info" %} **Allocator usage:** KPK does not use Morpho's public Allocator role, reducing the attack surface. Automation is instead scoped through KPK’s Permissions Layer and Morpho’s roles system. {% endhint %} ### Vault configuration Enabled markets, caps, risk tiers, oracles, allocation rules, and governance addresses are documented on each vault page and kept up to date in the [Changelog page](https://docs.kpk.io/changelog). --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.kpk.io/vaults/vaults/morpho.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.