Makiswap Makiswap Liquidity Pools turned paired HECO deposits into proportional LP shares with fee-linked withdrawal value
Updated
Makiswap Liquidity Pools gave providers LP tokens that represented a share of two deposited HECO assets. That share set the provider's portion of pool reserves and the liquidity-provider fee allocation. With HECO's retirement announced for January 15, 2025, these comparisons now concern historical positions rather than new deposits.
Table of contents
In short: Pool share, swap activity and the withdrawal-time reserve mix determined what a historical Makiswap liquidity position returned.
Historical pools differed through asset exposure and trading activity
Two pools using the same fee schedule could produce different provider outcomes. Each pair had its own reserve balances, swap activity and price path. A provider also entered at a particular reserve ratio and owned a particular fraction of that pool's LP token supply. Those variables affected fee income and the assets available at withdrawal.
Compare positions over the same interval and with the same valuation point. Record both deposited quantities, the LP tokens received and total LP supply at entry. Then match them with any later additions, transfers and removals. A pool that processed more swaps could collect more fees, yet a smaller ownership share or a less favorable reserve mix could leave a lower net value.
The pair identity matters as much as the percentage. Records from different pair contracts cannot form one continuous position.
LP tokens connected each deposit to a proportional claim
A Makiswap liquidity deposit used two tokens supplied at equal value for the selected pair. After one amount was entered, the interface calculated the matching quantity from the pool state. The completed deposit issued LP tokens. They represented a share of liquidity rather than a fixed quantity of either asset.
Share was relative: LP tokens controlled by a provider divided by the outstanding LP token supply at the same point. An LP balance therefore needs its matching total supply and block context. Two pools could issue different token counts for economically similar deposits, so raw LP balances were not a cross-pool ranking.
Removing liquidity redeemed LP tokens for the corresponding portion of the current reserves. The withdrawal did not promise the original token quantities. Swaps had already changed the reserve mix, while later deposits and removals had changed the pool's scale.
The fee split separated pool income from the developer allocation
Makiswap charged 0.2% on swaps under its historical fee schedule. The charge was divided between liquidity providers and a developer fund.
The historical fee schedule assigned 0.17% of each swap amount to liquidity providers. The remaining 0.03% went to the developer fund, outside the pool provider allocation. Those figures are percentage points of swap value, not promised returns on deposited capital.
A provider's fee income depended on eligible swap activity while the position existed. The provider's contemporaneous pool share then determined its fraction of the LP allocation. If a pair recorded no swaps during an interval, this fee mechanism produced no income for that interval. A large pool balance alone did not create trading fees.
For each input token, where recorded swap volume is V and the provider's share stays s, the gross historical allocation is V × 0.0017 × s. Apply the formula separately to each input token unless V already expresses both sides on one consistent valuation basis. If share changed, divide the period at each mint, burn or transfer and calculate each interval separately. Network costs belong below that gross figure. Farm rewards also require a separate line because they did not come from the swap-fee split.
Later deposits changed ownership percentages without changing the fee rate
New liquidity expanded reserves and minted additional LP tokens. An existing provider's token count stayed unchanged unless that address acted, but its percentage of the enlarged supply changed. A proportionate deposit also enlarged the asset base, so a lower percentage did not by itself prove a loss in claim value.
The reverse occurred on a partial removal: reserves and LP supply fell together as tokens were redeemed. Fee calculations after that block used the remaining share. Endpoint snapshots miss this history when deposits, removals or LP transfers occurred inside the comparison period.
Pool comparison works best with intervals between ownership-changing events. Each interval needs a starting LP balance, total supply and swap activity. This avoids treating a temporary larger share as though it lasted for the entire position.
Withdrawal value followed the reserve mix at exit
Liquidity removal returned the current quantities of both pool assets. It did not restore the deposit as two unchanged balances. Swaps shifted quantities between reserves, while outside market prices changed the value of those quantities. The provider's proportional claim could remain intact even when its composition differed from the original deposit.
To measure the pool outcome, value both withdrawn assets at one consistent endpoint. Then add any remaining claim and subtract transaction costs. Compare that figure with the same starting assets held separately over the same period. Valuing the pool at one time and the holding alternative at another confuses market movement with liquidity performance.
The difference between the pooled result and the holding alternative is commonly discussed as impermanent loss. Fee income could offset some or all of that difference, but the 0.17% allocation did not guarantee that it would. The outcome depended on relative prices, swap activity, ownership share and costs.
A higher withdrawal value could come from asset appreciation rather than superior pool economics. Quantity records keep those causes separate.
Staked LP tokens created a separate exit dependency
Makiswap allowed eligible LP tokens to enter yield farms. Staking moved those tokens from the wallet into a farm contract while the underlying pool claim continued to exist. The wallet's visible LP balance could therefore fall to zero without a liquidity removal. Farm rewards remained separate from the pool's trading-fee allocation.
The historical exit order first returned LP tokens from the farm, then removed liquidity through the pool. That dependency matters for reversibility. If the LP tokens were still recorded in a farm, a pool removal was not the next valid action. If contract or network access was unavailable, repeated removal attempts could not replace the missing unstake step.
Historical transaction records can distinguish staking, unstaking and liquidity removal. A successful stake receipt shows why LP tokens left the wallet; a successful unstake transaction should return them to the wallet; a successful removal should reduce the LP balance and return both pool assets. A failed or missing stage leaves the position unresolved rather than proving a zero balance.
Five checks determine whether historical positions are comparable
A comparison is reliable only when both positions have matching identity and time coverage. Use this checklist before drawing a fee or withdrawal conclusion.
- Match the pair contract, wallet and HECO network across every recorded event.
- Calculate share from the LP balance and total supply at the same block.
- Apply the 0.17% provider allocation without including the separate 0.03% developer portion.
- Split the analysis at every deposit, partial removal or LP token transfer.
- Locate any farm deposit and unstake records before treating wallet-held LP tokens as missing.
When every item is available, calculate intervals and compare exit quantities on one valuation basis. If pair identity or total supply is missing, the share cannot be reconstructed confidently. If farm custody is the only missing link, resolve that state in the record before interpreting a pool withdrawal.
The announced HECO retirement date frames pool comparison as historical reconciliation
The HECO Network's announced retirement date was January 15, 2025. Historical Makiswap mechanics do not establish that new deposits or withdrawals remain available. A surviving screen, token symbol or quoted percentage cannot prove current contract access.
Use preserved transaction hashes, receipts, LP transfer events and balance records when compatible access exists. A successful receipt can establish that a state change executed, while paired asset balances show the economic result. If no compatible archive or node exposes the relevant state, the exact historical share remains unresolved. The withdrawal result also remains unresolved unless receipts or transfer records show the returned assets. An interface estimate cannot fill either gap.
The clearest alternative is holding the same two starting assets separately. Use the same start, end and valuation basis for both positions. This isolates the pool's fee allocation and reserve changes from general asset-price movement. It also keeps a historical Makiswap comparison grounded in recoverable records rather than a presumed live opportunity.
Quick answers about Makiswap Liquidity Pools
Could transferred Makiswap LP tokens carry the pool claim to another address?
A transferred Makiswap LP token moved its represented pool claim to the receiving address. The sender's claim decreased with the transfer, while the receiver controlled the corresponding tokens. If a farm contract received them, the contract held the LP tokens until unstaking returned them. An approval alone did not transfer the balance.
Does a partial removal end the entire liquidity position?
A partial removal did not end the entire liquidity position when LP tokens remained. It redeemed only the selected portion and left the balance as a claim on the remaining reserves. Historical analysis should close one interval at the removal block, then open another with the reduced LP balance and updated total supply. Later fees applied to that remaining share until another ownership-changing event or the final removal.
When should the two withdrawn assets be valued for a fair comparison?
Both withdrawn assets should be valued at the same endpoint used for the holding comparison. A common timestamp and price basis prevent a later market move from appearing as pool income or loss. If withdrawal occurred through several transactions, value each amount at its transaction time or carry every amount to one stated endpoint consistently. Apply the same method to both alternatives.
Is a failed removal transaction proof that pool assets returned?
A failed removal transaction does not prove that either reserve asset returned to the wallet. A failed receipt indicates that the contract state change did not execute, although the account may still have paid a network fee. Match the receipt status with the LP token balance and both asset balances for the same account. A pending transaction remains unresolved until a final receipt or replacement transaction establishes its outcome.
Were farm rewards included in Makiswap's 0.17% liquidity-provider allocation?
Farm rewards were separate from Makiswap's historical 0.17% liquidity-provider share of swap value. Pool fees arose from swaps in the pair and followed pool ownership, while farming required depositing eligible LP tokens into another contract. A historical return calculation may include both, but it should list them separately. Combining them hides whether the return came from trading activity, token emissions or asset-price changes.