Morpho

This page covers the Morpho-specific nuances of integrating KPK vaults: the Morpho SDK, direct contract calls, and the Morpho Fee Wrapper. For the general integrator overview and audience-routing, start at the Integration page.

End-users who simply want to deposit should use the Morpho UI directly. Vault addresses, supported assets, and current parameters are listed on each vault page.

Where deposits end up: KPK Morpho v2 vaults route deposits through the Markets V1 Adapter directly into individual Morpho v1 markets. Integrators tracing the flow of funds should follow the adapter address listed on each vault page (under Key information) to see the markets the v2 vault is currently allocated to.

Integrating via the Morpho SDK

The Morpho SDK handles contract interactions, approvals, slippage protection, and transaction construction. It returns ready-to-send transaction objects so the integrator focuses on UX, not low-level encoding.

1. Install and instantiate

npm install @morpho-org/morpho-sdk

import { MorphoClient } from "@morpho-org/morpho-sdk";
import { mainnet } from "viem/chains";

const morpho = new MorphoClient(walletClient, {
  supportSignature: true,
  supportDeployless: false,
});

// KPK USDC Prime on Ethereum
const vault = morpho.vaultV2(
  "0x4Ef53d2cAa51C447fdFEEedee8F07FD1962C9ee6",
  mainnet.id,
);

All KPK vaults are ERC-4626 compliant and built on Morpho v2. Vault addresses live on each vault page; for example:

Vault	Chain	Address
KPK USDC Prime	Ethereum	0x4Ef53d2cAa51C447fdFEEedee8F07FD1962C9ee6
KPK USDC Yield	Ethereum	0xD5cCe260E7a755DDf0Fb9cdF06443d593AaeaA13
KPK ETH Prime	Ethereum	0xBb50A5341368751024ddf33385BA8cf61fE65FF9
KPK USDC Yield	Arbitrum	0x5837e4189819637853a357aF36650902347F5e73

For the full list, see the Morpho vault directory.

2. Read vault and position data

vault.getData() returns the onchain state needed to display APY, total assets, and convert between shares and assets.

const accrualVault = await vault.getData();

// accrualVault.totalAssets        → total assets in the vault
// accrualVault.toAssets(shares)   → convert user shares to asset amount
// accrualVault.toShares(assets)   → convert asset amount to shares

For APY and reward-rate data, query Morpho's offchain API alongside the onchain state. See the Morpho API reference for endpoints.

3. Deposit flow

The SDK uses a two-step pattern: first resolve what's needed (approvals or permit signatures), then build the final transaction.

import { parseUnits } from "viem";

const { buildTx, getRequirements } = vault.deposit({
  amount: parseUnits("1000", 6), // 1,000 USDC
  userAddress: USER_ADDRESS,
  accrualVault,
});

const requirements = await getRequirements();
// requirements: (ERC20Approval | Permit | Permit2)[]
// Surface each requirement to the user, collect signatures or send approval txs.

const tx = buildTx(/* signed requirement, if any */);
await walletClient.sendTransaction(tx);

Slippage protection is applied automatically: the SDK enforces a maxSharePrice ceiling to guard against ERC-4626 inflation attacks.

4. Withdrawal flow

// Withdraw a specific asset amount
const { buildTx: buildWithdrawTx } = vault.withdraw({
  amount: parseUnits("500", 6), // 500 USDC
  userAddress: USER_ADDRESS,
});
await walletClient.sendTransaction(buildWithdrawTx());

// Or redeem a specific share amount
const { buildTx: buildRedeemTx } = vault.redeem({
  shares: sharesToRedeem,
  userAddress: USER_ADDRESS,
});
await walletClient.sendTransaction(buildRedeemTx());

Withdrawals beyond the vault's idle buffer are routed through the configured liquidity adapter into the underlying Morpho v1 markets. If neither idle nor the liquidity adapter can cover the withdrawal, the SDK can construct a forceDeallocate call to pull liquidity from a specific market; see Liquidity and forceDeallocate for details.

5. Rewards

Some vaults receive MORPHO incentives or other reward campaigns distributed via Merkl. Query the Merkl API by user address to fetch claimable amounts:

const res = await fetch(
  `https://api.merkl.xyz/v3/userRewards?user=${userAddress}`,
);
const rewards = await res.json();

The claim is a separate transaction and does not modify the user's deposited position.

Direct contract integration

For custodians, CEXs, and onchain protocols that prefer raw contract calls without a JavaScript SDK, KPK vaults expose the standard ERC-4626 interface. The flows below use KPK USDC Prime on Ethereum (0x4Ef53d2cAa51C447fdFEEedee8F07FD1962C9ee6) as the example; substitute the vault address for the asset and chain you need from the vault directory.

