KongSwap’s Exit Problem Is Bigger Than a Missing Button

A September 13 discussion on the Internet Computer Developer Forum asks a practical question with serious custody implications: how can users withdraw tokens from KongSwap after hearing that the exchange had closed? The thread contains no confirmed answer or official shutdown notice. It documents an unresolved user report—not proof that every KongSwap balance is inaccessible.

That distinction matters because KongSwap’s published architecture places both its frontend and backend in canisters. Its whitepaper describes liquidity positions, token balances, removal of liquidity, and a claims mechanism as on-chain functions. In principle, a missing or unavailable web interface should not automatically mean that assets have vanished. In practice, users still need the correct canister, method, account format, and current contract state before attempting any recovery action.

There is also a separate infrastructure warning. A DFINITY repository currently notes that KongSwap’s former source repository disappeared and points to a pinned backend WebAssembly artifact hosted on DFINITY’s CDN. That is evidence of a changed software distribution path, not evidence of a shutdown or a successful withdrawal route.

For developers and users, the immediate lesson is to treat the frontend as an access layer, not as the source of truth. Before signing anything, reconcile three views of the same position: the token ledger balance, the KongSwap canister’s recorded position or claim, and the transaction history. Use only canister identifiers and interfaces obtained from authenticated project documentation, governance records, or independently verified source code. Do not use wallet addresses, recovery links, or “support” contacts posted by strangers in a forum thread.

A safe recovery guide would need to identify the official backend canister, publish the exact withdrawal or liquidity-removal interface, explain whether claims are pending, and show how users can verify the resulting ledger transaction. None of those details is established by the current discussion. Until they are, the responsible answer to the forum question is not to guess at a command—it is to preserve evidence, avoid new approvals, and demand a verifiable exit path.

The broader ICP development issue is architectural: on-chain execution can preserve state, but it does not by itself guarantee discoverability, user support, or a usable recovery workflow. Those operational guarantees must be documented before users deposit funds.