Mdex
Mdex liquidity mining: eligibility for LP rewards
Mdex liquidity mining rewarded users who staked eligible liquidity provider (LP) tokens in designated pools, so providing liquidity alone didn’t qualify every LP. Historical documentation covered HECO and BSC. HECO later received a shutdown notice, while old BSC pool listings don’t establish that rewards remain available today.
LP shares connect trading reserves with mining incentives
The liquidity pool held the paired assets used for swaps, while the mining pool accounted for eligible LP stakes. Supplying assets supported trading reserves; staking the resulting LP token determined participation in the corresponding mining pool. The historical workflow put liquidity provision before LP staking.
The assets behind an LP token
An LP token represented a share of a particular liquidity pool. The desktop instructions required both tokens for the selected pair, with matching values when adding liquidity to the existing pool. Equal value didn’t mean equal token quantities. The LP token connected the position to that pool’s assets, whose quantities could change as swaps altered the reserves.
The balance that mining rewarded
The mining entry accepted its corresponding LP token. Tokens held outside that entry weren’t part of its recorded stake, even when their owner had already supplied liquidity. The eligible staking balance therefore differed from the wallet’s holdings of either underlying asset. Owning MDX alone also didn’t establish an LP mining position.
Did every trading pair qualify for MDX rewards?
No, a tradable pair didn’t automatically qualify for liquidity mining rewards. Mdex restricted incentives to selected pairs. A pool could support swaps without appearing in the mining list, and creating a new pair didn’t itself establish a reward allocation. Eligibility belonged to the particular mining entry and its network, rather than every pool containing the same token names.
A historical announcement adding a pair described that campaign’s scope. It didn’t make the offer permanent or extend it to another network.
Network status changes the meaning of an old pool listing
HECO’s shutdown notice means that the original dual-chain mining description can’t serve as a current participation offer across both networks.
HECO after the shutdown notice
The November 20, 2024 notice named January 15, 2025 as HECO’s scheduled shutdown date and warned about clearance of certain assets. It concerned that network, without establishing closure of every Mdex deployment. Older HECO mining instructions describe historical operations. They don’t establish a deposit or recovery route after the announced shutdown date, and the notice doesn’t confirm what happened to each individual LP position.
BSC mining had its own pool entries
The documented BSC program concerned LP positions on BSC, now called BNB Smart Chain. Its old listings don’t confirm present reward allocations. An MDX-earning position would require an entry that accepts the relevant LP token and allocates rewards on that network. A launch announcement for another Mdex deployment doesn’t establish that it reproduced a particular mining campaign.
Does approving LP tokens start liquidity mining?
Approval alone doesn’t deposit LP tokens into a mining pool. In the ERC-20 approval model, an allowance permits a specified spender to use up to a stated token amount. That permission doesn’t establish a staking balance. The historical desktop workflow required authorization before the LP staking action when permission was first needed.
Before authorization or deposit, the held LP token must match the mining entry’s accepted token and network. An allowance for another token or spender doesn’t satisfy that requirement. A confirmed approval establishes permission; the mining pool’s recorded balance establishes the credited stake.
A pair-label match with an incompatible LP token
An LP token must match the token accepted by the selected mining pool before that balance can support a deposit. In this hypothetical example, assume a BSC mining entry is active. The wallet holds an LP token with the same displayed pair names, but its contract differs from the LP contract that the entry accepts.
The reader compares the contracts before authorizing a deposit. The comparison fails, so the wallet holding supplies no compatible LP tokens for that entry. The deposit remains unsigned. Matching pair names had suggested eligibility; the contract mismatch invalidates that assumption.
A retry requires a matching LP balance on the entry’s network, or another active entry that actually accepts the held token. Refreshing the display doesn’t change token identity. Without a matching entry, the held LP token remains outside the proposed mining position.
What determined an LP staker’s share of MDX?
Reward allocation depended on the amount assigned to the mining pool and the participant’s proportion of its eligible stake. In the proportional calculation, a participant’s share equalled their eligible LP stake divided by the mining pool’s total eligible LP stake. That fraction applied to the pool’s allocation, not all MDX produced across the platform. More competing stake could reduce an unchanged participant’s fraction. Production changes could also alter the available rewards: the May 20, 2024 announcement reported a further MDX halving on HECO and BSC. It described historical emissions, without establishing today’s allocation for any particular LP pool.
Displayed yield and the value of the pooled assets
MDX rewards added a token flow, while the LP position continued to reflect its underlying liquidity pool.
An annualized rate uses changing inputs
An annualized reward rate depended on reward output, total staking and the prices used to value the position. A calculation from those inputs didn’t fix them for a year. A rising MDX price could increase the quoted value of a reward without increasing its token quantity. Rates from different periods therefore needed the same valuation basis before comparison.
Mining rewards didn’t remove liquidity exposure
Swaps changed the pool’s asset quantities, while market prices changed their value. A liquidity position could underperform holding the deposited tokens separately, even while accruing MDX. Network transaction costs and any costs of converting rewards also affected proceeds. A positive reward balance could coexist with a decline in the combined position’s value, so accrued tokens alone didn’t establish a profit.
Claiming MDX, withdrawing LP tokens and removing liquidity
A reward claim, a mining withdrawal and liquidity removal affected different balances. The historical desktop staking page included a withdraw all control covering both rewards and LP tokens. Receiving LP tokens still differed from receiving the paired assets that those tokens represented. Mining withdrawal released the LP stake; liquidity removal redeemed the pool share for underlying assets.
Boardroom’s fixed-term single-token MDX positions had separate lockup and voucher rules. Those rules didn’t automatically apply to LP liquidity mining. For an exit intended to recover the paired assets, holding returned LP tokens leaves liquidity removal outstanding. The recovered quantities reflect the pool’s reserves at removal, rather than a promise to restore the original deposit quantities.
Questions people ask about Mdex liquidity mining
Did making more swaps increase my LP mining share?
The liquidity mining calculation used eligible LP stake, while transaction mining rewarded eligible trading activity. Additional swaps didn’t themselves increase a wallet’s recorded LP stake. A trading reward belonged to its own program and eligible pairs. The platform’s dual mining description didn’t make trading volume interchangeable with the LP balance used for liquidity-mining allocation.
Does staking LP tokens qualify for xMDX governance vouchers?
LP mining alone didn’t satisfy the documented eligibility rule for xMDX governance vouchers. Those vouchers came from fixed-term single-token MDX lockups in Boardroom and required manual collection. The governance rules used vouchers for director elections and community proposal voting. Holding an LP token or earning MDX through liquidity mining wasn’t equivalent to holding the voucher required for those activities.
Why can unclaimed MDX differ from the wallet’s MDX balance?
Unclaimed MDX represents an accrued mining reward, while the wallet balance reflects tokens that the wallet already holds. Those figures describe different balances and needn’t match. A completed claim can move rewards into the wallet; a displayed accrual alone doesn’t establish that transfer. The recorded LP stake is another balance, so none of these figures should substitute for the others.
Can an ordinary token transfer establish an LP mining deposit?
An ordinary token transfer doesn’t confirm that a mining pool credited an LP stake. The historical staking workflow used the corresponding liquidity-mining entry to deposit the LP token. A transfer receipt establishes movement to a recipient, not the reward-accounting state. Tokens mistakenly sent to a contract without an asset-withdrawal function may remain unrecoverable, even when a wallet shows the completed transfer.
How could a new pair’s initial price affect liquidity supplied for mining?
The first liquidity provider set a new pair’s initial exchange ratio, which could expose a mispriced deposit to arbitrage. A ratio that differed from the market allowed traders to exploit that difference. MDX incentives didn’t determine the initial ratio or establish that creating the pair qualified it for rewards.
Could a node delay hide an LP balance in my wallet?
A node delay can produce a stale or missing wallet-asset display without proving that the LP tokens moved. Switching a remote procedure call (RPC) endpoint can help when a particular node fails to report network data. That changes the connection used to read chain state. It doesn’t restore a discontinued network or guarantee recovery of an affected HECO position.