For the canonical Morpho bundler and adapter contract addresses across chains, see the Morpho contract addresses page. Addresses change occasionally; always cross-reference before integrating.

Deposit

The simplest deposit path is a direct ERC-4626 call:

1

Approve the vault to spend USDC.

Call approve(spender, amount) on USDC (0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48):

• spender = the KPK vault address
• amount = the deposit amount, in token units

2

Deposit into the vault.

Call deposit(assets, receiver) on the KPK vault:

• assets = the deposit amount
• receiver = the address that should receive the vault shares (typically the depositor)

For multi-step flows that batch approval and deposit in a single transaction (e.g. via Permit2), use Morpho's Bundler3. The Bundler3 and General Adapter contract addresses are listed on the Morpho addresses page; the Morpho UI builds the calldata for you.

Withdraw

1

Withdraw a specific asset amount.

Call withdraw(assets, receiver, owner) on the KPK vault:

• assets = the asset amount to withdraw
• receiver = the address that should receive the underlying asset
• owner = the address whose shares should be burned (the depositor, or any address that has approved the caller)

Or by share amount:

1

Redeem a specific share amount.

Call redeem(shares, receiver, owner) on the KPK vault:

• shares = the share amount to redeem
• receiver, owner = same as above

Claim rewards

Merkl-distributed reward tokens are claimed via the Merkl distributor:

• Call claim(users, tokens, amounts, proofs) on the Merkl distributor, with the values returned by the Merkl API for the depositor's address.

Fee wrapper for distribution partners

Distribution partners can request KPK to deploy a Morpho Fee Wrapper on top of a curated vault. This lets the partner charge their users a fee on the underlying KPK strategy without changing the vault itself. Wrapper deployment is a free service on KPK's side.

A fee wrapper is a fully ERC-4626 compliant vault that sits on top of the underlying KPK vault. Users deposit into the wrapper, which deposits 1:1 into the selected KPK vault. Yield accrues automatically through share appreciation. The partner's fee is deducted before user withdrawals.

What partners get:

• A standalone ERC-4626 vault, configured with a chosen fee and a recipient address. Supports any standard integration (deposit, withdraw, redeem, preview).
• Flexible fee configuration. The fee can be a performance fee (charged on yield), a management fee (charged on AUM), or a combination. Rates and recipient address are set at deployment.
• Optional permissioned setup. Wrappers can be deployed with gates on deposit, transfer, and withdrawal to comply with jurisdictional requirements (e.g. KYC-gated access, allowlisted depositors). KPK and the partner agree the gating policy at deployment.
• Non-custodial guarantees. Once deployed, gates that could restrict user withdrawals are permanently abdicated, so neither KPK nor the partner can block exits beyond the agreed policy.
• APY queryable via Morpho. The wrapper's APY is exposed through the Morpho GraphQL API, already net of the configured fee.

What to send when requesting a wrapper

To deploy, KPK needs three details from the partner:

1. Fee recipient address. The wallet that will receive performance and/or management fees, in 0x... format. Any address the partner controls works; KPK can also spin up a fresh Gnosis Safe and transfer ownership. The address must be able to call redeem() on the wrapper to convert accrued fee shares to assets.
2. Custody mode. Either:

   • Non-custodial mode (recommended for DeFi-native deployments). The gate setters (receiveShares, sendShares, receiveAssets) are permanently locked at deployment, so no one can restrict deposits, withdrawals, or transfers afterwards.
   • Configurable gates. The owner/curator retains the ability to set gates later for compliance (e.g. KYC/AML allowlists). Configurable gates may introduce custodial characteristics depending on the policy.
3. Vault naming.

   • Vault name (max 60 characters), e.g. Partner USDC Yield by KPK.
   • Vault symbol (max 30 characters), the onchain ticker, e.g. partnerUSDCy.

Either way, the wrapper does not appear in the public Morpho UI; it is reachable only through the partner's integration or via direct contract calls.

Sensible defaults

Partners without a strong preference can ask KPK to proceed with:

• Non-custodial mode (standard for DeFi-native deployments).
• A Fee Recipient Safe that KPK spins up on the partner's behalf, with the partner's chosen signers; ownership transferable later.
• Naming in the form <Partner> <Asset> <Strategy> by KPK for the vault name, and <partner><asset><Strategy> for the symbol. All three can be changed at deployment time.

To request a wrapper, contact [e-mail] or use the contact form with the underlying vault, fee structure, and any required gating.

Support

For integration questions, technical reviews, or hands-on help, reach out to [e-mail] or use the contact form. For protocol-level Morpho documentation, see docs.morpho.org.