The threat model most protocols do not publish
Every incident in this tracker up to here involves someone outside the project. This one does not. A developer engaged to build the protocol retained privileged access after their work and used it.
No contract was exploited. No key was stolen. The access was legitimately granted and never revoked. An audit examining the contract would have found the privileged function and, quite reasonably, treated it as an administrative capability the team intended to have.
What a user can actually check
Privileged roles are visible on-chain. For any contract holding your assets, it is checkable whether an upgrade, pause, withdraw or ownership-transfer function exists, and which address controls it. Whether that address is a single key, a multisig, or a timelocked multisig is also public.
What is not public is who holds those keys and whether access is revoked when people leave. That is the gap this incident sits in, and it is not solved by auditing.
The return
The funds came back in full. That outcome should not be read as typical, and it does not change the exposure that existed while they were gone.
Timeline
Append-only. Corrections are added as their own dated entry; earlier entries are never rewritten.
- A developer with privileged access transfers approximately $62m of user assets out of the protocol. Munchables
- The funds are returned in full, without conditions. Munchables
What to check
Munchables published statements confirming both the transfer and the return on its own channels.
Conisec does not host or link recovery, revocation or "checker" tools. After a public incident, attackers routinely seed exactly those links using the names of publications covering the story. Use the affected project's own official channel, linked above, and nothing else.
Sources
- Munchables, Official statements (26 Mar 2024)
Not advice. This is a summary of published facts, not legal, tax or security advice. Verify against the primary sources linked above.
Last verified by Conisec Staff.
