Mira: Preserving LP Token Redeemability

Invariant under test

Every transferable LP token accepted by the AMM must remain redeemable unless its underlying liquidity has actually been consumed.

The answer in 30 seconds

Microchain DEX engaged Immunefi for a 15-day review of Mira's binned-liquidity AMM on Fuel. Zealynx participated as a co-auditor alongside CODESPECT and Braniac. The review covered the Sway contracts that mint and burn liquidity, execute swaps, collect fees, and track LP-token reserves at commit 8800f00c7a8f56544a8e9aac55d187ab9b36e21b.[1][2]

The pivotal issue was a mismatch between storage presence and economic state. Mira blocked an LP token from being burned whenever its contract_reserves entry existed. After an attacker briefly used that LP token as an asset in another pool and withdrew it, the empty reserve entry still existed. The token remained transferable but could no longer be redeemed. The report rated the issue High and records it as fixed in commit 65509ec685e322498357504cf75967b06f69314d.[1]

This is a partner-delivered technical engagement narrative based on public evidence, not a customer transformation story. It does not claim exploitation, deployment, monetary exposure, customer sentiment, or continuing assurance.

The buyer decision: what makes an LP token safe to accept?

Mira implemented a binned-liquidity automated market maker: liquidity is distributed across discrete price bins, while LP tokens represent claims on pool reserves. The reviewed scope included mint, burn, swap, fee, bin-helper, and main-contract logic.[1][2]

For a DEX founder or integrator, the decision is broader than whether an LP token can be transferred:

Can every LP token that appears valid in a wallet, market, or integration still be redeemed for its underlying claim?

The relevant invariant was redeemability follows actual reserve ownership, not the historical existence of a storage key. A transferable token with a permanently disabled burn path can mislead holders and downstream systems about what the token represents.

The dangerous assumption: an existing reserve record means reserves still exist

Fuel's UTXO model required the burn path to distinguish LP tokens supplied for burning from LP tokens still held as pool reserves. Mira's guard queried contract_reserves and allowed burning only when the lookup returned None.[1]

That check treated two different states as equivalent:

the AMM currently holds the LP token as a reserve asset; and
the AMM once held the LP token, now holds zero, but retains a non-None storage entry.

The second state should not block redemption. Yet the storage-presence check could not distinguish it from live reserves.[1]

How the review tested the redeemability invariant

1. Follow the token through a complete lifecycle

The review did not stop at LP-token creation or transfer. It followed the token through minting, use as an asset in another pool, reserve withdrawal, transfer, and eventual burn.[1]

2. Separate storage shape from economic value

The critical question was not whether contract_reserves.get(asset_id) returned a record. It was whether the AMM still held a non-zero reserve balance for that asset. That distinction exposed the stale-state failure.[1]

3. Test composability as an adversarial sequence

An attacker did not need to forge an LP token or seize privileged authority. The sequence used ordinary pool operations to change how the AMM later interpreted a legitimate token.[1]

4. Verify the remediation at a named commit

The report recommended allowing the burn when the reserve entry is absent or zero. It records the High-severity issue as fixed in commit 65509ec685e322498357504cf75967b06f69314d.[1]

The pivotal discovery: a valid token could be tainted by history

The failure sequence was:

an attacker obtains or selects a legitimate Mira LP token;
the attacker creates or uses another pool with that LP token as one reserve asset;
the LP token is deposited into that pool, creating a contract_reserves entry;
the attacker withdraws the deposited LP token, leaving the reserve balance empty;
the reserve lookup remains non-None because the storage entry persists;
the LP-token burn guard rejects redemption despite the AMM no longer holding that token as pool reserves.[1]

The report describes the resulting token as unredeemable while still capable of being deposited into a third-party system or sold.[1] The security boundary therefore extended beyond Mira's own UI: downstream systems could observe a transferable token without knowing that its redemption path had been disabled by prior pool history.

Before, intervention, and verified after-state

Before the review	Review intervention	Verified after-state in the public report
Burn eligibility depended on whether a reserve record existed	Traced an LP token through deposit, full withdrawal, transfer, and burn	IMM-HIGH-01 records a fix in commit `65509ec685e322498357504cf75967b06f69314d`
An empty-but-present reserve entry was treated like a live reserve balance	Distinguished storage presence from a non-zero economic balance	The report says the guard should permit burning when reserves are absent or zero
A token could remain transferable after its redemption path became unavailable	Evaluated the token from a downstream holder or integrator's perspective	The identified stale-state redemption path is recorded as fixed

