On July 28, 2026, SSS DeFi identified a security incident affecting the β2.0 concentrated liquidity feature.
The investigation has confirmed that there was an inconsistency between CLMM position creation and exit calculations, which allowed the attacker to create abnormal liquidity entitlements and transfer out real assets from the affected liquidity pools.
After the incident occurred, SSS immediately suspended core functions involving fund movements, including withdrawals, swaps, and new liquidity additions, and initiated system isolation, asset-by-asset reconciliation, vulnerability remediation, security auditing, and cross-chain fund tracing.
We apologize to our users and the community for this incident. The fact that SSS is still in an early stage does not reduce the team’s responsibility. The recent pace of rapid iteration increased system complexity and change risk. This is an engineering responsibility that the team must face and bear, not an excuse for the incident.
I. Confirmed Impact So Far
Based on the asset-by-asset reconciliation completed so far:
- The value of assets confirmed to have been transferred out of SSS is approximately US$9,200;
- User assets will not be reduced because of this incident and remain 100% covered by the remaining reserves;
- The confirmed losses will be borne by the SSS team and will not be passed on to users;
- If any verified user loss is identified later, the team will make it whole in full.
The current suspension of business is a proactive security measure.
II. Actions Taken in the First 48 Hours After the Incident
Over the past 48 hours, SSS has completed or initiated the following:
- Suspended withdrawals, swaps, and new liquidity additions;
- Isolated the related accounts, positions, and abnormal fund paths;
- Blocked the known CLMM exploit path;
- Reconstructed the complete internal attack execution sequence;
- Confirmed 19 abnormal Open/Burn groups, 3 internal USDT reallocations, and 4 related Principals;
- Completed closed-form reconciliation for 7 affected assets at the smallest atomic-unit precision;
- Matched 58 confirmed successful withdrawals one by one to external ledger or public-chain evidence;
- Traced the stolen outbound assets to their last verifiable locations on Bitcoin, BNB Chain, and Solana;
- Reverse-traced the attack preparation funds through their full path into ICP via Ethereum, Uniswap, and OneSec;
- Initiated a systematic audit of Core, Gateway, the permission system, the withdrawal state machine, and all fund entry and exit paths.
These results do not mean that the investigation has ended, but they are already sufficient to confirm the attack mechanism, scope of impact, and main asset flows.
III. Current System Status
At present:
- The known exploit path has been blocked;
- The related accounts and abnormal positions have been isolated;
- User liabilities remain fully covered by sufficient reserves;
- BTC, BNB, SOL, and the related ETH addresses are under continuous monitoring;
- The comprehensive security audit and recovery acceptance process are still ongoing;
- Core business functions involving fund movements remain suspended.
SSS will not rush to reopen the system because of market pressure or the speed of recovery.
Only after all Critical and High issues have been closed, asset-by-asset reconciliation has passed again, historical attack replays fail, and concurrency and fault-injection tests pass will the system enter a limited canary recovery phase.
IV. Strengthening the Risk-Control System
This incident exposed not just an isolated function issue. It also showed that during rapid iteration, mathematical invariants, fund exits, and abnormal risk controls still need to be further institutionalized.
SSS is turning the following controls into long-term system capabilities:
- Using unified and verifiable mathematical boundaries for CLMM creation, addition, exit, and collection;
- Setting per-withdrawal limits, periodic limits, and abnormal-rate guardrails for each asset;
- Connecting all fund exits to a unified suspension, isolation, and manual review mechanism;
- Using a unique, idempotent, and recoverable state machine for external payments;
- Ensuring that financial facts are confirmed only by Core, and that the frontend and external Gateway cannot become accounting authorities;
- Further minimizing high-risk permissions and isolating them from day-to-day operating identities;
- Requiring every core financial change to pass historical attack replay, concurrency testing, and fault-injection testing;
- Requiring asset-by-asset reserve verification and production Wasm binding before business recovery;
- Establishing continuous on-chain reserve monitoring, abnormal alerts, and an incident-response process.
SSS will later disclose how these controls are implemented and accepted, rather than simply making vague claims that the system is “more secure.”
V. Asset Recovery and Dialogue With the Attacker
SSS has already reconstructed the attack process and confirmed the main on-chain flow paths of the affected assets.
We prefer to resolve this incident through dialogue and voluntary return, and we have opened an official communication and asset-return channel:
https://about.sssdefi.ai/security/incident-20260728/contact
SSS is willing to discuss a conditional security bounty, capped at no more than 10% of the returned value and no more than US$1,000, provided that at least 90% of the traceable assets are returned.
This proposal is conditional on the assets being confirmed as received. No bounty will be paid in advance, and this does not mean that SSS can bind law-enforcement authorities or promise criminal immunity.
If there is no constructive response, SSS reserves all rights to:
- Continue tracing and preserving on-chain evidence;
- Cooperate with cross-chain bridges, exchanges, custodians, and infrastructure service providers;
- Request freezes and preservation when the assets enter controllable platforms;
- File formal reports with competent authorities;
- Pursue asset recovery through applicable civil, criminal, or judicial procedures.
We also welcome security researchers, developers, and community members to help share the official contact page above.
VI. SSS’s Goals and Responsibilities
SSS is a complex and challenging DeFi system. It is the first to innovatively adopt an architecture that combines an internal ledger with multi-chain execution, with the goal of preserving decentralized asset control while delivering speed, privacy, and user experience close to that of professional trading systems.
SSS aims to build more than just another DEX. It aims to build a decentralized private trading system for the AI era, with the goal of becoming a top-tier global DeFi platform, while adhering over the long term to: Safe, Simple, Swift.
This incident shows that innovation and speed cannot replace security proof. Truly reliable DeFi must be built on:
- Clear financial invariants;
- Minimal permissions;
- Fail-closed design;
- Verifiable reconciliation;
- Transparent incident handling;
- Responsibility for user funds.
The team will continue advancing this mission, but with stricter engineering discipline, risk control, and public acceptance as prerequisites.
VII. Community Participation and Early Contributions
SSS welcomes white-hat security researchers, ICP developers, test users, and community members to submit the following through the official channel (https://docs.sssdefi.ai/security):
- Security vulnerabilities;
- Risk scenarios;
- Test cases;
- Product suggestions;
- Documentation improvements;
- Community-building contributions.
Valid contributions will be recorded under the existing XP system.
In the whitepaper currently being drafted, SSS plans to make XP one of the important bases for identifying and rewarding early contributors in future tokenomics and governance design. Specific eligibility, ratios, vesting arrangements, and compliance rules have not yet been finalized, and nothing here constitutes a definitive token-allocation commitment.
Security contributions will be evaluated and rewarded independently, and there is no need to prove vulnerabilities through actual attacks or by moving user assets.
VIII. Next Steps
SSS will proceed in the following order:
- Complete the comprehensive security audit;
- Close all Critical and High issues;
- Continue fund monitoring and asset recovery;
- Complete asset-by-asset solvency verification;
- Publish a complete technical postmortem and security-hardening report;
- Conduct a strictly limited small-amount withdrawal canary;
- Gradually resume withdrawals by asset;
- Restore swaps and order functions;
- Finally restore liquidity-related operations.
Thank you to our users, developers, and the ICP community for your supervision, feedback, and support.
SSS DeFi Team
(Source: https://about.sssdefi.ai/blog/sss-defi-0728-security-incident-initial-announcement-en)