Mitosis

Mitosis vaults connect branch-chain deposits to Hub Assets

Mitosis vaults hold deposited assets on supported branch chains while the Asset Manager issues corresponding Hub Assets on Mitosis Chain. Cross-chain messages connect custody on one chain with token accounting on the other. A deposit-only route creates a representation of the underlying asset without authorizing strategy deployment. Supplying Hub Assets to a Vault Liquidity Framework, or selecting the combined deposit-and-supply route, commits the supplied portion to that framework. Withdrawal of the underlying assets requires available liquidity on the selected branch chain.

On this page

A completed deposit needs a processed message

A standard deposit transfers a supported token into branch-chain custody, then sends a message; unfinished minting calls for tracing the existing message before another deposit.

The branch record confirms custody

The selected asset must be initialized in the vault, with deposits enabled and sufficient remaining capacity. The core deposit method pulls the token from its caller through an ERC-20 allowance. Its successful transaction emits a Deposited event identifying the asset, recipient and amount. That record establishes the branch-chain deposit. It doesn’t establish a completed mint on Mitosis Chain, because the destination contracts still need to process the message. The Asset Manager’s Deposited event in the destination transaction records the later mint.

Trace the deposit message when minting remains unfinished

Cross-chain processing can remain unfinished after a successful origin transaction. The existing deposit message identifies the asset, recipient and amount awaiting destination execution. Check the message’s processing status and any destination revert details to distinguish unfinished delivery from a rejected contract call. Another accepted deposit would transfer additional tokens, so resubmitting the asset transfer doesn’t finish the earlier mint.

A transaction signature alone doesn’t establish either custody or minting.

Does a vault deposit also commit assets to a strategy?

A deposit commits assets to a Vault Liquidity Framework only when the user supplies the resulting Hub Assets or the protocol’s combined deposit-and-supply route successfully supplies them.

Deposit-only custody retains the supply decision

Holding Hub Assets alone doesn’t authorize their underlying assets for VLF deployment. A Vault Liquidity Framework, or VLF, organizes a liquidity opportunity around a particular Hub Asset. Ecosystem-Owned Liquidity (EOL) and Matrix are the relevant framework models. Supplying to a VLF creates a share position and makes corresponding underlying liquidity available for allocation. Choosing deposit-only custody preserves the option to decide on that commitment later.

Combined supply can leave a Hub Asset remainder

The branch contract also exposes depositWithSupplyVLF, which includes the selected VLF vault in its cross-chain message. The branch-side VLF must be initialized and match the deposited asset. When the destination VLF’s underlying asset matches the mapped Hub Asset, the Asset Manager limits supply to the recipient’s permitted deposit amount for that originating chain. When this limit accepts only part of the deposit, the recipient receives the remaining Hub Assets. A successfully processed combined message can consequently produce both vault shares and an unsupplied Hub Asset balance.

If the destination VLF’s underlying asset doesn’t match, the recipient receives Hub Assets without VLF supply. The Asset Manager’s DepositedWithSupplyVLF event on Mitosis Chain includes both the deposited amount and the amount actually supplied.

Deposit parameters define acceptance at the custody vault

The custody vault checks asset configuration, remaining capacity and recipient validity before accepting a deposit, so a positive wallet balance alone doesn’t establish whether the call can succeed.

Breakdown: Deposit parameters define acceptance at the custody vault
Deposit parameter Required value or condition Rejection when unmet
Asset initialization isAssetInitialized(asset) returns true An uninitialized asset causes the deposit to revert.
Asset deposit halt isAssetActionHalted(asset, AssetAction.Deposit) returns false A halted deposit action causes a revert.
Remaining capacity availableCap(asset) is at least the deposit amount An amount exceeding remaining capacity causes a revert.
Recipient address The to address is nonzero A zero recipient causes a revert.

The amount must also be nonzero, and the relevant function must pass its pause check. Global pauses and function-specific pauses are separate from an asset’s deposit halt. Capacity changes as deposits consume it and authorized managers adjust the cap. These are custody-vault conditions; a VLF applies its own supply limits. Passing one contract’s checks doesn’t establish acceptance by the other.


Contract permissions separate withdrawals from strategy access

Branch-chain withdrawals use an authenticated entrypoint, while strategy access depends on allocated liquidity and a configured executor; ownership of a receipt doesn’t grant arbitrary access to the custody contract’s balance.

Diagram: Contract permissions separate withdrawals from strategy access (Mitosis vaults)

View image file

The entrypoint routes authenticated withdrawals

