Mitosis is a Layer 1 for programmable cross-chain liquidity

Do not confuse a hub asset with a miAsset

A hub asset and a miAsset record different stages of the liquidity journey. Depositing a supported token into a branch-chain vault mints an equivalent hub asset on the central chain, while supplying that hub asset to an EOL vault mints the miAsset that represents a strategy position.

The distinction controls both exposure and redemption. A hub asset has 1:1 backing and remains outside Vault Liquidity Framework strategies until its holder deliberately supplies it. A miAsset is an ERC-20 share in an ERC-4626-compatible vault, so its redemption value follows the vault's settled assets per share rather than a permanent one-token-for-one-token rate. The Mitosis Vault initially stores the branch-chain asset; after EOL supply, an authorized strategy executor gains access to the allocated portion. Keeping the hub asset therefore preserves a plain cross-chain representation, while minting the miAsset opts into managed liquidity deployment.

Mitosis EOL beside Yearn V3, Beefy, and Aave V3

Mitosis EOL combines a cross-chain asset ledger, managed strategies, and tokenized vault shares. Yearn V3 and Beefy also issue vault shares against automated strategies, whereas Aave V3 issues aTokens against liquidity supplied to a lending pool on one deployment. The relevant decision is who directs the underlying capital and what receipt the user controls.

EOL is the closer fit when one position should follow coordinated opportunities across branch chains. Yearn V3 or Beefy suits a user selecting a particular automated vault, while Aave V3 offers a more narrowly defined lending exposure. None of these models leaves the underlying token sitting in the user's wallet; self-custody applies to the private key and receipt token, not direct possession of capital after supply.

From a branch-chain deposit to a programmable position

A branch-chain deposit has 3 fixed state changes: the user transfers a supported asset to the local vault, cross-chain messaging reports the deposit, and the Asset Manager mints the matching hub asset. Supplying that hub asset to an EOL vault adds another state change by minting a miAsset share. A Base route using WETH or USDC, for example, can connect to an EOL opportunity supported by YO without making the user manually move strategy positions between networks.

Returning to the original asset separates the same layers in reverse. Reclaiming the miAsset first produces hub-asset value after the queue resolves. A hub-asset withdrawal then follows a 4-event sequence: request, burn, cross-chain message, and branch-chain transfer. The destination needs adequate unallocated liquidity because a representation on the central ledger does not guarantee that every branch holds enough immediately withdrawable inventory at the same moment.

The Mitosis Layer 1 as the coordination engine

The Mitosis Layer 1 divides its architecture into 2 layers. Its execution layer runs an EVM-compatible environment with unmodified Ethereum execution clients, while the consensus layer combines Cosmos SDK and CometBFT; the Engine API connects the two. The live network uses chain ID 124816 and MITO as its native currency symbol. MITO therefore pays gas for transactions executed on this Layer 1, while a deposit on Base or BNB Chain also consumes that branch chain's native gas asset.

The Mitosis Chain acts as the hub in a hub-and-spoke system. Vaults and strategy executors sit on branch chains, and the Asset Manager maintains the cross-chain ledger that distinguishes idle liquidity from allocated liquidity. This structure gives Solidity applications an EVM environment for miAssets while CometBFT supplies proof-of-stake consensus and finality beneath that execution layer.

How gains, losses, and extra rewards change miAsset value

VLF settlement updates a miAsset position through 3 accounting paths: same-asset yield, same-asset loss, and rewards paid in a different token. Same-asset settlement follows 5 actions from the strategist's trigger through balance comparison, cross-chain reporting, and minting or burning hub assets. A positive balance difference increases the assets represented by the existing shares; a negative difference reduces them.

Extra-reward settlement uses a separate 7-action path because the reward token differs from the vault's underlying asset. The strategy executor identifies and transfers the reward, the cross-chain ledger recognizes it, corresponding hub assets are minted to the treasury, and distribution reaches entitled users through the configured method. Morpho and Compound illustrate the kind of lending venue that produces strategy accounting, although an example venue does not imply that every EOL vault uses it. Yield therefore appears through settled share value or a defined reward distribution, not through an assumed fixed return.

Where miAssets earn their place in a DeFi strategy

miAssets support 3 primary uses: preserving a liquid claim on managed capital, carrying EOL economic exposure, and serving as programmable ERC-20 building blocks. A holder transfers the share without first unwinding every branch-chain strategy, provided the receiving application supports that exact token. That portability is useful when capital would otherwise sit in separate vault receipts across several networks.

Concrete positions include miETH and miUSDC, whose underlying assets are WETH and USDC rather than arbitrary tokens with similar names. The ERC-4626 interface standardizes asset-to-share queries, deposits, and redemptions for integrators. It does not create automatic acceptance by an exchange, lending market, or collateral system: each application must add the specific contract and define how it values the share. The benefit is programmable ownership of a managed position, while the boundary is integration-specific liquidity.

Reclaim queues, strategy exposure, and branch-chain limits

The reclaim queue converts a miAsset back toward a hub asset through 3 stages: initiation, resolution, and claim execution. Resolution requires 2 conditions - reserved underlying liquidity and completion of the vault's waiting period. A VLF configuration can impose a 7-day minimum, yet available idle liquidity still determines when reservation completes. The waiting period and the liquidity reservation are therefore separate checks, not interchangeable estimates of the same delay.

Strategy performance directly changes the value available for reclaim because settlement records both gains and losses. Cross-chain messaging, the Asset Manager ledger, branch-chain liquidity thresholds, and the strategy executor also form part of the operating model. Deposit caps constrain new supply through the ERC-4626 maxDeposit and maxMint functions, while withdrawal capacity depends on liquidity that has returned from active strategies. These constraints make the miAsset useful as a position token without turning it into an instantly redeemable stable balance.

Preparing the wallet and the first EOL supply

The first EOL supply requires an EVM wallet, a supported branch-chain asset, gas on every network used, and available vault capacity. The Mitosis app presents the route, but the wallet confirmation remains the definitive record of the asset, network, amount, approval, and contract interaction.

1. Select the supported branch chain and the exact deposit asset, such as WETH or USDC on Base.
2. Hold enough of the branch chain's native currency to approve and deposit the token.
3. Check the vault's available capacity rather than assuming every listed route accepts unlimited supply.
4. Approve only the intended amount, deposit, and wait for the cross-chain message to mint the hub asset.
5. Switch to the Layer 1 and confirm the hub-asset balance before choosing an EOL vault.
6. Supply the hub asset, record the received miAsset, and read the vault's reclaim configuration.

Those 6 steps deliberately separate bridging representation from strategy participation. If the process stops after the hub asset arrives, the funds have not entered EOL. Once the miAsset appears, the holder owns a vault share whose value and exit path follow that vault's accounting rather than the original wallet balance.

Governance and composability after the first supply

EOL allocation governance and network governance control different decisions. The EOL design uses 2 phases: Initiation evaluates which protocols become eligible, and Gauge voting assigns liquidity among approved integrations. Its voting model derives influence from a 7-day time-weighted average miAsset balance, while the operational strategist executes authorized allocations through the Asset Manager and branch-chain strategy contracts.

For most users, Mitosis governance uses gMITO for protocol parameters, upgrades, and cross-chain execution. The process has 4 broad stages - earn gMITO, accumulate voting power, vote, and execute an approved proposal - and its contracts build on OpenZeppelin v5 Governor and Timelock components. gMITO is ERC-20 compatible but non-transferable: ordinary transfer functions are disabled, while minting and burning remain available. Voting power adds 2 balances, held gMITO and staked gMITO. A miAsset position therefore governs liquidity within its EOL context, whereas gMITO addresses the wider network.