First, the issue is that every time a large transaction is made on ICPSwap, it is often intercepted by bots. This leads to significant losses for large users, especially those conducting multiple high-volume transactions, which greatly increases their costs. The existence of such bots has been a long-standing problem, yet the ICPSwap team has not made any changes to address it. On the other hand, Kongswap has not experienced such issues.
2 Likes
Secondly, the speed on ICPSwap is too slow, and the entire transaction process takes a long time, resulting in a poor user experience. Additionally, if the tokens remain in the liquidity pool, the user’s balance is not displayed in the personal center, making it difficult for users to track which tokens they still hold.
Furthermore, the platform is currently solely focused on collecting transaction fees from users without assuming the corresponding responsibility. When users experience transaction failures on the ICS platform and do not receive their tokens in a timely manner, the project team only takes action hours later to restore the transaction, looking for excuses to avoid their responsibilities as the platform operator. They ignore the losses users incur due to the failure of token transfers. For instance, after the Boom transaction issue that occurred a few hours ago, there has been no follow-up response.
@ICPSwap As the largest DeFi project on IC at the moment, please pay more attention to user transaction security and ease of use. Do not ignore the users. The current price of $ICS proves that there is still progress to be made.
Than put tokens to pool first, use very small slippage, and than make trade. After that pull tokens out of pool again. Or just DCA in and out with small transactions.
New upcoming upgrade will make swap faster, do you even follow theyr updates?
If tokens get stuck, they need to make proposals to get tokens back, yes it takes some time, but users always get tokens back.
Token price has nothing to do with product 
1 Like
Dear Sir,
Thank you for raising these important concerns.
Since we are using Swap V3, which allows setting price ranges and corresponding liquidity, the computational workload is much higher. If we were to use a single canister for all pairs, instead of each trading pair having its own canister, the system would experience severe delays due to the increased computation load. Additionally, to ensure asset security and independent operation for each trading pair, we opted for the current architecture.
This greatly improved scalability and performance. But there’s a trade-off — while a single canister can easily access all balances, cross-canister communication (reading balances and executing trades across pairs) is naturally slower.
In addition, ICPSwap’s current subnet (lhg73) is under high load, which may also be contributing to slower transaction speeds. The good news is: we’ve now made it possible to deploy new trading pair canisters on lighter subnets. For example, here’s a new pair deployed on the pzp6e subnet:
https://dashboard.internetcomputer.org/canister/tirbb-diaaa-aaaar-qbldq-cai
That said, we haven’t stopped optimizing. In version 3.6, we’ve made meaningful breakthroughs, and the issues you mentioned may very well be resolved in this update. The ICPSwap 3.6 code has now been officially submitted to the audit firm for a full security review — and we’ll be announcing it publicly on X soon.
As for the issue with the BOOM token — yesterday there was a brief stopped caused by the BOOM token canister(https://dashboard.internetcomputer.org/canister/vtrom-gqaaa-aaaaq-aabia-cai) running out of cycles. Without cycles, the token can’t interact with the pool, which led to funds being stuck. The team acted immediately by submitting a proposal, and the issue was resolved promptly after it passed. Our admin also followed up with you via DM to make sure everything was addressed.
We’ll keep improving this — there’s still room to make it better.
Finally, we truly appreciate your feedback. You’re absolutely right — user safety and experience are our top priorities.
We’ll continue pushing forward on all fronts, and we won’t lose sight of what matters most.
Thanks again for being part of the $ICS journey! 
3 Likes
Dear @Henn91 Big thanks for lending a hand!
2 Likes
The users don’t need excuses, they need a secure and reliable transaction process. When users encounter issues during transactions on your platform, shouldn’t you show a responsible attitude towards those transactions? The objective reason is not that you have no responsibility, but rather that the platform should take accountability for the security and reliability of the transactions.
The price also reflects the users’ attitude towards the project team, my friend.
So why not blaiming the whole ICP infrastructure for the low price?
If you are invested into icps the try to help instead of fudding.
In case u dont like ICPS just use KongSwap and stop fudding.
If BoomDAO did not top up its token canister with cycles, then yes, need to ask BoomDAO team to top up. When canister working again, than ICPSwap can return tokens. Even if Boom team deletes token canister, ICPSwap cant do anything about it and has no obligation to refund as platform only offers swap services.
No, it does not, price pumps only shows if there are whales who pump and dump on you. When eventually ICP price goes up, whales can pump ICS even more. Market cap $1.73M, circulating supply 281.06M, low risk. 
1 Like
@ICPSwap for the time being, maybe could ban the bot directly? I really do not want trade there because of the bot. or maybe you should speed up the audit of version 3.6
You cant really ban bots, if you do small amount trades, bots dont really matter. If bigger amounts, than set low slippage % and send tokens to pool first.
Usually bots try to slip in with low liquidity pools. Even without bots you never want to buy too much as you get way less tokens. Better make limit order when buying.
1 Like
It feels like every time issues arise, the blame is shifted to users instead of the platform taking responsibility. There always seems to be an excuse, and that’s disheartening.