Only the configured entrypoint can call the custody vault’s withdrawal function. The branch entrypoint checks the incoming remote domain and sender before routing withdrawal instructions. On Mitosis Chain, the receiving entrypoint also validates the registered origin and branch sender before forwarding a deposit. These checks connect each accepted message to its configured counterparty. Message authentication and deposit accounting serve different purposes: one establishes the permitted sender, while the other determines the affected asset and amount.

Allocation restricts the strategy executor

The Asset Manager tracks idle and allocated liquidity for each VLF. A strategist’s allocation requires enough idle Hub Asset value and available underlying liquidity on the selected branch. After the allocation message arrives, the configured strategy executor can fetch its permitted amount from custody. Returning tokens to the vault and deallocating them are distinct operations. The deallocation message updates the Asset Manager’s ledger, making the corresponding value idle again. A custody token balance alone therefore doesn’t describe every allocation commitment.

What limits a withdrawal to a branch chain?

A withdrawal requires a registered asset pairing, sufficient unallocated liquidity on the destination branch and enough recorded branch liquidity remaining to satisfy that asset’s configured threshold after withdrawal.

The Asset Manager checks destination-branch liquidity before burning Hub Assets for a withdrawal. Available branch liquidity equals recorded branch liquidity minus allocated liquidity. The threshold check separately compares recorded branch liquidity after withdrawal with its configured minimum. If either liquidity check fails, the withdrawal reverts without burning Hub Assets. Once the request passes, the Asset Manager burns the corresponding Hub Assets and sends withdrawal instructions. The branch vault transfers the underlying token when it processes those instructions. A Hub Asset burn records initiation on Mitosis Chain; the branch transfer records delivery to the recipient.

Another supported branch is an alternative only when its asset pairing and liquidity conditions also permit the withdrawal.


Hub Assets and vault shares represent different claims

Hub Assets represent deposited underlying tokens at a 1:1 deposit and withdrawal ratio, while VLF shares represent participation in a particular liquidity opportunity and its changing asset value.

The Hub Asset follows ERC-20 and retains the underlying token’s symbol. A VLF vault implements an ERC-4626 interface, with share conversion determined by its vault accounting. Yield settlement can increase the Hub Assets backing its shares; loss settlement reduces that backing. The custody ratio doesn’t promise a fixed VLF share conversion or protection from strategy losses. A position in miAssets or maAssets therefore needs different accounting from an unsupplied Hub Asset balance.

Reclaiming VLF shares starts with a queue request. A later claim returns Hub Assets once liquidity is reserved and the configured waiting period has elapsed. That claim doesn’t itself deliver underlying tokens to a branch chain. The subsequent withdrawal must satisfy the destination’s separate liquidity limits.

Illustration: Mitosis vaults: Hub Assets and vault shares represent different claims

View image file

A combined deposit can leave separate share and Hub Asset balances; only the share portion requires VLF reclaim before a branch-chain withdrawal.

Quick answers about Mitosis vaults

Is depositing to another recipient supported by a Mitosis vault?

The core deposit method lets the caller specify a separate recipient through its to parameter. It pulls the underlying tokens from the caller and carries the recipient in the deposit message. The recipient must be nonzero; supplying an unintended valid address doesn’t automatically make the call revert.

What fee does quoteDeposit return for a Mitosis vault deposit?

quoteDeposit returns the quoted fee for dispatching the deposit message through the configured cross-chain messaging route. It isn’t the deposited token amount or the complete cost of executing the origin transaction. The native currency supplied with the deposit funds message dispatch, while the underlying ERC-20 amount follows the token transfer.

Can I send native currency straight to the custody vault?

The core custody vault rejects plain native-currency transfers through its receive and fallback functions. Its payable deposit method accepts native currency for message dispatch while pulling a supported ERC-20 token. A native-asset wrapping route uses a separate deposit proxy where supported; sending currency directly to the vault doesn’t invoke that route.

How do token decimals affect the amount withdrawn from a vault?

The Asset Manager converts between Hub Asset units and the destination token’s configured decimals. If the Hub Asset has finer precision, withdrawal rounds down to representable branch-token units and burns only the matching adjusted Hub Asset amount. An amount rounding to zero fails; finer residual units remain in the holder’s balance.

Do I need to approve Hub Assets for a branch-chain withdrawal?

The standard Asset Manager withdrawal burns Hub Assets through the token’s authorized supply-manager role and doesn’t consume a wallet’s ERC-20 allowance. Branch deposits use token allowances because the custody vault pulls the underlying asset. A separate application or wrapper can require permissions for its own operations, so those requests need separate consideration.

Last updated: