Mitosis

Mitosis miAssets are ERC-20 vault shares with a queued exit

Mitosis miAssets are ERC-20 vault shares whose underlying hub assets return through Mitosis's ReclaimQueue rather than an instant redemption. A holder submits shares, waits for the vault's configured reclaim period, and waits for sufficient liquidity to be reserved. Only after both conditions are satisfied does a separate claim transfer the hub asset to the recorded receiver. The commonly shown seven-day period is an example, so the vault's on-chain reclaimPeriod governs a specific request.

Posted:

In short: A single receiver can hold 100 pending requests per vault, so splitting an exit adds queue records without shortening the reclaim period.

A submitted request is not a completed redemption

The Mitosis reclaim request starts a three-stage exit; it does not release hub assets. The ReclaimQueue first receives the selected vault shares and creates a request record for the chosen receiver. Those shares leave the sender's wallet immediately, which explains why the visible miAsset balance falls before any underlying asset arrives.

Next, the resolver synchronizes a contiguous portion of the queue after liquidity becomes available. The final stage is a separate claim transaction. Two gates control that transition: the request must be old enough, and its underlying hub assets must have been moved into reserve. Treating a successful request receipt as proof that redemption has finished is the central mistake to avoid.

Which clock actually controls the wait?

The Mitosis reclaim clock applies a vault-specific minimum period measured from the request timestamp. Seven days equals 168 hours, but that figure is an illustrated configuration rather than a universal duration for every VLF Vault. The contract exposes reclaimPeriod(vault) and includes the same value in queueInfo, allowing the relevant queue setting to be read directly.

Time alone never resolves the request. If the configured period ends before liquidity is reserved, the request remains pending until the resolver synchronizes it. If reservation occurs first, the timestamp boundary still blocks the claim. The earliest claim moment is therefore the later of those two events. A request stores its timestamp, while the queue stores the period; a later configuration update changes the eligibility boundary applied to pending records.

The requested asset amount becomes a ceiling

A ReclaimQueue request records both the submitted shares and the asset amount returned by previewRedeem at submission. For Mitosis miAssets, the eventual claim uses the lower of two quantities: that recorded asset amount or the shares' floor-rounded value at the applicable synchronization snapshot.

This rule separates queue exposure from continued ownership of freely held shares. If the vault's share value rises after submission, the claimant does not receive more than the recorded preview; the share value above that ceiling is handled through ReclaimQueueCollector. If the vault value falls before synchronization, the lower conversion determines the claim. The request therefore fixes upside at entry while preserving exposure to a decline that reaches the vault before settlement.

Queue capacity rewards consolidation, not request splitting

The ReclaimQueue enforces a per-receiver, per-vault capacity rather than an unrestricted stack of small exits. The ReclaimQueue contract caps a single claim calculation at 100 requests and prevents one receiver from accumulating more than 100 pending requests for the same vault. A 101st pending request is rejected until earlier records advance beyond the receiver's personal offset.

Global request identifiers begin at 0 and rise as entries are appended. Synchronization advances through a contiguous range from the queue's global offset, so dividing one amount into many adjacent requests does not bypass earlier entries or shorten the configured clock. It consumes capacity and adds transaction work. Separate requests remain useful when amounts need different receivers or submission times, but request splitting is not a speed mechanism.

ERC-4626 standardizes shares, not instant liquidity

ERC-4626 standardizes vault accounting and previews; it does not require deployed strategy assets to be immediately withdrawable. Mitosis miAssets combine an ERC-20 share token with an ERC-4626-compatible VLF Vault, while ReclaimQueue supplies the delayed exit path needed when hub assets support active liquidity strategies.

The ERC-20 core interface defines six balance, allowance, and transfer functions plus two events, Transfer and Approval. ERC-4626 adds four primary state-changing flows - deposit, mint, withdraw, and redeem - along with eight maximum-or-preview companions and two conversion views. Mitosis uses this vocabulary to calculate shares and assets, then applies queue-specific timing and reservation rules outside the standard's basic accounting model.

At contract level, SafeERC20 and Math components from OpenZeppelin handle token transfers and explicit rounding. The queue calls previewRedeem when a request enters, transfers shares with transferFrom, and later invokes the vault withdrawal during synchronization. Standard interfaces make those units legible; available reserve liquidity decides when the exit progresses, which is examined in practice.

How idle liquidity becomes a reserved claim balance

The Asset Manager separates VLF liquidity into two operational states: idle and allocated. Reclaim reservations draw from idle hub assets, while allocated liquidity remains assigned to a strategy on a branch chain. This distinction explains why a vault with substantial total assets can still lack immediately reservable assets for a pending exit.

