Bundles

Bundles structure

Bundles are opinionated, end-user-facing entrypoints that execute a fixed chain of calls against a Morpho protocol in a single transaction. Each entrypoint performs atomic checks, can receive callbacks (e.g. Morpho callbacks used to sequence a borrow and a supply), and keeps calldata simple to verify. Bundles operate on msg.sender's position and are not meant to be called by other contracts or to hold token balances between transactions.

Most Bundle entrypoints share the same building blocks:

Token permits - each underlying token the Bundle pulls from the caller accepts an optional TokenPermit, either an ERC-2612 permit or a Permit2 SignatureTransfer, so the approval and the operation land in one transaction. An empty permit means the caller granted a standard ERC-20 allowance to the Bundle beforehand. MidnightBundlesV2 uses separate standard ERC-20 approvals and accepts no inline Permit or Permit2 signatures.
Share permits - share-based entrypoints (vaultBundlesV1Withdraw, vaultBundlesV1Migrate, vaultExitBundlesV1InKindRedemptionVaultV1, vaultExitBundlesV1InKindRedemptionVaultV2, and vaultExitBundlesV1ForceWithdrawVaultV2) take an ERC-2612 Permit on the vault shares instead, or rely on a prior share allowance to the Bundle. Shares never go through Permit2.
Signed authorization - BlueBundlesV1 entrypoints that act on the caller's Morpho position (borrow, withdraw, repay-and-withdraw-collateral, migrate) accept an optional Morpho SignedAuthorization so the caller can authorize the Bundle in the same transaction. An empty signature means the Bundle is already authorized. Vault entrypoints take share permits, not Morpho authorizations.
Public allocations - entrypoints that consume market liquidity accept a list of Vault V2 BluePublicAllocator reallocations executed before the operation.

The deployment addresses of every Bundle are listed in the addresses page.

Referral fees and deadlines

Eligible Blue and Vault Bundle entrypoints can collect optional referral fees, paid to a configured recipient in the same transaction.

referralFeePct: WAD-scaled percentage, strictly below WAD; pass 0 for no fee.
referralFeeRecipient: address that receives the fee.
deadline: timestamp after which the entrypoint reverts.

Entrypoint(s)	Fee base	Formula
`blueBundlesV1Supply`, `vaultBundlesV1Deposit`	Assets pulled from the caller	`fee = assets * referralFeePct / WAD`; the remainder is supplied or deposited.
`blueBundlesV1SupplyCollateralAndBorrow`, `blueBundlesV1Withdraw`	Loan-token proceeds after public allocator penalties	`fee = proceeds * referralFeePct / WAD`; the remainder is sent to the caller.
`vaultBundlesV1Withdraw`, `vaultExitBundlesV1ForceWithdrawVaultV2`	Assets withdrawn after any force-deallocate penalty	`fee = withdrawnAssets * referralFeePct / WAD`; the remainder is sent to the caller.
`blueBundlesV1RepayAndWithdrawCollateral`	Actual assets repaid	`fee = repaidAssets * referralFeePct / (WAD - referralFeePct)`; the fee is charged on top.
`blueBundlesV1MigrateBorrowPosition`	Source-market debt repaid	`fee = repaidAssets * referralFeePct / (WAD - referralFeePct)`; the fee and any allocator penalties increase destination debt.
`vaultBundlesV1Migrate`	Assets withdrawn from the source vault	`fee = withdrawnAssets * referralFeePct / WAD`; the remainder is deposited into the destination vault.
`vaultExitBundlesV1InKindRedemptionVaultV1`, `vaultExitBundlesV1InKindRedemptionVaultV2`	No fee base	No referral fee.

For guidance on charging a borrow fee through Bundles and related Blue and Vault operations, see How to monetize your borrow product.

Every MidnightBundlesV2 entrypoint requires a deadline. Four taker entrypoints accept referral-fee fields, while midnightBundlesV2CancelAndMake does not. See How the referral fee works.

`BlueBundlesV1`

BlueBundlesV1.sol

Entrypoints for Variable Rate Markets (Morpho Blue):

Entrypoint	What it does
`blueBundlesV1Supply`	Supply loan assets to a market.
`blueBundlesV1Withdraw`	Withdraw supplied loan assets, by assets or by shares.
`blueBundlesV1SupplyCollateralAndBorrow`	Supply collateral and borrow, bounded by a `maxLtv` check.
`blueBundlesV1RepayAndWithdrawCollateral`	Repay debt, by assets or by shares, and withdraw collateral, bounded by a `maxLtv` check.
`blueBundlesV1MigrateBorrowPosition`	Move a full borrow position (collateral and debt) from one market to another in one transaction - the source debt is repaid atomically with assets borrowed on the destination market, so the caller needs no assets for repayment.