“Fixed” is limited to the remediation recorded in the September 2025 report. The public evidence does not establish production deployment or guarantee later versions.[1]

A reusable test model for receipt and LP tokens

Teams building or integrating transferable claim tokens should test lifecycle state, not just token validity:

redeemable(token) = authentic_issuer(token)
                  && claim_balance(token) > 0
                  && no_live_reserve_constraint(token)
                  && burn_path_uses_current_economic_state

Before release or integration, verify:

Zero versus missing: Does the contract distinguish a zero balance from an absent record, and should it?
State cleanup: Which mappings remain populated after a full withdrawal or burn?
Round-trip behavior: Can an asset be deposited, fully withdrawn, transferred, and redeemed without historical state changing its rights?
Nested claims: What happens when one pool's LP token becomes another pool's reserve asset?
Third-party observability: Can an integrator detect whether a transferable claim is currently redeemable?
Adversarial tainting: Can another user change a token's redemption behavior without owning the eventual holder's position?
Remediation regression: Does relaxing a stale-state guard still prevent burning assets that are genuinely held as live reserves?

Impact and evidence limits

The strongest supportable result is finding-specific: the report documents a High-severity path that could make a legitimate LP token permanently unredeemable, and it records the guard correction in a named commit.[1]

The wider review found ten issues: two High, four Medium, three Low, and one Insight. Nine were fixed and one Medium issue was acknowledged.[1][2] This narrative does not turn those statuses into a claim that the complete AMM was secure.

No public source establishes that the issue was exploited, that the fix was deployed, or that a dated amount of assets was exposed. No TVL, funds-protected, money-saved, loss-avoided, or business-outcome claim is made.

Evidence and attribution

Canonical technical record: the Immunefi report identifies Microchain DEX, the reviewed commit, the co-auditors, the stale reserve-entry mechanism, the recommendation, and the remediation commit.[1]
Public audit record: Zealynx's engagement page reports the same scope, co-audit relationship, finding distribution, and aggregate remediation state.[2]
Attribution class: partner-delivered. Microchain engaged Immunefi; Zealynx served as a co-auditor alongside CODESPECT and Braniac.[1]
Evidence cutoff: the public report dated September 17, 2025 and the public audit record used for this narrative.
Limitations: provider and partner-authored evidence supports technical scope and recorded remediation, but not deployment, customer sentiment, commercial impact, exploitation, or later-code security.

Shipping a transferable LP or receipt token?

Zealynx can test whether minting, nesting, reserve accounting, transfer, and redemption preserve the same claim through complete token lifecycles. Explore smart contract security audits or request an LP-token lifecycle review.

Frequently asked questions

Why did an empty pool still block LP-token redemption?

The burn guard checked whether a contract_reserves storage entry existed, not whether its current reserve value was non-zero. A fully withdrawn pool could therefore leave historical state that continued to block burning.[1]

Why is transferability not enough to prove an LP token is healthy?

Transfer logic can continue working even when the issuer's burn or redemption path rejects the token. Holders and integrations must evaluate the underlying claim lifecycle, not ERC-style transfer behavior alone.

How was the issue fixed?

The report recommended changing the guard so that a reserve result other than None is accepted when its value is zero. It records IMM-HIGH-01 as fixed in commit 65509ec685e322498357504cf75967b06f69314d.[1]

Was this a direct Zealynx client engagement?

No. The report states that Microchain engaged Immunefi. Zealynx participated as a co-auditor alongside CODESPECT and Braniac.[1]

Were all findings fixed?

Nine of ten findings were fixed. The Medium-severity active-bin share-calculation issue was acknowledged rather than fixed.[1][2]

How much value did the review protect?

The public evidence provides no dated, scoped asset amount for the affected LP-token path. This narrative therefore makes no monetary exposure, value-protected, money-saved, or loss-avoided claim.

Sources

[1] https://raw.githubusercontent.com/ZealynxSecurity/audits/main/web3/2025-08-zealynx-microchain.pdf — Mira Binned Liquidity AMM Security Report [2] https://zealynx.io/audits/microchain/binned-liquidity-amm-q3-2025 — Mira Binned Liquidity AMM Audit Record