I’m an affected user from the borrow/lend side, and I’m trying to understand the repeated statement that the Insurance Fund was “not affected.”
I’m not trying to assume bad faith. I’m genuinely confused about what “not affected” means here, especially as someone who never interacted with the Insurance Fund directly.
If “not affected” means the internal IF accounting did not change, that’s one thing. But if token balances moved, funds were transferred for emergency safe-keeping, or the IF is still connected to the same broader protocol solvency picture, then I think users need a clearer explanation.
The questions I’m hoping the team or community can help answer are:
When the team says the IF was “not affected,” does that mean no on-chain token balances changed, or only that the internal IF share accounting stayed the same?
What are the exact IF vault or token account addresses, and what were their balances before and after the incident?
Are IF assets stored separately from user deposits, or are they ultimately part of the same underlying custody system or protocol code?
Was there any admin-level action, transfer, or withdrawal involving the Insurance Fund during the incident or emergency response?
For any quoted USD “notional value,” is that just an estimate based on the current market value of the underlying tokens? In other words, is the actual withdrawable amount based on token balances and IF shares, rather than a fixed USD amount?
If the IF truly was not affected, then I’m comfortable supporting the proposed treatment/release framework. But right now, “not affected” feels too vague for affected borrow/lend users who never touched the IF to understand what is actually being protected, released, or excluded.
I also think this matters a lot for the relaunch. If the community gets this wrong, or if people feel like the treatment is based on unclear definitions, it could damage trust right when the protocol most needs it. I want the relaunch to succeed, but that requires users to understand why some funds are considered affected and others are not.
A precise answer would help a lot: not affected how, not affected for whom, and based on which on-chain balances?
Both are correct, insurance fund vault assets were completely isolated from the protocol exploit. No unauthorized balance changes during the attack on April 1st.
There are a couple addresses, and I might miss some but relevant addresses include:
Yes and no, some vault assets are on different addresses, but the majority were on the JCNCM address, however it’s important to note that this housed assets from the strategy vaults as well, which were the main target.
As mentioned previously the drift team moved the IF vault SOL and USDC to different addresses, other IF vault funds remain on the JCNCM address.
If you mean the recovery pool, then you can think of it as a share % of the total assets usd value on April 1st, and then applied forward. if you had 1% of spot market + strategy vault assets prior to the attack, you have 1% share of the recovery pool. As for the IF vaults, these assets should be available as they were deposited.
Currently Drift confirmed that IF vault funds were untouched and too be returned to users “soon” (on relaunch?), but then contradicted themselves in the later post suggesting they want a DAO vote on the unaffected user funds which would raise ample legal concerns.
I agree it’s difficult to view chain balances when drift had multiple site protocols running through the same addresses: borrow/lend, strategy vaults, IF vaults, subaccounts, and more. Arkham helps look at this to some degree.
It was not afffected because it had a smart contract time delay which prevented the hackers from taking it. This feature is the only reason I invested. For them now to say they are changing the rules after the fact is not only unethical it is criminal.
I would read “not affected” as internal IF share accounting unchanged, not necessarily “no token-account movement.” The clearest counterexample is original USDC: the IF vault balance changed because funds were moved to emergency safe-keeping, but the accounting view is still recoverable as vault remaining + safe account.
We have exact accounting balances from the on-chain snapshot, and can be fully audited by running slot-bounded account history. check out my thread for address
My understanding: No, IF assets are not stored in the same custody account as ordinary user deposits. For each spot market, Drift has a normal spot-market token vault used for user deposits/borrows, some of which are drained, and a separate insuranceFund.vault token account used for the insurance fund. They may hold the same mint, for example USDC, but they are different SPL token accounts with different accounting. The code path is also different. User deposits/withdrawals are accounted through the spot market deposit/borrow system and user spot balances. IF assets are accounted through the insurance fund fields, especially totalShares and userShares, plus IF staking/unstaking logic. The protocol-owned IF portion is the residual: protocolShares = totalShares - userShares So the IF is not just “some of the user deposit pool.” It is a separate vault and a separate share-accounting system inside the Drift program. Its custody and accounting are distinct from user deposits.
Yes, at one known admin/emergency-style interaction involved the IF: the original USDC IF funds were moved out to the safe account in my post. I would phrase this as “there was an emergency safe-keeping transfer involving the IF vault,” not as a normal withdrawal or proof of loss.
The notional value is not the same thing as fully withdrawable 1:1 cash. It is mark-to-market value of tokens attributed to IF accounting. Actual withdrawability depends on the underlying token balances/custody, Drift’s IF withdrawal rules on relaunch or admin controls. The protocol-owned portion is an accounting residual, not automatically a withdrawable user asset.
I don’t think this is true. It was unaffected because the original contract only allowed withdrawals of protocol owned portion of the IF to specific approved addresses. The original exploit wasn’t able to get around that. But yes, there was no way to drain the IF during the exploit.
Agree. No one will come back if they allow IF to be part of the recovery fund. Investors also choose risk in putting their money thats why some put it in IF
Gotcha, so, the IF vaults were separate accounts, the exploit could only reach the borrow/lend pool, and the IF couldn’t be drained because there was no way to exploit it.
I also looked at the on-chain breakdown (thread here), and assuming these are verified, then it seems to checkout.
The community shouldn’t be reverse-engineering this from individual on-chain investigations. The team needs to confirm these facts directly and do it before putting any proposal forward.