blueBundlesV1SupplyCollateralAndBorrow, blueBundlesV1Withdraw and blueBundlesV1MigrateBorrowPosition accept Vault V2 BluePublicAllocator reallocations.

`VaultBundlesV1`

VaultBundlesV1.sol

Entrypoints for Vault V1 and Vault V2:

Entrypoint	What it does
`vaultBundlesV1Deposit`	Deposit assets into a vault.
`vaultBundlesV1Withdraw`	Withdraw assets from a vault.
`vaultBundlesV1Migrate`	Migrate assets from one vault to another vault.

`VaultExitBundlesV1`

VaultExitBundlesV1.sol

Exit paths for vaults whose liquidity is constrained:

Entrypoint	What it does
`vaultExitBundlesV1InKindRedemptionVaultV1`	Redeem in kind from an illiquid Vault V1.
`vaultExitBundlesV1InKindRedemptionVaultV2`	Withdraw idle assets and redeem the remainder in kind from an illiquid Vault V2.
`vaultExitBundlesV1ForceWithdrawVaultV2`	Force withdraw assets from an illiquid Vault V2 whose underlying markets are liquid, paying the force-deallocate penalty (idle and liquidity-adapter assets are withdrawn penalty-free first).

`MidnightBundlesV2`

MidnightBundlesV2.sol

Entrypoint	What it does
`midnightBundlesV2CancelAndMake`	Cancels selected offer groups, optionally supplies collateral or parks loan assets on Blue, and atomically activates a new offer root and logs its payload.
`midnightBundlesV2BuyWithUnitsTargetAndWithdrawCollateral`	Takes offers toward a units target, can repay remaining debt, and withdraw collateral.
`midnightBundlesV2BuyWithAssetsTargetAndWithdrawCollateral`	Takes offers toward an asset target, can repay remaining debt, and withdraw collateral.
`midnightBundlesV2SupplyCollateralAndSellWithUnitsTarget`	Supplies collateral and takes offers toward a units target.
`midnightBundlesV2SupplyCollateralAndSellWithAssetsTarget`	Supplies collateral and takes offers toward an asset target.

Operations act on msg.sender's position; MidnightBundlesV2 entrypoints do not accept a taker address.
Token pulls use separate ERC-20 approvals rather than inline Permit or Permit2. When msg.value is positive, MidnightBundlesV2 wraps the supplied native token and transfers it to the caller.
The two buy entrypoints can repay debt and withdraw collateral, and the two sell entrypoints can supply collateral. The separate MidnightBundlesV1 repay-and-withdraw path is removed.
Maker publication is atomic: selected offer-group cancellations, optional collateral supply or Blue asset parking, ratifier root activation, and payload logging share one call.
MidnightBundlesV2 adds reduce-only bounds, and every entrypoint takes a deadline.

MidnightBundlesV1 compatibility: MidnightBundlesV1 remains functional, and migrating to MidnightBundlesV2 is optional. The Bundles changelog Source code table links both contract versions.

Permit2

In November 2022, Uniswap Labs introduced Permit2, a robust token approval contract designed to standardize and secure token approvals across various smart contracts. By enabling signature-based approvals and efficient management of token allowances, Permit2 significantly enhances the user experience. It reduces transaction costs and bolsters smart contract security by mitigating risks associated with traditional approval methods.

Bundles accept Permit2 SignatureTransfer permits, naming the Bundle as spender, as an alternative to ERC-2612 permits and standard ERC-20 approvals. MidnightBundlesV2 accepts no Permit2 signature and requires a standard ERC-20 approval. Discover the full potential of Permit2 and how it revolutionizes token approvals in the integration guide.

Bundler3 (deprecated)

Bundler3 - the general-purpose multicall dispatcher with GeneralAdapter1, ParaswapAdapter and the migration adapters - is deprecated. The Morpho interface and the Morpho SDK (from v6) route every operation through Bundles, and new integrations should do the same. Bundler3 deployments remain live and immutable, and their addresses stay listed in the addresses page for existing integrators.

Bundles are protocol-specific by design. Flows that Bundler3 enabled through arbitrary call composition - DEX swaps and leverage via ParaswapAdapter, migrations from other lending protocols via the migration adapters, and Vault V1 PublicAllocator reallocations - have no Bundle equivalent today.

Bundles

On this page