The SEC added four words to its buyback FAQ: "and has no central party." That is the right test, and not only for lawyers. Discretionary buybacks fail it: a vote can start them, a vote can stop them. Value return is real when no one decides whether it happens. #DeFi #Tokenomics
Borrow vs. margin: what a pool can lend against, and what it can't Two ways to use a pool's liquidity look almost identical from the outside. Both let you put in one asset and get exposure to another. Underneath, they carry completely different risk, and the difference decides what a permissionless AMM can offer. What borrow is Deposit token A into a pool, take token B out. The pool decides how much B you may take by looking at its own price of A. The moment the position opens, B has left the pool. If A turns out to be worth less than the pool believed, the pool has already paid; the borrower simply never comes back. So a borrow is exactly as safe as the pool's price of A. And that price is not a fact the pool knows. It is the result of the last trade. Where a price comes from If A trades in many places, the pool's price is held in place by everyone who is not in the pool. Push it away from the rest of the market and arbitrageurs sell into you, dynamic fees climb with the deviation, and the push is expensive and short-lived. The price is anchored. Now take a pool where the token trades nowhere else, most of its supply sits inside the pool, and nobody is on the other side. Call it a single-participant pool. There, the price is whatever the last buyer paid. Push it and it stays pushed, because there is no market to pull it back. Lend against that price and you are lending against a number that one person chose. None of this is specific to AMMs. Every lending venue that has ever taken an illiquid asset as collateral has learned the same lesson: centralized exchanges cap or delist thin collateral, DeFi lenders add supply caps, LTV haircuts and external oracles. Collateral that cannot be sold into a real market is not collateral. The only honest answers are to not lend against it, or to learn its price from somewhere other than the pool being borrowed from. What margin is Margin, a leveraged position, has a different shape. The trader deposits margin; the pool lends the other asset and swaps it inside the same pool, right there, with full price impact. Nothing leaves the pool when the position opens. The position is an amount of the pool's own asset, bought at the pool's price, and the only way anything leaves at close is by swapping back through the same pool. The pool's exposure is the price path between open and close, marked against a lagging reference and closed out by liquidation. There is no moment where the pool hands an asset out against an outside valuation. Margin can still be pushed around; every market can. But pushing it means trading against the pool with real assets, paying deviation fees on the way in, and unwinding through the same pool on the way out. That is a game the pool can play. The decision Anyone can create a pool on Likwid, so thin, single-participant pools are a normal condition, not an edge case. A feature that is only safe on active pairs does not belong in a permissionless AMM. Borrow needs a market the pool cannot guarantee. Margin needs only the pool. That is why Likwid Margin is narrowing to one thing, margin trading on the pool's own liquidity, and collateral borrow is being removed.
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.
ONE MANIPULATION ATTEMPT, FULLY ACCOUNTED On September 7, someone spent about an hour trying to break a small BNB/USDT pool on Likwid. This is the complete ledger: what they did, what each mechanism did back, who ended up with the money, and what we are changing because of it. TL;DR • A purpose-built contract opened 22 rapid 5x longs and pushed the pool price of BNB from 727 to 1,969 USDT, a +171% move, while the real market stayed near 727. • An MEV bot dumped into the top. All 22 longs were liquidated within 20 seconds. The attacker then crashed the pool to 220 (-70%) with 79 sells and borrowed 1.49 BNB against 790 USDT at that fake price. Twenty minutes later other bots bought the pool back to 723 and that position was liquidated too. • Net result, in USD at the pre-attack price of 727 USDT/BNB: attacker -$1,175. MEV bots +$1,221. Pool fees +$1,270. Liquidators +$28. LPs and lenders of the pool -$201, which is 2.9% of the pool's $6,864 in reserves. The six parties sum to zero. • The pool now shows an insurance-fund deficit of 1.4738 BNB and 432.80 USDT (about $1,507). Most of that number is an accounting effect of where the attacker's last collateral went, not an additional loss. We explain that below, because it is the part most people will misread. • No contract was broken, no parameter was bypassed, and the attacker paid roughly six times the damage they caused. That is what the design is supposed to do. It is not the same as "nobody lost anything", and we would rather show the whole ledger than round it off. WHY WE ARE PUBLISHING THIS Likwid pools have no oracle. Every price used for swaps, for margin health and for liquidation comes from the pool's own reserves. That is a deliberate choice: there is no external feed to spoof, no keeper set to bribe, no order book to spoof. The trade-off is equally deliberate: anyone with enough capital can move the pool price, and the protocol has to make that expensive rather than impossible. This incident is the first time someone has run the full playbook against a live pool. It is small money. The pool held about $6.9k, and the attack was executed in USDT amounts of a few hundred at a time. But the mechanics are exactly the ones that would matter at scale, and every step is on chain, so we reconstructed it to the dollar. What follows is that reconstruction. All numbers come from the pool's own events (PoolUpdated, Swap, Fees, Margin, LiquidateBurn), decoded and cross-checked so that the flows of all parties add up to zero. USD figures use 727 USDT/BNB, the pool price at the moment the first attacker transaction landed; the pool returned to 723 after the episode, so the choice of reference does not move the conclusions. THE MECHANISMS IN PLAY Four properties of the protocol matter for this story. 1. The pool is the price. A Likwid pool is a single constant-product curve, (x + x')(y + y') = k, that serves spot swaps, lending and margin at once. The "pool price" below is simply the ratio of the pool's paired reserves. 2. A lagging reference price for anything that can hurt someone else. Liquidation checks and borrow-health checks do not use the live pool price. They use a *truncated reference* that is allowed to move toward the live price only by a bounded amount per update, growing with the square of the time elapsed since the last update, and not at all for transactions that land in the same second as the previous update. Opening or modifying a position must pass the health check against both the live price and the reference, whichever is worse. A one-block price spike therefore cannot liquidate anyone and cannot be borrowed against. Moving the reference takes time and real trades. 3. A fee that scales with how far you push. The swap fee starts at the pool's base rate, 0.3% here. Once a trade would leave the pool price more than 10% away from the reference, the fee grows with the cube of the deviation: fee = 0.3% x (10 x s)^3, capped at 99%. The deviation is measured on the price *after* the trade, so a large trade pays for the distance it creates. The fee is taken from the trader's input and stays in the pool: 90% to LPs, 10% to the protocol. 4. Conservative leverage and forced unwinds through the pool. Maximum leverage is 5x. A position is liquidatable when its collateral, valued at the reference price, falls below 110% of its debt. Liquidation sells the collateral back into the same pool, paying the same fee curve as any other trade, and pays the liquidator 1% of the collateral. If the collateral does not cover the debt, the shortfall is booked against the pool's insurance fund. Keep those four in mind. Each step of the attack ran into one of them. THE TIMELINE All times are UTC, September 7, 2026. Before the first transaction the pool held 4.78 BNB and 3,388 USDT, about $6,864, at a price of 727 USDT per BNB. ACT 1: THE PUMP (22:39:57 TO 23:11:57) The attacker's contract had been deployed for this purpose. It had no prior history in the pool, 12 KB of code, and every one of its 113 transactions came from the same wallet. It opened one 5x long on BNB at 22:39:57, sold a little BNB to probe the pool, then between 23:03:40 and 23:11:57 opened 21 more 5x longs, one every three seconds or so. Each long posted 0.018 to 0.031 BNB of margin, borrowed 84 to 141 USDT from the pool, and used that USDT to buy BNB from the same pool. Twenty-two positions in total: 0.535 BNB of margin posted, 2,408 USDT borrowed, and the pool price walked from 727 to 1,969 USDT per BNB. Two details show this was engineered rather than clumsy. Every step moved the price by 5 to 7%, just under the 10% deviation that turns the dynamic fee on, so the opens paid only the base fee. And the three-second spacing let the truncated reference keep up with the live price, which is the only way the health check on each new position would pass. The cost of doing it this way is the point: 22 real positions with real margin, and by the end of the pump the attacker was long about 2.65 BNB at prices the rest of the market would never pay. ACT 2: THE DUMP (23:12:00) The attacker sold a token of BNB at the top. In the same second, an MEV bot that has nothing to do with the attacker as far as the chain shows (a different controlling wallet, a contract with thousands of prior deployments, and it later bought the dip as well) fired 47 sells in two transactions: 0.6055 BNB for 920.85 USDT, an average of 1,521 per BNB against a real market of about 727. Because those 47 fills landed in the same second, the reference price stayed frozen at the top while the live price fell away from it. The fee on the fills climbed from 0.3% to 21.9% within the same transaction. The bot still profited, about $481 net, because selling BNB at double the market price beats a 22% fee. But the pool captured 0.0399 BNB of that spread in fees, and the price only got as far as 1,279 before the bot stopped. ACT 3: THE LIQUIDATIONS (23:12:04 TO 23:12:24) Within four seconds of the dump, liquidations started. Within twenty seconds all 22 longs were gone. Thirty-three of the 44 liquidations in the episode were executed by a keeper, the rest by three independent liquidation bots competing for the 1% reward. Total liquidator income across the whole episode: 0.0268 BNB and 8.39 USDT, about $28. Each liquidation sold the position's BNB collateral back into the pool to repay its USDT debt. Two things worked against recovery. The collateral had been bought at 1,000 to 1,900 per BNB and was being sold into a pool that the dump had already pushed down. And the unwinds themselves pushed the live price further from the still-elevated reference, so several paid a dynamic fee on top. The result was 434.66 USDT of debt that the collateral did not cover, booked against the pool's insurance fund on the USDT side. At this point the attacker had lost all 0.535 BNB of margin and had extracted essentially nothing: the pumped BNB was sitting inside the liquidated positions, not in their wallet. ACT 4: THE CRASH AND THE BORROW (23:14:58 TO 23:19:57) The second half of the plan was the mirror image. If the pool could be made to value BNB far *below* market, the attacker could deposit USDT and borrow BNB that the pool thought was cheap. Doing that required moving the truncated reference down, and the reference does not jump. So the attacker sold BNB into the pool 79 times over five minutes: 2.6056 BNB for a total of 808.49 USDT, an average of 310 USDT per BNB, a 57% discount to market. The pool price went from 444 to 220. These sells paid only the base fee, because each one stayed inside the 10% band and the reference followed. That is the cost the design imposes: you can move the reference, but only by trading at the price you are creating, in size, for as long as it takes. At 23:18:28, with the pool at about 243, the attacker deposited 790.45 USDT and borrowed 1.49 BNB. The pool valued that debt at about $362; the market valued it at about $1,083. The attacker walked away with the BNB. ACT 5: THE BUYBACK AND THE LAST LIQUIDATION (23:36:09 TO 23:36:30) Nobody else was going to leave BNB at 220. Between 23:36:09 and 23:36:30, fourteen MEV bots bought BNB from the pool in 31 fills: 1,550 USDT for 3.1496 BNB, an average of 492 per BNB. They paid 378.44 USDT in fees for the privilege, 24.4% of their volume, with single fills paying up to 50.9%. The pool price recovered to 723. The recovery made the attacker's borrow position underwater. At 23:36:25 it was liquidated. Its 782.55 USDT of collateral was sold into a pool whose live price was already 37% above the reference, and the sale itself pushed the deviation past the point where the fee caps at 99%. Of the 782.55 USDT, 774.72 became fees (697.25 to LPs, 77.47 to the protocol) and the pool recovered only 0.015 BNB against 1.49 BNB of debt. The shortfall, 1.4749 BNB, was booked against the insurance fund on the BNB side. That last transaction is the one that makes the pool page look alarming today. It is worth understanding exactly what it did, so the next section walks through the books. THE LEDGER Net token flows for every party over the 57 minutes, valued at 727 USDT per BNB: • Attacker contract: BNB -1.8810; USDT +192.96; USD -$1,175 • MEV bot that dumped the top: BNB -0.6055; USDT +920.85; USD +$481 • Fourteen MEV bots that bought the bottom: BNB +3.1496; USDT -1,550.00; USD +$740 • Four liquidators (1% rewards): BNB +0.0268; USDT +8.39; USD +$28 • Protocol fee share: BNB +0.0158; USDT +116.05; USD +$128 • Pool reserves (LPs and lenders): BNB -0.6229; USDT +251.62; USD -$201 • Total: BNB 0; USDT 0; USD 0 The attacker's line is the sum of everything they touched: 0.535 BNB of margin and 790.45 USDT of collateral forfeited, 2.8346 BNB sold across 90 swaps for 983.41 USDT, and 1.49 BNB borrowed and kept. Gas was about 0.0013 BNB. Even if you credit the dump bot's $481 to the attacker, which the chain does not support, the combined result is still -$694. Fees collected by the pool during the episode: 0.1355 BNB and 1,044.48 USDT to LPs (about $1,143) plus 0.0158 BNB and 116.05 USDT to the protocol (about $128), a total of about $1,270, or 18.5% of the pool's pre-attack reserves, in under an hour. WHAT THE NEGATIVE INSURANCE FUND MEANS Every Likwid pool keeps one identity per token: real reserves plus outstanding borrows equal LP claims plus lender claims plus the insurance fund. A negative insurance fund means the claims on the books exceed the assets behind them by that amount. For this pool it is 1.4738 BNB on the BNB side and 432.80 USDT on the USDT side, about $1,507. It is real. It is owed to LPs and lenders, and it heals only from future liquidation surpluses and over-repayments on the same side, or from a direct donation to the fund. But it is not a $1,507 loss on top of the fees. Look at the LP side of the books: LP claims on the pool rose by about $1,325 during the episode, because the fees landed in the reserves LPs own. Subtract the $1,507 deficit and you get about -$180, which matches the -$201 change in real reserves once lender claims and rounding are included. The two numbers are the same loss seen from two sides. The reason the deficit looks so much larger than the real loss is the last liquidation. Selling 782.55 USDT of collateral at a 99% fee did not lose the pool 782 USDT; the USDT stayed in the pool. It just stayed there as *fees to LPs* instead of as *repayment of the 1.49 BNB debt*. So the books show LP claims up by 697 USDT and the insurance fund down by 1.47 BNB, where a fee-free unwind would have shown LP claims flat and the fund down by roughly 0.1 BNB. Same assets, same real loss, very different-looking ledger. We flag this because it is the kind of thing that turns into a screenshot. WHAT WORKED The pump cost real money and returned nothing. Five-times leverage and pool-depth limits meant a +171% move needed 22 separate positions and 0.535 BNB of margin, all of which was liquidated. The attacker could not extract the pumped price: the BNB bought at the top was inside positions that the protocol sold back into the pool. The reference price could not be flashed. To borrow against a fake price the attacker had to actually drag the reference down, which meant five minutes of selling 2.6 BNB at a 57% discount, about $1,080 of value handed to the pool and to whoever bought later. This is the single largest line in their loss, and it is exactly the cost the lagging reference is meant to impose. A flash loan does nothing here. Deviation-priced fees turned the spread into LP income. The bot that dumped the top paid up to 22%. The bots that bought the bottom paid 24% of their volume, with fills at 51%. Roughly $1,270 that would otherwise have been pure MEV profit ended up in the pool instead. Liquidation was fast and competitive. Four seconds from dump to first liquidation, twenty seconds to clear all 22 positions, four different liquidators, and a total reward of $28. Nobody got rich liquidating. WHAT DID NOT, AND WHAT WE ARE CHANGING A fake price can still be borrowed against, if you pay to move the reference slowly. The attacker did get 1.49 BNB out against 790 USDT. That single position is where the pool's real loss came from: 1.49 BNB out, 790 USDT in, about -$293 at market. The lagging reference made it expensive (it cost the attacker far more than $293 to set up), but it did not make it impossible. We treat that as the price of having no oracle at all, and the numbers say the price was paid by the attacker, not by LPs. We will keep watching whether that holds at larger pool sizes, where the same trick needs proportionally more capital and pays proportionally more fees. Forced unwinds should not pay the dynamic fee. The 99% fee on the last liquidation did not change what LPs really own, but it converted recoverable debt into a headline deficit and it makes the insurance fund harder to read and slower to heal. We had already drafted a proposal to settle liquidation unwinds at the pool's static base fee; this episode is the argument for shipping it. Insurance-fund deficits are side-locked. A shortfall in BNB cannot be healed by a surplus in USDT on the same pool, and vice versa. A cross-side rebalancing rule, bounded by the reference price so it cannot itself be gamed, is the second item on the same proposal. This pool's deficit. LPs and lenders in the BNB/USDT pool on BNB Chain carry the $1,507 book deficit today. It shrinks with every profitable liquidation and every over-repayment on the affected side, and it can be closed at once by a donation to the pool's fund. We are deciding how to handle it and will post the decision, with the transaction, in this thread. METHOD, SO YOU CAN CHECK IT • Every event emitted by the Likwid vault and the three position managers for this pool, from vault deployment on May 1 through today, was pulled by eth_getLogs and decoded against the contract ABIs: 3,447 events. • Pool prices are derived from the pairReserves snapshot each event carries; liquidation events carry both the reference and the live reserves at the moment of liquidation. • Party flows use the trader-side deltas in Swap, the margin and debt fields in Margin, and the reward fields in LiquidateBurn. Fees come from Fees events. Everything is valued at 727 USDT/BNB. • The check that matters: attacker, MEV bots, liquidators, protocol fees and pool reserves sum to exactly zero. Key transactions on BNB Chain, in order: • First long opened (block 120,575,902): 0x44a03b2122b4dfda12d6c19f4d420ab81e5d770094b320699ec5cef0c81544ca • Last long opened (120,580,161): 0x9ba1a2fe4c7c883bb71a3ed75a889eb39214258afd8c67c219200b636de4b9b7 • Dump, 47 fills in two transactions (120,580,169 and 120,580,170): 0x8bc72a803c8dbbe8c674890e43f02197b4af61c976d048f453a14d7513aff008, 0xa88b462cff0c19d099687f8eb43ffe30fe8a230a071bc35609179b5346f1108a • First liquidation with bad debt (120,580,178): 0xb399796f677de9811ce244ca6dc195770e9944e330ca40d4a903d009ff81f734 • Crash sells, first and last (120,580,561 to 120,581,227): 0xc4bd08db8261071488843fd257c32a407b1f68ea9f2ccf4471b47f70aba1d66d, 0xb110047c7f7fbc73426e223cb5efc06f1778e0d1265aee46fd0eb7fd472055e2 • Borrow of 1.49 BNB against 790 USDT (120,581,029): 0x0b03bf1e90c2867e87c5503e3cdbc53e700b782faa0d21339607aebe0dc500e4 • Largest buyback, 500 USDT for 1.58 BNB (120,583,387): 0x9814a1e954400574bbe1e381df69ff864f471566acd510ef499767702e14321f • Final liquidation, 1.4749 BNB bad debt (120,583,421): 0x4f1b0dddb6c145c08b573813e648af6aa45924819061c8b7d397efe49c1e304d Pool: 0xb929e72a539e7c98b8d755f0dfc488c574a9df6fc94a6822940087d0eb70ae7a on BNB Chain. Vault, position managers and the helper contract are listed at https://t.co/r38SVNGs5L. Manipulation is allowed here. It just doesn't pay.
Borrowing should not move a pool's price. On Likwid, a loan shifts real reserves into mirror reserves. The expanded balance stays constant, so the quote holds. Leverage swaps through the curve, moving price like a real trade. Same pool. Different action. #DeFi #Lending https://t.co/4Oh6mXHxUw
Vitalik's new roadmap ends with a promise: Ethereum will be quantum-safe, private, censorship-resistant. And Lean. Likwid has no oracle, no order book, no counterparty. The L1 is our whole trust model. When your only dependency is EVM, its roadmap is your roadmap. #DeFi #Ethereum #DeFiSecurity
BlackRock put a $6.2B money market fund on Ethereum — cash, short-term Treasuries, and overnight repo, tokenized. When the world's largest asset manager settles here, tokenization stops being a thesis. It's a certainty. That's why Likwid builds on Ethereum. Long-term. #DeFi #Tokenization #RWA
$2M swapped into $14K. Not a hack — a routing bug + a backrun bot. A victim's trade dumped ~1,117 ETH into a thin AVAIL/WETH pool, buying AVAIL at ~120× its real price. A same-block backrunner sold a sliver of AVAIL back in, drained ~1,072 WETH — and paid most of it to the block builder. On LIKWID, this class of MEV is priced out by design 🧵👇 1. Root cause: fragmented, low-liquidity side pools. A router can shove size into a thin pool and eat catastrophic slippage. That self-inflicted mispricing is free money — the backrunner just sells the asset back in at the real price and walks off with the WETH. 2. Likwid puts spot + leverage in ONE native pool per token. No thin side-pool to route into. No oracle to lag or manipulate — price comes straight from reserves, and borrowed size stays "on the books" as mirror reserves, so lending can't fake the quote. 3. The killer: dynamic fees scale cubically with how hard you shove the price. • ≤10% move → 0.3% base • 20% → ~8× • ~70%+ → capped at 99% A trade that yanks price 120× would hit the 99% cap. The backrun's arb margin evaporates — predatory MEV becomes too expensive to bother. 4. The takeaway from this $2M loss: slippage + MEV aren't edge cases. They're structural. Likwid taxes the exact behavior that makes these attacks profitable — at the pool level, no oracle required. 👉 https://t.co/p3vsC8TEJC #DeFi #MEV
Most leverage blowups trace back to one thing: a price feed someone could push. Likwid has no feed to push. • Liquidations price off pool reserves, slippage-adjusted • Dynamic fees scale cubically — a 20% push pays ~8x the base fee • Truncated price kills single-block flash attacks #DeFi #MEV #DeFiSecurity