Reservation follows four linked actions. A strategist assesses idle liquidity, reserves an eligible amount, withdraws that amount from the VLF Vault into ReclaimQueue while the corresponding shares are burned, and removes the reserved balance from future strategy allocation. Once moved, that balance is earmarked for claims rather than new yield deployment.

When liquidity sits with a VLF Strategy Executor, it must first return to the Mitosis Vault and be deallocated through the Asset Manager's cross-chain ledger. Strategy position closure, branch-chain messaging, and ledger synchronization add time beyond the configured minimum. Queue length alone cannot reveal how quickly those operational steps will finish.

Reading on-chain status without inventing an ETA

ReclaimQueue exposes concrete state for eligibility and progress, but it does not publish a guaranteed completion timestamp. Its five-field QueueInfo view reports whether the queue is enabled, the reclaim period, the global offset, the item count, and the synchronization-log count. Together, those values show configuration and advancement without predicting future reservations.

A receiver's queueIndex supplies a personal offset and size, while pendingRequests returns selected request records. The four-value claim preview identifies the request range, total shares, and total assets that a claim would presently process. Synchronization logs retain six accounting fields: a timestamp, two request boundaries, cumulative shares, total supply, and total assets.

Vault accounting also changes through three settlement classes: same-asset yield, loss, and extra rewards. Yield increases hub assets in the vault, loss reduces them, and differently denominated rewards follow a separate distribution path. Because the reclaim calculation reads settled vault state and uses floor rounding, a claim preview provides better evidence than estimating from the wallet's original deposit amount.

Five checks before sending shares to ReclaimQueue

The pre-request decision for the Mitosis queue concerns amount, receiver, timing, and transaction readiness. The workflow provides no cancellation or receiver-reassignment function after a request is recorded, so these five conditions deserve confirmation before shares move:

The receiver and vault form the durable routing pair for the pending record. Selecting the correct vault matters as much as entering the correct amount because each VLF Vault has its own underlying ERC-20 asset, queue configuration, accounting state, and reservation balance.

Completing the claim after both gates resolve

A Mitosis miAssets claim is a second user action performed after time eligibility and synchronization are both complete. The previewClaim view shows the currently claimable aggregate, and claim(receiver, vault) transfers the underlying hub asset directly to that recorded receiver. Calling the function does not redirect the proceeds to the transaction sender.

The normal user path contains two mandatory state-changing calls: request and claim. It contains three when a fresh ERC-20 approval is required first. The resolver's synchronization transaction occurs between them as a protocol operation. One claim can advance as many as 100 eligible records for that receiver and vault, after which the personal offset moves forward.

On Mitosis Mainnet, chain ID 124816 distinguishes the network and MITO pays its transaction gas. Receiving the hub asset completes the ReclaimQueue portion of the exit. Moving an asset onward to Ethereum or another supported branch chain is a separate withdrawal operation with its own message, finality, and gas requirements.

FAQ

Can a queued miAsset reclaim be canceled after submission?

A submitted ReclaimQueue request has no cancellation function in the queue workflow. The shares have already transferred from the sender into the contract and the request is indexed to its recorded receiver. Because the claim amount is also bounded by the asset preview captured at submission, the amount and timing should be settled before the request transaction is sent.

Who receives the hub asset if another wallet calls the claim function?

The receiver stored with the request receives the reclaimed hub asset. The claim function accepts a receiver and vault, calculates that receiver's eligible records, and transfers the underlying ERC-20 asset to that address. A different wallet can submit the claim transaction without becoming the beneficiary, because the transaction sender does not replace the receiver recorded when the request entered the queue.

Does an ERC-20 approval start the reclaim clock?

An ERC-20 approval does not start the reclaim period. Approval only gives ReclaimQueue permission to transfer a specified allowance of vault shares. The request timestamp is created when the separate request transaction succeeds and the shares move into the queue. An approval completed hours or days earlier contributes no elapsed time toward the vault's configured waiting period.

Are queued reclaim requests represented by another transferable token?

Queued requests are contract records rather than newly minted transferable ERC-20 tokens. ReclaimQueue assigns request identifiers, stores share and asset amounts, and indexes each record under a receiver and vault. Transferring unrelated wallet tokens does not move that queue position. The underlying hub asset remains directed to the receiver stored for the request when an eligible claim is executed.

Why did my miAsset balance fall before the hub asset arrived?

The miAsset balance falls because submitting a reclaim transfers the requested vault shares into ReclaimQueue immediately. The corresponding hub asset arrives only after the minimum period passes, liquidity is synchronized into reserve, and a claim transaction succeeds. During synchronization, the vault withdrawal burns the relevant shares. The temporary gap between share transfer and asset receipt is therefore an expected part of the three-stage process.