Mitosis is a programmable liquidity network with a verifiable vault deposit flow

The origin-network mismatch that stops the vault call

A Mitosis vault deposit stops before execution when the wallet's active chain differs from the interface selection. The origin network determines the vault contract, token balance, fee currency, and transaction record. A familiar ticker cannot resolve that identity because token balances on separate chains belong to separate ledgers and contract addresses.

Chain IDs provide the decisive check. Ethereum uses chain ID 1, Arbitrum One uses 42161, and Base uses 8453. If the panel selects Ethereum while the wallet holds weETH on Arbitrum, the displayed balance stays empty or the action remains unavailable. No deposit has occurred at that point. The interface is reading Ethereum state while the token exists in the wallet's Arbitrum state.

Select the origin network where the supported asset actually resides, then accept the wallet's network switch. That alignment determines which vault receives the token. It also establishes the chain on which the first transaction receipt will appear.

Prepare the wallet state before entering an amount

The deposit prerequisites are a connected EVM wallet, a supported ERC-20 on the selected branch chain, and enough native currency for that chain's fee. The standard flow sends the Hub Asset to the same 20-byte EVM address on Mitosis Chain. Keep the intended account connected throughout the network switch so the sender and destination remain consistent.

Gas assets stay separate from the deposit token. BNB Smart Chain, shown as BSC in the selector, uses chain ID 56 and BNB for gas. Optimism uses chain ID 10 and ETH. Mantle uses chain ID 5000 and MNT. A wallet holding only the selected ERC-20 lacks the native balance required to submit its approval or vault call.

The token must already exist on the chosen origin chain. Switching the wallet from one network to another changes its chain context; it does not relocate a balance. Once the account, token, and native fee asset line up, the panel can produce a meaningful quote.

Read every choice in the deposit panel before signing

The deposit panel exposes five decision fields: action, origin network, token, amount, and expected receipt. It also displays the Network Fee. Deposit and Withdraw are different flows, so the active tab belongs in the review. The token row identifies the asset being transferred, while "You'll Receive" identifies the Hub Asset issued on the destination chain.

Use each network's durable chain identity behind its label. Linea is chain ID 59144, Scroll is 534352, Mode is 34443, and Blast is 81457. The amount beside Network Fee is a transaction quote for the selected origin. A displayed 0 before the wallet and amount are fully loaded is a placeholder, not a final gas estimate. The core vault also rejects a zero-amount deposit.

Five-condition confirmation checklist

• The wallet's chain ID matches the origin network selected in the panel.
• The token symbol, contract, and available balance belong to that same chain.
• The entered amount leaves enough native currency for approval and deposit gas.
• "You'll Receive" shows the same asset quantity as a Hub Asset on Mitosis Chain.
• The Network Fee uses the native currency expected for the selected origin.

These checks separate three values that look similar on a compact screen: the deposit asset, its fiat display value, and the network fee. Only the token amount enters the vault. The fee pays for transaction execution and cross-chain coordination.

From branch-chain transfer to Hub Asset mint

The vault deposit flow has 3 protocol stages. First, the branch-chain vault transfers the selected ERC-20 from the connected account and stores it. Second, a cross-chain message reports the asset, recipient, and amount to the Asset Manager. Third, the Asset Manager mints the matching Hub Asset on the destination chain.

A conventional ERC-20 with insufficient allowance requires 2 distinct state changes: approval and deposit. Approval authorizes the vault to spend a stated token amount but does not deposit it. The later vault call performs the transfer, reduces available vault capacity, emits the deposit record, and starts the cross-chain message. An existing sufficient allowance removes the extra approval request.

The Asset Manager mints Hub Assets at a 1:1 deposit ratio after the cross-chain message reaches Mitosis Chain. The Hub Asset follows ERC-20 and retains the underlying asset's symbol, while its network and contract address distinguish it from the origin token. The underlying remains stored in the branch-chain vault. Supplying that receipt to a Vault Liquidity Framework is a separate decision that produces a different position asset, such as a miAsset or maAsset.

Verify the branch-chain receipt and Hub Asset balance

Deposit verification uses 2 on-chain records rather than one interface success message. The origin record proves that the token entered the branch-chain vault. The destination balance proves that the corresponding Hub Asset was minted after the cross-chain message arrived. Reading both sides prevents a pending relay from being mistaken for a new deposit requirement.

Start with the origin transaction. Its chain ID should match the network selected before signing. A successful vault call emits a Deposited record with 3 essential fields: asset, recipient, and amount. The wallet's token balance falls by the deposited quantity, while its native balance also reflects the transaction fee.

Then inspect the same EVM address on the destination network. Its mainnet chain ID is 124816, and MITO is its native fee currency. The Hub Asset balance should rise by the deposited quantity under the corresponding ERC-20 contract. The token symbol alone is insufficient for this check; pair the symbol with the destination chain and contract address.

An origin receipt can finalize before the Hub Asset appears. That state means the deposit transfer succeeded while cross-chain delivery remains in progress. Refresh the destination balance and follow the existing transaction trail. Submitting another deposit would create a second independent transfer rather than accelerate the first message.

Repair a wrong-network setup without duplicating the deposit

A wallet-chain mismatch is repaired by restoring the intended account, selecting the network that actually holds the token, and accepting the matching wallet switch. If no vault transaction was submitted, no deposit token moved. The panel simply queried the wrong chain and returned an empty balance or inactive action.

Compare the full 42-character EVM address, including the 0x prefix, rather than relying on a shortened account label. If the address matches but the balance does not, inspect the wallet's chain ID. Choose that token's supported chain in the panel. Moving the selector does not bridge the token, and choosing another network will not make the existing balance available there.

A completed approval does not prove that a deposit followed. It leaves an allowance on the specific token, spender, account, and chain. A reverted vault call leaves the deposit token in the wallet because the transfer and contract changes revert together, although an earlier approval remains. A successful origin receipt means the flow has progressed beyond setup; verify the destination mint instead of signing a duplicate request.