Thank you @SlowMist_Team and @MistTrack_io for the alert and the fund tracing. This is our full response on the reported transaction. The finding is correct and the bug is ours. We wrote the collateral-borrow path, we shipped it, and we did not catch this. What follows is the complete accounting for that transaction and that pool, so that anyone can check our numbers against the chain. 1. What went wrong LikwidMarginPosition has a collateral-borrow mode (leverage = 0): deposit one token of a pool, borrow the other. Three things in that path were wrong at the same time. • Every position was valued on its own. The borrow limit comes from a swap quote against the pool's reserves, and this path never moved those reserves, so the same quote came back on every call. A large amount of collateral could be split into many positions, each priced as if it were the only one. This is exactly what SlowMist identified. • Collateral was valued at the pool's own current price. In a thin pool, that price can be pushed several times higher with a few BNB. • The only limit that applied across positions was a cap that lets borrowing reach 80% of a pool's BNB, and that includes BNB the attacker had just put in. The attacker bought the pool's token in ten small steps over five minutes to raise its price 4.6x, then in a single transaction opened 24 borrow positions against the tokens they had just bought, took the BNB, and abandoned the positions. 2. The numbers Three different figures get mixed together in an incident like this: the gross amount borrowed, the attacker's net profit, and the loss to the pool. We keep them apart. Gross amount borrowed: 74.31 BNB. SlowMist's figure is accurate. It is what left the vault in that transaction and will never be repaid. Where that BNB came from: • 55 BNB was the attacker's own money, spent in the five minutes before the transaction buying the token to raise its price. • An earlier attempt on the same pool, about 80 minutes before, had failed. The attacker bought 20.8 BNB worth of the token, sold it back in one trade, hit the pool's 99% dynamic fee and got 0.36 BNB back. That 20.44 BNB stayed in the pool. • In total the attacker put 75.8 BNB into this pool and took 77.99 BNB out (74.31 borrowed, 3.68 from selling tokens). Attacker's net profit on this pool: +2.19 BNB. Loss to the pool: before the attack the pool held 17.93 BNB of real liquidity. At 07:00 UTC it held 5.67, a drop of about 12.3 BNB. Of that, 2.19 BNB went to the attacker and more than 9 BNB went to other holders of the token: the attack left the pool's price inflated, and 54 third-party trades have sold into that price since. One LP withdrew 0.30 BNB. One more figure is visible on-chain, so we address it here. After the 24 positions were liquidated, this pool's insurance fund reads -61.32 BNB. That is not a second, larger loss. The attacker's own 75.8 BNB had been booked into the pool's reserves when they bought, and was then borrowed back out; the deficit is the book entry for that. Measured the other way (pool book minus deficit), LP-backed BNB in this pool went from 22.5 to 10.3, the same loss of about 12 BNB that the real liquidity shows. So most of the 74.31 BNB is the attacker's own money going in and coming back out. The attacker made 2.19 BNB. The pool's LPs have lost about 12 BNB so far, and that is the number we hold ourselves to. It is smaller than the headline, and it is still a real loss to real LPs. 3. Why this pool The pool is a BNB/meme pair. More than 80% of the token's supply was sitting inside the Likwid pool, against about 18 BNB of real liquidity, and the token has no meaningful market anywhere else. It was in effect a single-participant pool. There was no outside liquidity to arbitrage against and nobody trading the other side, so a few BNB moved the price several times over and it stayed there. Likwid prices everything from the pool itself, with no oracle. That design depends on a market existing around the pool. When someone pushes the price away from where it should be, arbitrageurs and holders trade against them, dynamic fees climb with the deviation, and the push becomes expensive and short-lived. In an active pair, the cost of this attack grows with the depth of the pool and with the counter-flow it meets. The attacker's first attempt shows the mechanism working: it lost 20.44 BNB to fees. This explains where the attack was possible. It does not excuse it. Anyone can create a pool on Likwid, thin pools are a normal condition of a permissionless protocol, and a borrow function has to be safe there too. Ours was not. 4. Isolation between pools LikwidVault is a single contract, but every pool inside it keeps its own ledger: its own reserves, its own lending balance, its own insurance fund. A pool can only pay out of its own reserves, and the borrow path reverts beyond that. Nothing borrowed in this pool can draw on another pool's funds, and this pool's deficit stays in this pool. 5. What we are doing • Collateral borrowing has been restricted on-chain as an immediate measure. At 16:22 UTC on Sept 18 our multisig raised the minimum collateral ratio for this mode from 1.4x to 16.78x, the maximum the contract accepts, which cuts what can be borrowed against the same collateral by about 12x. This is a restriction, not the fix; the fix is the removal below. https://t.co/KSx6jLQPFn • This pool is in an abnormal state: its price is still about 2.8x the pre-attack level and its book carries the deficit described above. Please do not add liquidity to it or trade in it until we publish the handling plan. • The collateral-borrow entry (leverage = 0) will be removed entirely, not patched, in a new contract version. It will be a fresh deployment, and we will publish migration steps for existing LPs and position holders well before it goes live. • Likwid Margin goes back to doing one thing: margin trading. Standalone borrow and lend were side features. They widened the attack surface more than they served users, and they will be retired with the new version. Transaction: 0x83cbd07d59aedc2f114c351c568d3386ff5bc7caa87d12bc6494e2dc7bf16f4d Thank you again to SlowMist and MistTrack for the fast and accurate work.