SONIC has vulnerabilities, leading to the depletion of the pool, causing a significant drop in the ICP ecosystem. Hackers directly extracts tokens from Sonic’s pool， sell ecosystem coins and buy assets such as ckBTC and ckETH
hacker ：
Formal verification.. coming to ICP via KINIC soon 
More specifically, when Zurich wakes up.
Vibe coding is already an old trend. Vericoding is the new trend.
Agents can make code 10x faster than humans.. but no human can make sure it works..
Almost 80% of vibe code has bugs.. this breaks the Caffiene thesis as ‘tamperproof’ code.
But there is a solution that is both more marketable and tech savvy. Its called vericoding.
It works really well with Motoko. This is vibe coding with formal methods resulting in proofs.
For all possible inputs of the spec, it cannot get hacked.
Small lifts technically! BIG lifts for everyone else.
Why doesn’t Kinic make a dex themselves? Everyone trusts Kinic
Attack Is ongoing. If you try to swap on Sonic, 3 steps from the transactions will go through, on the last 4th transaction - funds leak out of Sonic straight to his wallet before funds reach your wallet.
It’s a leaking bucket. What a mess.
I don’t why I’m almost sure this was an Inside job.
Sonic founder drained SonicDex a while ago. It is abandoned for a long time, no team response nothing.
Then the owner started building the same dex but on Solana.
Now when he probably herd about MultiDex, he decided to nuke his whole platform. This is 100% and inside job.
Last proposal on his SNS is shady also.
That’s my hunch.
All hacks are 99% always team members.. They know the codes..
looked into it a bit, and the pool canisters are not controlled by the DAO, so anybody with control could have upgraded the canister. I checked some of the pool canisters and seemed to have received an upgrade this morning. For example the ICP/CHAT pool.
https://ic-api.internetcomputer.org/api/v3/canisters/dy354-viaaa-aaaak-qlsaa-cai
to see all canisters from this user principal you can check nmego-d5hug-xi2qp-2stqm-4msyk-qjemt-44c3j-jz6pa-zhhtu-lv6gg-aae
Correction; i’m not sure the updated_at on the api link i shared is related to the canister upgrade, as doing a deeper dive into the canister upgrade hisory shows the last upgrade was 2026-06-21 15:14:26 UTC
1730387464998202354 → 2024-10-31 15:11:04 UTC | #1 creation — controller set to v26lw-…-cai
1730387465851706459 → 2024-10-31 15:11:05 UTC | #2 install — module fd5fe636…36d4db
1730387479745314411 → 2024-10-31 15:11:19 UTC | #3 controllers_change — added nmego-…-aae
1733389635403449987 → 2024-12-05 09:07:15 UTC | #4 upgrade — module dc298f29…7314de
1733746298774891094 → 2024-12-09 12:11:38 UTC | #5 upgrade — module 73956605…2f1f59
1743654541313476156 → 2025-04-03 03:09:01 UTC | #6 upgrade — module 9eca9a92…dad139
1743667409479797245 → 2025-04-03 06:43:29 UTC | #7 upgrade — module d2b4bd1a…44a98a
1747941028887739633 → 2025-05-22 19:10:28 UTC | #8 upgrade — module 85677555…7bc2db1
1749196252754700144 → 2025-06-06 07:50:52 UTC | #9 upgrade — module 6238505a…242d2
1756617447415724330 → 2025-08-31 05:17:27 UTC | #10 upgrade — module 3d5bcaa1…819033
1756790842661525983 → 2025-09-02 05:27:22 UTC | #11 upgrade — module b0448b89…9aea78a
1782045266094513987 → 2026-06-21 15:14:26 UTC | #12 upgrade — module 56f95c28…3d26de
This data is pulled from a Cycleops canister
Welcome to the party - I’ve been working on it for 9 months now: sr9n.com I think that, at some point in the future, developers will write around 1-5k LOC of specs and high level architecture code, then let AI fill in the rest. It also ties in well with your other work: ZK proves that the software ran as it was supposed to, while formal verification proves that the software itself is correct.
nice.
on our end.. we have a pipeline that lets you convert natural language to formal logic (SMT).
we can then take that SMT and run it though special models to ouput spec for Dafny, Certora ect.
these compile into programs in (C#, Java, JavaScript, Go, and Python, Solidity) with formal proofs.
*never thought about adding Motoko.. but i imagine it would be a smaller lift
*would be an epic grant if those still existed
now how the hell does a normal person know this process was done correctly?
even normal devs, know nothing about formal proofs…
for many years we have been pioneering a space called ZKML (zero knowledge machine learning), this could be used to commit to the model that demonstrates 99% soundness at NL to SMT conversion. SMT solver itself is easy to wrap in ZK.. it returns SAT / UNSAT. we can ‘fold’ thousands of these proofs into one succinct artifact that is VALID on a successful run or invalid; verifiable in under 1s even by complete normies. Succinct verification meets formal methods
Weakness of formal methods:
- You only prove what is in the spec. If the spec is bad.. it does not help. We have methods to help here.
- Proof repair is hard and LLM are bad at it. We have methods here.
- SMT only works on certain logic. (First order logic and other methods required for non linear functions and such).
for several years they are not serious project, they kept extracting money from the dao whenever they felt like it.
Good low-stakes warning shot for the ecosystem IMO. Projects that custody TVL need to invest in security or close down. I disclosed the KongSwap full drain without reward, then tried to get other projects to list bounty programs to no avail. I really want to hunt here as an honest whitehat but can’t. So all that’s left is blackhats. Maybe some projects will list a bounty program now.
may I ask how was possible to check canisters by controller?
The list of canisters controlled by a principal isn’t something you can query directly on-chain, the IC’s management canister has no “list canisters by controller” method, and canister_status only works if you already know the canister ID and are one of its controllers. list_canisters exists but it’s a subnet admin method returning canister-ID ranges, not a controller filter.
What makes it possible is DFINITY’s public dashboard API, which runs an off-chain indexer that tracks canister controllers. You can hit it directly:
https://ic-api.internetcomputer.org/api/v3/canisters?controller_id=<PRINCIPAL_ID>
Or just use the official ICP Dashboard (dashboard.internetcomputer.org) search a principal and it shows the canisters it controls.
One caveat worth knowing: on the IC anyone can add any principal as a controller of their canister, so a canister showing up under a principal doesn’t prove that principal owns or created it.
In case you find it useful, the OhShii Token Explorer / Wallet Analyzer wraps this same API for you and adds canister-type classification, so it’s a convenient option, but it’s not the only way; the DFINITY dashboard and its REST API give you the same underlying data.
e.g. https://explorer.ohshii.io/explorer?mode=wallet&account=r7inp-6aaaa-aaaaa-aaabq-cai&wtab=canisters
The official docs AI has confirmed:
canister_infoThe
canister_infomanagement canister method returns the following information about any canister:
total_num_changes— the total number of canister changes ever recorded in the history (this count doesn’t decrease even if old entries are dropped).
recent_changes— a list of the most recent canister changes, including:
- Canister creation
- Code installations, reinstalls, and upgrades
- Controller changes
- Snapshot loads
- Canister renaming
Each change entry includes the timestamp, canister version after the change, and the origin (user or canister) that initiated it.
module_hash— the SHA-256 hash of the currently installed Wasm module (nullif the canister is empty).
controllers— the current set of canister controllers.Key characteristics
- Any canister can call it on any other canister — unlike
canister_status, which is restricted to controllers.- Not callable by external users — only canisters can invoke it (no ingress messages).
- History is bounded — the system guarantees at least the 20 most recent changes are retained, but may drop older ones.
Example (Rust)
use ic_cdk::api::management_canister::main::{ canister_info, CanisterInfoRequest, CanisterInfoResponse, }; use candid::Principal; #[ic_cdk::update] async fn info(canister_id: Principal) -> CanisterInfoResponse { let request = CanisterInfoRequest { canister_id, num_requested_changes: Some(20), }; canister_info(request).await.unwrap().0 }
My main point from my original answer was that neither method gives you a reverse lookup. canister_info can tell you who controls canister X, but not which canisters are controlled by a principal.
There’s no on-chain controller index, which is why the dashboard’s off-chain indexer is needed to make that query possible in the first place.
This is right btw, canister_info does expose the current controllers, along with the module hash and change history, for any canister.
Sorry I misunderstood you. I get what you’re saying now.
As mentioned, the info is accessible via canister_info and you don’t need to be a controller to get it. You can poll, or lazily query and cache (as the DFINITY dashboard does), or use OhShii, or other explorers
Taggr had a bounty program from day one. And it paid off several times.
So that’s it? Sonic got hacked and that’s that? No announcements? No vigilance? Wow.
It’s so encouraging for scammers, 24 hour fuzz and then clear rode.
Where is the investigation? Who was the attacker? Who did it?
Where did all the money go? Is it tied to an exchange to any KYC? IP addresses?
Also, why is Sonic Swap still standing? It’s just gulping money, trades are failing without payout, you can say Scam is ongoing.
What the hell is going on here?