The fastest DeFi, #SSS public beta is now live!
CEX experience, DEX trust.
$200,000 Reward!
Welcome to have a try and feedback!
Home: https://www.sssdefi.ai/
canister link: https://bpfil-eiaaa-aaaad-qlkrq-cai.icp0.io/
App: https://app.sssdefi.ai/
canister link: SSS · DeFi v3
#ICP #DeFi #CEX
Check the Litepaper v2.0
Okay, cool but who are you? Is this KongSwap remake? 
How do you expect to have users test this with real money using test URLs and no information on the team.
The joker has resurfaced…. Now speaking of a hero in negative light.
Evan don’t worry I’ll handle this joker.
Where this money coming from, its not 200 usd, its 200k usd.
Thank you. Very fair question — and honestly, after everything that has happened in ICP DeFi recently, people should ask it. We also wanna take the chance to express our points.
A few direct points from our side.
First, these are not “test URLs.” This is a public beta, live on ICP, and people can verify that by using the product itself.
Second, on the “who are you / no team info” part: I understand the concern, but I also want to be very direct about our view.
In crypto, public team identity can help, but it is not the essence of trust. Satoshi did not start Bitcoin by putting up a team page either. What ultimately matters is not how many faces are shown, but whether the product has real value, whether the system design makes sense, whether the records are clear, and whether users can verify outcomes for themselves.
That is exactly how we think about SSS.
Recent events around KongSwap were a major blow to ICP DeFi, and also a reminder that team disclosure alone does not solve the core problem. We do not say this as criticism. In fact, KongSwap also proved that ICP users do want DeFi with richer features and stronger user experience.
Our difference is that SSS was never designed as “just another DEX.”
From day one, our ambition has been to build a trading system.
If we look at the past 17 years of crypto, the biggest winners from a wealth and usage perspective were not blockchains themselves, but centralized exchanges — especially Binance. That sounds ironic for an industry built on decentralization, but it is the truth. And if we want DeFi to truly return to its original promise, then we have to face that truth.
to build, on a decentralized public chain, a trading experience that can approach the usability and efficiency of a CEX, while keeping the transparency, auditability, and on-chain verifiability that centralized exchanges cannot give users.
We are also very clear-eyed about where we are today.
SSS is not in its final decentralized form yet. At the current stage, the most important thing for us is to carefully balance decentralized security and centralized efficiency, and to earn trust not by over-promising, but by real product design:
clear on-chain records, clear receipts, clear boundaries, verifiable outcomes, controllable risk when problems happen, and a system that is designed around users rather than slogans.
So no, SSS is not a KongSwap remake.
And no, we do not believe people should trust us just because we publish team bios.
We believe trust should come from value, product quality, design philosophy, transparency, and what users can verify with their own eyes.
That is also why we did not rush this out as a concept. We spent more than a year building before opening public beta, and only did so after we believed the product was complete enough and the risks were within a controllable range.
So my honest suggestion is simple:
don’t decide based only on analogies, labels, or fear from another project’s outcome.
Spend 3 minutes, try SSS with a very small amount, and judge the product directly.
If after that you still think it is “just another DEX,” that is completely fair.
But I think once you actually use it, you will understand why we believe SSS is trying to solve a different problem.
If you lied about rewards, its over, no matter what you built. Trust is everything.
SSS is not something we put together to “take advantage” of Kong’s sunset. We’ve been building it for more than 1 year. And have publlished v2 month ago
On security: that’s a fair question. Trust should come from product design, clear boundaries, on-chain records, and what users can verify directly — not from rumors or personal attacks.
If you have specific security concerns, feel free to raise them one by one. That’s a much better discussion.
Good question, and we should clarify this more precisely.
This is not a pre-funded $200k cash pool sitting there waiting to be distributed.
It is the cap of the referral reward program, and the rewards come over time from actual trading-fee sharing generated by referred users’ activity.
User trust comes first for us, so we’d rather explain the mechanism clearly than use wording that can be misunderstood. We’ll update the wording.
Heads up to anyone trying this, when you connect via Plug Wallet, SSS requests a Global Delegation, not a scoped one. That’s worth understanding before you approve it.
Scoped delegation (what most dApps use): The dApp can only call canisters listed in a specific whitelist, typically just its own backend. This is the standard, safe approach.
Global delegation (what SSS requests): No canister restrictions. The dApp’s session key can make calls to any canister on the IC as your identity, including every token ledger you hold balances on.
In practice, that means if you approve this, the dApp could call icrc1_transfer on any ICRC-1 ledger as you and move your tokens wherever it wants, with no further approval needed from Plug.
There’s no legitimate performance reason for a DEX to need this. Scoped delegations already allow instant trade execution without per-transaction popups. A properly integrated dApp uses requestConnect with a whitelist and createActor through Plug’s API. Global delegation bypasses all of Plug’s built-in security filtering.
Maybe the SSS team just didn’t integrate Plug properly and this is an oversight rather than anything malicious, but either way, I’d hold off on approving it until they fix their integration to use scoped delegations. Or at minimum, use a fresh wallet with funds you’re comfortable losing.
References for anyone who wants to dig deeper:
Thanks for flagging this — we reviewed it carefully across Plug, II, and NFID.
You were right to raise it. The current Plug login flow can result in a broader delegation prompt at runtime than we intended. That is not acceptable for a real-money product, so we are treating it as a top-priority security fix.
To be clear:
We are now disabling / restricting Plug until the integration is corrected, and we are re-validating all login modes again. We will also publish a clearer note explaining the auth boundary for Plug, II, and NFID.
This is exactly why SSS is still in public beta: we want real scrutiny, real feedback, and real verification from users before moving further.
We also welcome feedback through the in-app Feedback entry, OpenChat, Telegram, X/Twitter, and the forum. Helpful feedback like this is valuable to us, and as the project grows successfully, we absolutely intend to recognize and support meaningful contributors where we can.
Thanks again — this was a useful catch, and exactly the kind of public review that helps make the product stronger.
Thanks again for reporting this. We reproduced the behavior and completed a fix within 24 hours.
After investigation, the issue was not in the backend or in asset custody itself. It was caused by the way Plug was previously integrated on the frontend through the IdentityKit signer delegation flow. Under that runtime path, Plug could show a broader Global Delegation permission prompt and, on first login, trigger an extra authorization step.
This was a frontend authorization-scope issue in the Plug login flow, not a case of funds being moved or user assets being put at risk.
We have now changed the Plug login flow to use Plug’s native connection path with a restricted canister whitelist. In practice, this means the authorization scope is now much clearer and tighter for users, and the previous global-style delegation prompt should no longer appear.
We also cleaned up the wallet login flow overall:
Most importantly, this was an authorization-prompt / frontend integration issue, not a case of user assets being transferred or exposed.
We really appreciate the report. It helped us identify and fix the issue quickly during public testing. Please feel free to test again, and keep sending feedback through the site, OpenChat, Telegram, X, or the forum.
