Makiswap used HECO liquidity pools for swaps, with each position change recorded on-chain

How each Makiswap path changed wallet state

A swap changes one wallet asset into another, liquidity provision exchanges two assets for a pool position and farming deposits an eligible position into another contract. Those paths may begin in a similar interface, yet they create different records and exit requirements. The correct path is the one whose final on-chain state matches the task.

For a swap, completion means that the input was spent and the output reached the selected address. Providing liquidity creates a claim on pooled reserves, commonly represented by liquidity provider tokens. Farming adds another layer because those position tokens leave the wallet and enter a farm contract. A user who expects a simple token balance should not treat a staked position as missing funds.

The starting wallet state defined the baseline

A useful starting record contained the connected account, selected network, input balance and enough native currency for network fees. This snapshot gave later balance changes a clear baseline. It also exposed a setup error: the wallet could display the expected address while connected to another network.

Token identity matters as much as the displayed symbol. Different contracts can use the same name or ticker, so the contract address and decimal handling define the asset that the transaction will move. The proposed transaction should also identify the intended contract. If the network, account or contract differed from the expected starting state, the transaction should not have been signed. A later receipt could not correct a transaction sent to the wrong contract.

The documented swap lifecycle from quote to receipt

Makiswap's documented swap flow moved through preparation, authorization, execution and reconciliation. Authorization was unnecessary when the wallet already had a sufficient allowance.

Before a signature

The quote describes an expected exchange at the pool state used for that calculation. It can change before execution because another trade may alter the reserves. The transaction request is therefore the commitment boundary, not the earlier screen alone. Before signing, a user needed to review the input amount, expected output, recipient, network fee and any minimum-output condition encoded by the router.

Allowance transaction

A standard token approval grants a specific spender permission to use an amount from the wallet. Approval is a separate state change and does not complete the swap. Its receipt should identify the approval transaction, while the input and output balances normally remain unchanged. An unlimited allowance has a wider future scope than an exact allowance, so that distinction belongs in the signing decision.

Swap transaction

The swap call asks the router and pool contracts to execute under the submitted conditions. Wallet confirmation signed and submitted the request, but it did not prove that the network accepted, included or successfully executed it. Once included, the receipt status distinguishes successful execution from a reverted call. A reverted transaction does not settle the requested exchange, although the network may still charge gas for processing it.

After a receipt

Reconciliation compares the starting record with the receipt and the refreshed wallet state. Check the input decrease, output increase and native balance reduction for gas. The transaction hash anchors this review to one operation. If the interface remains stale, the receipt and token balances provide stronger evidence than an unchanged animation or notification.

What does a successful Makiswap swap prove?

A successful receipt proves that the submitted transaction executed on its recorded network, subject to the contract logic and conditions inside that transaction. It does not certify the asset's identity, future value or suitability. It also does not show whether a different quote would have offered a better result.

Read the receipt beside the balance changes. The status answers whether execution succeeded, while transfer records and final balances answer what moved. A transaction can succeed even when the economic result disappoints the user, provided it remained inside the submitted limits. Use the receipt to assess execution and the settled amount to assess the economic result.

Reconciling the quoted and settled amounts

The settled amount should be compared with the quote that was visible immediately before signing, not with an earlier estimate saved while reserves had a different state. Price impact comes from the trade changing the pool ratio. Slippage reflects movement between quotation and execution, while the transaction's minimum-output condition sets the permitted range.

First confirm that the input amount matches the signed request. Then identify the output transfer and compare it with the transaction's minimum acceptable output where that value is available. A final amount below the original estimate may still be valid if it stayed within the signed condition. An amount outside the encoded condition should cause the call to revert rather than settle as an unrestricted trade.

Wallet displays sometimes cache balances or omit an unfamiliar token. Refreshing the account view can resolve a presentation delay, but it cannot change settlement. The on-chain receipt and the relevant account balance determine whether the output arrived.

View image file

Liquidity pools supplied the swap route

Makiswap was built as an automated market maker on HECO. Its pools held paired token reserves that supported exchanges without a conventional order book. The reserve relationship supplied each quote, while an executed trade changed the pool state for the next transaction.

Liquidity providers contributed both sides of a supported pair and received tokens that represented their share. That position was not a fixed claim on the original quantities. Pool reserves changed as traders swapped, so a later withdrawal could return a different mix of the two assets. Fees could accrue to the position under the pool rules, but they did not remove the risk created by changing relative prices.

Evidence for an earlier deposit includes both deposited amounts, the pool contract and the resulting position balance. Removing liquidity converted the pool position back into its underlying assets. It was a different action from swapping one token directly for another.

Yield farming added another contract position

Yield farming began after an eligible liquidity position existed because the documented flow staked liquidity provider tokens rather than the two underlying assets. The wallet could therefore show fewer position tokens after a successful farm deposit. The farm record should show the corresponding historical stake.

Harvesting rewards, adding to a stake and removing a stake were separate transactions. Unstaking returned the position token to the wallet; it did not automatically split that position into its underlying assets. A full exit required the position token to be available first, followed by a liquidity-removal transaction. Missing that distinction could make an incomplete exit look complete.

Farm availability and reward settings could change independently of the underlying pool before HECO retired. An archived farm listing does not prove that deposits or rewards remained enabled at a given time. The documented approval and deposit flow is no longer available for new transactions.

Costs that changed the final wallet balance

The economic result combined the pool exchange, the swap fee encoded by the contracts, price impact and the network fee paid by the wallet. These components appeared in different places. The quoted output reflected pool execution, while gas reduced the native-currency balance separately.

Old fee descriptions should not replace the values recorded in the transaction that actually ran. Contract configurations and available routes could change. Compare the submitted amounts and the wallet's network fee estimate with the receipt. A failed call could still consume gas because validators processed it even though no swap output settled.

Keeping a separate gas reserve reduced the risk that an account could not submit the next transaction. The documented workflow could require approval before a swap or unstaking before liquidity removal.

A missing balance can indicate several states

For a historical record, a missing output may reflect a reverted transaction, a transaction that was never confirmed, the wrong network, an unlisted token or a successful transfer to another recipient. Each state leaves different evidence, so the records must be resolved before drawing a conclusion.

Start with the transaction hash. No hash usually means the wallet never broadcast the request. A hash without a final receipt does not prove settlement. A failed receipt means the intended contract call did not complete. For a successful receipt, inspect the recipient, relevant transfer records and final balance. If those records show the expected token transfer, an absent wallet display may reflect a missing token entry or stale balance.

Liquidity and farming create another possibility. The expected value may exist as a pool position or farm stake rather than as a freely spendable token balance. Check the last successful action before deciding which balance should have changed.

Checklist for interpreting an earlier transaction

Treat an earlier transaction as complete only when its receipt and balance changes form a consistent record.

• Confirm that the recorded account and network matched the intended HECO starting state.
• Match every recorded token to its intended contract rather than relying on its symbol.
• Compare the approved spender, allowance amount and swap conditions with the intended request.
• Verify the receipt status and compare both asset balances with the recorded baseline.
• Resolve any missing output, unexpected recipient or unexplained balance change before concluding that the transaction succeeded.

Consistent records support a conclusion about what happened. Conflicting records leave the outcome unresolved.

Exit records completed the reconciliation trail

An exit was complete only when the assets reached the intended state. A swap ended with the output in the recipient account. A liquidity exit ended after position tokens were redeemed. A farming exit could require unstaking, confirming the returned position and then removing liquidity.

Transaction hashes for each state change keep separate signatures from being mistaken for one operation. They let a reader verify which step approved spending, where assets moved and whether a later step failed. Before HECO retired, revoking an unused allowance could narrow future contract access, but revocation required another on-chain transaction and its own successful receipt.

Final balances complete the historical reconciliation. When the account, network, receipts and assets agree, the records show whether the resulting tokens stayed in the wallet or moved into another supported position.