![0xKaden's tweet photo. yETH Exploit Deep Dive
After spending some time exploring the recent yETH exploit, I quickly realized that it's easily one of the most sophisticated attacks I've ever seen. In fact, it was so complicated that every writeup I read misunderstood at least some part of the attack. This complexity provides for some serious alpha to developers and security researchers who can thoroughly understand the attack, so don't just bookmark this, let's dive in.
Hybrid AMM Curve
To understand this exploit, we first need to understand the underlying mechanism of the protocol. The yETH pool uses an invariant which is a hybrid between constant product and constant sum. If you're familiar with the inner workings of Uniswap, you should be familiar with the constant product behavior, essentially it just adjusts the price according to the reserves. Whereas constant sum results in a constant price between the tokens, regardless of reserves. The yETH hybrid curve behaves like a constant sum when the token reserves are balanced, keeping the price constant, and behaves like a constant product curve when the reserves are imbalanced. This behavior is valuable for pools of assets which have the same value due to the fact that the price is much less sensitive to reserve changes.
Below we have a graph [1] of these different curves. Red: constant product, green: constant sum, blue: hybrid used by the yETH pool.
The First Bug: Breaking The Invariant
Let's zoom in on the `_calc_supply` function. This function uses an iterative approximation to converge to a new supply and constant product term at each iteration, ending the loop once sufficient precision is achieved.
The constant product term (r) is recomputed at each iteration as the current value multiplied by the new supply, divided by the previous supply (`r * sp / s`). Effectively, it scales at the same rate as the supply.
The bug: if the decrease in supply of any given iteration of the solver is large enough, the constant product term can round down to zero. There is no revert to handle this case and once it occurs, each following iteration will remain zero since `0 * x / y = 0`.
Now that we have a zero constant product term, we no longer have a hybrid constant product/constant sum curve, instead we effectively just have a constant sum curve. To understand why this is a problem we have to go back and look at the curves. In the below graph [2], we have the intended curve (red) and the constant sum curve (purple) which is the result of the zero product term.
As we adjust the supply (see desmos graph [2] linked in reply) of these two curves (D), we can see that the reserves increase by the same amount in the middle, where the reserves are balanced, but by different amounts on the outside, where the reserves are imbalanced. This means that as we add/remove liquidity with imbalanced reserves, these two curves will mint/burn a different amount of LP tokens.
Understanding this behavior, the attacker systemically switched between these curves by triggering the zero constant product term when adding liquidity with unbalanced reserves to receive more LP tokens than intended. They then resolved the constant product term back to normal during liquidity removal to receive the correct amount of tokens provided for burning the inflated amount of LP tokens they received. This allowed the attacker to withdraw more tokens than they deposited, which they repeated until the pool was drained of its reserves for a profit of about ~$8m.
The Second Bug: Unexpected Underflow
You thought we were done? Nope, there's yet another bug that the attacker exploited to steal even more funds after already completely draining the pool.
Now that the pool is empty, and variables used for accounting are in such an unusual state, there is a significant side effect which occurs when we attempt to deposit certain dust amounts. Again, looking in the `_calc_supply` function, when we iteratively recompute the supply, we compute it with the following line (`(l - s * r) / d`):
Since we use unchecked math here and the accounting is in a highly irregular state, it's unexpectedly possible for `s * r > l`, resulting in the computed supply underflowing. The attacker exploits this underflow by depositing the following amounts: `[1, 1, 1, 1, 1, 1, 1, 9]`, resulting in them being minted `~2.6*10^56` yETH LP tokens. The attacker then makes a swap on the curve yETH/WETH pool, draining the pool of its WETH, for a profit of ~$1m.
Conclusion
Not only did this attack include a highly sophisticated AMM invariant exploit, but it also exploited an underflow which is likely only possible due to the existence of the invariant exploit. This combination of exploits allowed the attacker to not only drain the yETH pool, but also another pool containing the LP token. Both attacks, and even tornado cash deposits were all made in the same transaction, preventing any chance at rescue.
In my research, every writeup I came across misunderstood this attack in some way. Clearly, it's extremely rare to understand such a sophisticated exploit, providing for some serious alpha to developers and security researchers to fully wrap their heads around this.](https://pbs.twimg.com/media/G7V-9O0b0AEdU36.png)
![0xKaden's tweet photo. yETH Exploit Deep Dive
After spending some time exploring the recent yETH exploit, I quickly realized that it's easily one of the most sophisticated attacks I've ever seen. In fact, it was so complicated that every writeup I read misunderstood at least some part of the attack. This complexity provides for some serious alpha to developers and security researchers who can thoroughly understand the attack, so don't just bookmark this, let's dive in.
Hybrid AMM Curve
To understand this exploit, we first need to understand the underlying mechanism of the protocol. The yETH pool uses an invariant which is a hybrid between constant product and constant sum. If you're familiar with the inner workings of Uniswap, you should be familiar with the constant product behavior, essentially it just adjusts the price according to the reserves. Whereas constant sum results in a constant price between the tokens, regardless of reserves. The yETH hybrid curve behaves like a constant sum when the token reserves are balanced, keeping the price constant, and behaves like a constant product curve when the reserves are imbalanced. This behavior is valuable for pools of assets which have the same value due to the fact that the price is much less sensitive to reserve changes.
Below we have a graph [1] of these different curves. Red: constant product, green: constant sum, blue: hybrid used by the yETH pool.
The First Bug: Breaking The Invariant
Let's zoom in on the `_calc_supply` function. This function uses an iterative approximation to converge to a new supply and constant product term at each iteration, ending the loop once sufficient precision is achieved.
The constant product term (r) is recomputed at each iteration as the current value multiplied by the new supply, divided by the previous supply (`r * sp / s`). Effectively, it scales at the same rate as the supply.
The bug: if the decrease in supply of any given iteration of the solver is large enough, the constant product term can round down to zero. There is no revert to handle this case and once it occurs, each following iteration will remain zero since `0 * x / y = 0`.
Now that we have a zero constant product term, we no longer have a hybrid constant product/constant sum curve, instead we effectively just have a constant sum curve. To understand why this is a problem we have to go back and look at the curves. In the below graph [2], we have the intended curve (red) and the constant sum curve (purple) which is the result of the zero product term.
As we adjust the supply (see desmos graph [2] linked in reply) of these two curves (D), we can see that the reserves increase by the same amount in the middle, where the reserves are balanced, but by different amounts on the outside, where the reserves are imbalanced. This means that as we add/remove liquidity with imbalanced reserves, these two curves will mint/burn a different amount of LP tokens.
Understanding this behavior, the attacker systemically switched between these curves by triggering the zero constant product term when adding liquidity with unbalanced reserves to receive more LP tokens than intended. They then resolved the constant product term back to normal during liquidity removal to receive the correct amount of tokens provided for burning the inflated amount of LP tokens they received. This allowed the attacker to withdraw more tokens than they deposited, which they repeated until the pool was drained of its reserves for a profit of about ~$8m.
The Second Bug: Unexpected Underflow
You thought we were done? Nope, there's yet another bug that the attacker exploited to steal even more funds after already completely draining the pool.
Now that the pool is empty, and variables used for accounting are in such an unusual state, there is a significant side effect which occurs when we attempt to deposit certain dust amounts. Again, looking in the `_calc_supply` function, when we iteratively recompute the supply, we compute it with the following line (`(l - s * r) / d`):
Since we use unchecked math here and the accounting is in a highly irregular state, it's unexpectedly possible for `s * r > l`, resulting in the computed supply underflowing. The attacker exploits this underflow by depositing the following amounts: `[1, 1, 1, 1, 1, 1, 1, 9]`, resulting in them being minted `~2.6*10^56` yETH LP tokens. The attacker then makes a swap on the curve yETH/WETH pool, draining the pool of its WETH, for a profit of ~$1m.
Conclusion
Not only did this attack include a highly sophisticated AMM invariant exploit, but it also exploited an underflow which is likely only possible due to the existence of the invariant exploit. This combination of exploits allowed the attacker to not only drain the yETH pool, but also another pool containing the LP token. Both attacks, and even tornado cash deposits were all made in the same transaction, preventing any chance at rescue.
In my research, every writeup I came across misunderstood this attack in some way. Clearly, it's extremely rare to understand such a sophisticated exploit, providing for some serious alpha to developers and security researchers to fully wrap their heads around this.](https://pbs.twimg.com/media/G7V-uW8bsAAE--w.png)
![0xKaden's tweet photo. yETH Exploit Deep Dive
After spending some time exploring the recent yETH exploit, I quickly realized that it's easily one of the most sophisticated attacks I've ever seen. In fact, it was so complicated that every writeup I read misunderstood at least some part of the attack. This complexity provides for some serious alpha to developers and security researchers who can thoroughly understand the attack, so don't just bookmark this, let's dive in.
Hybrid AMM Curve
To understand this exploit, we first need to understand the underlying mechanism of the protocol. The yETH pool uses an invariant which is a hybrid between constant product and constant sum. If you're familiar with the inner workings of Uniswap, you should be familiar with the constant product behavior, essentially it just adjusts the price according to the reserves. Whereas constant sum results in a constant price between the tokens, regardless of reserves. The yETH hybrid curve behaves like a constant sum when the token reserves are balanced, keeping the price constant, and behaves like a constant product curve when the reserves are imbalanced. This behavior is valuable for pools of assets which have the same value due to the fact that the price is much less sensitive to reserve changes.
Below we have a graph [1] of these different curves. Red: constant product, green: constant sum, blue: hybrid used by the yETH pool.
The First Bug: Breaking The Invariant
Let's zoom in on the `_calc_supply` function. This function uses an iterative approximation to converge to a new supply and constant product term at each iteration, ending the loop once sufficient precision is achieved.
The constant product term (r) is recomputed at each iteration as the current value multiplied by the new supply, divided by the previous supply (`r * sp / s`). Effectively, it scales at the same rate as the supply.
The bug: if the decrease in supply of any given iteration of the solver is large enough, the constant product term can round down to zero. There is no revert to handle this case and once it occurs, each following iteration will remain zero since `0 * x / y = 0`.
Now that we have a zero constant product term, we no longer have a hybrid constant product/constant sum curve, instead we effectively just have a constant sum curve. To understand why this is a problem we have to go back and look at the curves. In the below graph [2], we have the intended curve (red) and the constant sum curve (purple) which is the result of the zero product term.
As we adjust the supply (see desmos graph [2] linked in reply) of these two curves (D), we can see that the reserves increase by the same amount in the middle, where the reserves are balanced, but by different amounts on the outside, where the reserves are imbalanced. This means that as we add/remove liquidity with imbalanced reserves, these two curves will mint/burn a different amount of LP tokens.
Understanding this behavior, the attacker systemically switched between these curves by triggering the zero constant product term when adding liquidity with unbalanced reserves to receive more LP tokens than intended. They then resolved the constant product term back to normal during liquidity removal to receive the correct amount of tokens provided for burning the inflated amount of LP tokens they received. This allowed the attacker to withdraw more tokens than they deposited, which they repeated until the pool was drained of its reserves for a profit of about ~$8m.
The Second Bug: Unexpected Underflow
You thought we were done? Nope, there's yet another bug that the attacker exploited to steal even more funds after already completely draining the pool.
Now that the pool is empty, and variables used for accounting are in such an unusual state, there is a significant side effect which occurs when we attempt to deposit certain dust amounts. Again, looking in the `_calc_supply` function, when we iteratively recompute the supply, we compute it with the following line (`(l - s * r) / d`):
Since we use unchecked math here and the accounting is in a highly irregular state, it's unexpectedly possible for `s * r > l`, resulting in the computed supply underflowing. The attacker exploits this underflow by depositing the following amounts: `[1, 1, 1, 1, 1, 1, 1, 9]`, resulting in them being minted `~2.6*10^56` yETH LP tokens. The attacker then makes a swap on the curve yETH/WETH pool, draining the pool of its WETH, for a profit of ~$1m.
Conclusion
Not only did this attack include a highly sophisticated AMM invariant exploit, but it also exploited an underflow which is likely only possible due to the existence of the invariant exploit. This combination of exploits allowed the attacker to not only drain the yETH pool, but also another pool containing the LP token. Both attacks, and even tornado cash deposits were all made in the same transaction, preventing any chance at rescue.
In my research, every writeup I came across misunderstood this attack in some way. Clearly, it's extremely rare to understand such a sophisticated exploit, providing for some serious alpha to developers and security researchers to fully wrap their heads around this.](https://pbs.twimg.com/media/G7V-KNcb0AA9XDy.png)
Olivia
Online
Hippo Potato
@hippo_potato
Joined November 2021
409 Following
159 Followers
405 Posts
1/ Many DeFi hacks aren't atomic.
We reconstructed per-tx timelines for 10 exploits where the drain ran for minutes to hours to ask one question: how much could have been saved after the first malicious tx?
🧵
The DeFi United effort has been one of the most impressive moments of collective action this space has ever seen.
The entire ecosystem rallied to make the affected users whole. A story that, against the odds, looks like it ends well.
However. There is one last piece that is missing. I'm talking about @LayerZero_Core.
After multiple attempts to reach out both publicly and privately, we still haven't heard from your team. @PrimordialAA tagging you here in case you can provide some clarity.
Aave is contributing 25,000 $ETH. Kelp is contributing 2,000 $ETH (70% of their treasury making it clear they want to make things right). We've got a bunch of protocols that were not even affected contributing hundreds or thousands of ETH. But we still have not heard the amount that LZ will be putting towards making the users whole.
I'll be honest: it feels like LZ has been waiting for the situation to resolve itself before making any commitment. That's not a good look. And it matters, because transparency on this is the last thing standing between a clean resolution and a lingering question mark over the whole effort.
Three direct questions that I'd genuinely welcome answers to from anyone close to the team:
1 - Will there be *any* financial contribution from LZ towards the DeFi United initiative? If yes, what is the amount? If not, what's the rationale?
2 - What role has LZ played in the recovery so far beyond the initial statement?
3 - It's been 5 days since that statement. What are the next steps?
You still have a window to make this right. DMs are open here and on TG.
went through layerzero gasolina aws deployment repo + extracted app source.
tl;dr concerning
the reference deployment is public by design. and the sample providers.json ships with rpc quorum: 1 on every mainnet chain.
1. the recommended cdk stack puts a public api gateway in front of a private alb in front of fargate in private subnets. publicLoadBalancer: false, taskSubnets: PRIVATE_WITH_NAT, and an HttpApi with HttpAlbIntegration. the readme literally tells operators to send the resulting ApiGatewayUrl to layerzero labs.
2. no authorizer, no iam auth mode, no ip allowlist, no waf, no route-level policy anywhere in the repo. the app itself (bootstrap.ts) registers /provider-health, which leaks configured rpcs. server.listen(port) without host arg binds to public ip.
3. cdk/gasolina/config/providers/mainnet/providers.json sets quorum: 1 for ethereum, bsc, polygon, arbitrum, optimism, fantom, and the rest. multiple rpc urls are configured as failover, not consensus. the multiprovider code only enforces quorum when quorum > 1 and explicitly bypasses the wrapper when it's 1. rpcs are mostly public endpoints (llamarpc, publicnode, ankr).
4. provider config lives in an s3 bucket that the cdk stack creates, uploads to, and passes via env vars (PROVIDER_CONFIG_TYPE, CONFIG_BUCKET_NAME). so the trust boundary is the app + the mutable config plane + the upstream rpc tier + whatever's in front of api gateway.
5. operators are told to validate by curling the public url for /available-chains, /signer-info?chainName=ethereum, /provider-health (again, leaks rpc). external reachability is an encouraged documented requirement.
caveats: this is the public repo and extracted non-public source. it doesn't prove the config they had for kelp bridge. but the public info and the defaults the operators are pointed at look concerning.
read more here: https://t.co/ZR5bwLzCEn
Bridged $DOT (@Polkadot) was exploited on Ethereum 30 mins ago.
Admin changed to the attacker's contract, 1 BILLION $DOT minted and immediately dumped. Price went from $1.22 to fractions of a cent.
Stop scrolling. This might be one of the most important thing happening on Hyperliquid right now and almost nobody is talking about it.
What you're looking at is the first independent client achieving block hash parity with Hyperliquid validators.
For non-technical people: Hyperliquid hasn't open-sourced its node client. The code that runs the network is a compiled binary, a black box. @androolloyd took that black box, 87MB of machine code with no documentation, and reverse-engineered it using AI and Ghidra. He decoded every formula, every structure, every protocol. Then he built his own client from scratch that produces the exact same results as the official validators. 3/3 match.
For technical people: full verification chain cracked. keccak256 on raw msgpack for block response hashes. blake3 keyed for consensus transactions. LtHash16 with SSE2 paddw across 14 accumulators (11 L1 + 3 EVM) finalized with SHA-256 for state hashing. All reproduced independently from a stripped ELF binary with zero source code.
What this means: anyone can now verify the Hyperliquid chain independently without trusting the official binary. This is the foundation for a truly decentralized validator set where operators don't depend on one codebase. Independent implementations make the network stronger, more resilient, and harder to compromise.
The team didn't open-source the client. So someone reverse-engineered it and built one anyway. That's the kind of ecosystem Hyperliquid has.
I'll be covering this work in depth over the coming days to make sure everyone understands the magnitude of what's being built here.
Legendary work happening in real time.
Hyperliquid.
https://t.co/i6kBwb32Da
** Correction on key compromise **
A week ago, Drift moved to a new multisig, created by a signer from the old multisig. This signer did not add themselves to the new one.
The exploiter also initiated the proposal in the old multisig to hand over admin control to this new wallet.
Of the 5 signers on the new multisig, only 1 came from the previous setup; the other 4 were brand-new.
The wallet was set with a 2/5 threshold and a 0-second timelock.
~Five hours ago, that sole carryover signer used the new multisig to propose changing Drift’s admin.
One of the new signers co-signed a second later, instantly meeting the 2/5 threshold.
With no timelock in place, the transaction was executed immediately.
** Note **
Some of the relevant Solana programs are not verified, which limits full analysis.
We're continuing to dig into the onchain data and will publish a more thorough post-mortem covering the multisig migration, Solana DeFi contagion, and vault exposure in a follow-up.
aside from the multisig compromise, why does a protocol with 9fig tvl not have timelocks for adding new assets or disabling withdrawal safeguards?
the whole attack worked because listing a new collateral type and disabling withdrawal guards happened in one transaction.
just make that take 48 hours.
the community would have looked at a token backed by $700 of raydium liquidity and killed it immediately.
we keep building better dashboards and alerts but the actual answer is just making the dangerous admin stuff slow enough that humans can react.
A partial liquidation can leave bad debt and drain a borrower's entire collateral, even at HF = 0.99, if LT * (1 + bonus) >= 1.
@D4r3_D3v1L_ checked 22 protocols using partial liquidation. 4 are vulnerable, 6 have on-chain constraint.
I wrote two posts breaking this down:
https://t.co/5yxfNZ8l1s
The IMF has published "Understanding Stablecoins" - their most comprehensive take on the space yet.
It's 56 pages. Here's our recap 🧠👇
1. The stablecoin market doubled in 2 years
Stablecoin issuance hit ~$300 billion by September 2025. But that's still only 7% of total crypto market cap, and just 0.5% of US stock market cap.
- USDT and USDC own ~90% of the market
- 97% of all stablecoins are pegged to the dollar
- Combined trading volume for USDT and USDC was $23 trillion in 2024, up 90% from 2023.
2. 80% of stablecoin transactions are bots
Not humans buying coffee, but arbitrage, rebalancing, automated systems.
- The "crypto payments revolution" is real, but still very early.
- The fastest-growing actual use case for stablecoins is cross-border payments
- Stablecoin cross-border flows have overtaken Bitcoin and Ethereum since early 2022
3. Not Europe or the USA, emerging markets are leading stablecoin adoption
Africa, the Middle East, and Latin America are ahead, not the US or Asia.
- Stablecoin flows between emerging economies are now the largest share of cross-border activity by value
- That's the opposite of traditional SWIFT payments, which are dominated by developed countries
- Net flows go from North America outward, which means people in developing countries are using stablecoins as a dollar savings account.
4. Most holders can't redeem their stablecoins directly
Tether requires a $100K minimum and platform registration to redeem.
Retail users have to sell on exchanges, where the price can slip below $1.
We've already seen the peg break.
- USDC dropped to $0.88 when Silicon Valley Bank collapsed in March 2023. Circle had $3.3B stuck there
- USDT broke parity during the TerraUSD collapse in May 2022
- Both recovered in ~2 days. But scale that up, and the IMF says it could hit Treasury and repo markets hard.
5. Tether's reserves are still a question mark
USDC is managed by BlackRock. 40% T-bills, 45% overnight reverse repos. 14-day average maturity. Meanwhile,
Tether reserves ~75% in T-bills and repos, as well as ~5% Bitcoin and ~5% gold, domiciled in El Salvador. There is still no full independent audit
The US GENIUS Act says foreign issuers need "comparable" home regulation to operate in the US. Whether El Salvador qualifies is anyone's guess.
6. Dollar stablecoins could dollarize entire economies
This is the macro risk the IMF is most concerned about.
In Latin America and Africa/ME, stablecoin holdings went from basically zero in 2020 to 1.5-2.7% of total deposits by 2024.
The percentage looks small. But the growth curve is steep.
Unlike normal dollarization, which needs bank accounts or physical cash, stablecoins just need a phone.
If enough economic activity shifts to dollar-backed stablecoins, central banks lose control of local monetary policy.
Seigniorage income drops. Currency sovereignty erodes.
7. Regulation is moving fast, but in different directions
- EU's MiCA: live and most comprehensive
- US GENIUS Act: just passed
- Japan: amended Payment Services Act
- The UK: still consulting
But they disagree on who can issue, how reserves are held, redemption rules, and how foreign issuers are treated.
The IMF calls this fragmentation a major regulatory arbitrage risk.
Tether operating from El Salvador while issuing the world's biggest dollar stablecoin is a case study.
8. Stablecoin growth projections from institutions
- JPMorgan: $500B by 2028
- US Treasury Secretary Bessent: $3.7 trillion by the end of the decade
If anything near the high end happens, stablecoins become major holders of US T-bills.
That starts compressing yields. Which has real implications for how monetary policy works.
In a nutshell:
- Stablecoins aren't a crypto sideshow anymore
- They're becoming infrastructure for cross-border payments, dollar access in emerging markets, and tokenized finance
- But 80% of activity is still bots
- Most users can't redeem directly
- The biggest issuer hasn't been fully audited
- Global regulation is fragmented
The real risk isn't one stablecoin blowing up.
It's systemic plumbing being built on instruments that still lack consistent global oversight.
yETH Exploit Deep Dive
After spending some time exploring the recent yETH exploit, I quickly realized that it's easily one of the most sophisticated attacks I've ever seen. In fact, it was so complicated that every writeup I read misunderstood at least some part of the attack. This complexity provides for some serious alpha to developers and security researchers who can thoroughly understand the attack, so don't just bookmark this, let's dive in.
Hybrid AMM Curve
To understand this exploit, we first need to understand the underlying mechanism of the protocol. The yETH pool uses an invariant which is a hybrid between constant product and constant sum. If you're familiar with the inner workings of Uniswap, you should be familiar with the constant product behavior, essentially it just adjusts the price according to the reserves. Whereas constant sum results in a constant price between the tokens, regardless of reserves. The yETH hybrid curve behaves like a constant sum when the token reserves are balanced, keeping the price constant, and behaves like a constant product curve when the reserves are imbalanced. This behavior is valuable for pools of assets which have the same value due to the fact that the price is much less sensitive to reserve changes.
Below we have a graph [1] of these different curves. Red: constant product, green: constant sum, blue: hybrid used by the yETH pool.
The First Bug: Breaking The Invariant
Let's zoom in on the `_calc_supply` function. This function uses an iterative approximation to converge to a new supply and constant product term at each iteration, ending the loop once sufficient precision is achieved.
The constant product term (r) is recomputed at each iteration as the current value multiplied by the new supply, divided by the previous supply (`r * sp / s`). Effectively, it scales at the same rate as the supply.
The bug: if the decrease in supply of any given iteration of the solver is large enough, the constant product term can round down to zero. There is no revert to handle this case and once it occurs, each following iteration will remain zero since `0 * x / y = 0`.
Now that we have a zero constant product term, we no longer have a hybrid constant product/constant sum curve, instead we effectively just have a constant sum curve. To understand why this is a problem we have to go back and look at the curves. In the below graph [2], we have the intended curve (red) and the constant sum curve (purple) which is the result of the zero product term.
As we adjust the supply (see desmos graph [2] linked in reply) of these two curves (D), we can see that the reserves increase by the same amount in the middle, where the reserves are balanced, but by different amounts on the outside, where the reserves are imbalanced. This means that as we add/remove liquidity with imbalanced reserves, these two curves will mint/burn a different amount of LP tokens.
Understanding this behavior, the attacker systemically switched between these curves by triggering the zero constant product term when adding liquidity with unbalanced reserves to receive more LP tokens than intended. They then resolved the constant product term back to normal during liquidity removal to receive the correct amount of tokens provided for burning the inflated amount of LP tokens they received. This allowed the attacker to withdraw more tokens than they deposited, which they repeated until the pool was drained of its reserves for a profit of about ~$8m.
The Second Bug: Unexpected Underflow
You thought we were done? Nope, there's yet another bug that the attacker exploited to steal even more funds after already completely draining the pool.
Now that the pool is empty, and variables used for accounting are in such an unusual state, there is a significant side effect which occurs when we attempt to deposit certain dust amounts. Again, looking in the `_calc_supply` function, when we iteratively recompute the supply, we compute it with the following line (`(l - s * r) / d`):
Since we use unchecked math here and the accounting is in a highly irregular state, it's unexpectedly possible for `s * r > l`, resulting in the computed supply underflowing. The attacker exploits this underflow by depositing the following amounts: `[1, 1, 1, 1, 1, 1, 1, 9]`, resulting in them being minted `~2.6*10^56` yETH LP tokens. The attacker then makes a swap on the curve yETH/WETH pool, draining the pool of its WETH, for a profit of ~$1m.
Conclusion
Not only did this attack include a highly sophisticated AMM invariant exploit, but it also exploited an underflow which is likely only possible due to the existence of the invariant exploit. This combination of exploits allowed the attacker to not only drain the yETH pool, but also another pool containing the LP token. Both attacks, and even tornado cash deposits were all made in the same transaction, preventing any chance at rescue.
In my research, every writeup I came across misunderstood this attack in some way. Clearly, it's extremely rare to understand such a sophisticated exploit, providing for some serious alpha to developers and security researchers to fully wrap their heads around this.
![0xKaden's tweet photo. yETH Exploit Deep Dive
After spending some time exploring the recent yETH exploit, I quickly realized that it's easily one of the most sophisticated attacks I've ever seen. In fact, it was so complicated that every writeup I read misunderstood at least some part of the attack. This complexity provides for some serious alpha to developers and security researchers who can thoroughly understand the attack, so don't just bookmark this, let's dive in.
Hybrid AMM Curve
To understand this exploit, we first need to understand the underlying mechanism of the protocol. The yETH pool uses an invariant which is a hybrid between constant product and constant sum. If you're familiar with the inner workings of Uniswap, you should be familiar with the constant product behavior, essentially it just adjusts the price according to the reserves. Whereas constant sum results in a constant price between the tokens, regardless of reserves. The yETH hybrid curve behaves like a constant sum when the token reserves are balanced, keeping the price constant, and behaves like a constant product curve when the reserves are imbalanced. This behavior is valuable for pools of assets which have the same value due to the fact that the price is much less sensitive to reserve changes.
Below we have a graph [1] of these different curves. Red: constant product, green: constant sum, blue: hybrid used by the yETH pool.
The First Bug: Breaking The Invariant
Let's zoom in on the `_calc_supply` function. This function uses an iterative approximation to converge to a new supply and constant product term at each iteration, ending the loop once sufficient precision is achieved.
The constant product term (r) is recomputed at each iteration as the current value multiplied by the new supply, divided by the previous supply (`r * sp / s`). Effectively, it scales at the same rate as the supply.
The bug: if the decrease in supply of any given iteration of the solver is large enough, the constant product term can round down to zero. There is no revert to handle this case and once it occurs, each following iteration will remain zero since `0 * x / y = 0`.
Now that we have a zero constant product term, we no longer have a hybrid constant product/constant sum curve, instead we effectively just have a constant sum curve. To understand why this is a problem we have to go back and look at the curves. In the below graph [2], we have the intended curve (red) and the constant sum curve (purple) which is the result of the zero product term.
As we adjust the supply (see desmos graph [2] linked in reply) of these two curves (D), we can see that the reserves increase by the same amount in the middle, where the reserves are balanced, but by different amounts on the outside, where the reserves are imbalanced. This means that as we add/remove liquidity with imbalanced reserves, these two curves will mint/burn a different amount of LP tokens.
Understanding this behavior, the attacker systemically switched between these curves by triggering the zero constant product term when adding liquidity with unbalanced reserves to receive more LP tokens than intended. They then resolved the constant product term back to normal during liquidity removal to receive the correct amount of tokens provided for burning the inflated amount of LP tokens they received. This allowed the attacker to withdraw more tokens than they deposited, which they repeated until the pool was drained of its reserves for a profit of about ~$8m.
The Second Bug: Unexpected Underflow
You thought we were done? Nope, there's yet another bug that the attacker exploited to steal even more funds after already completely draining the pool.
Now that the pool is empty, and variables used for accounting are in such an unusual state, there is a significant side effect which occurs when we attempt to deposit certain dust amounts. Again, looking in the `_calc_supply` function, when we iteratively recompute the supply, we compute it with the following line (`(l - s * r) / d`):
Since we use unchecked math here and the accounting is in a highly irregular state, it's unexpectedly possible for `s * r > l`, resulting in the computed supply underflowing. The attacker exploits this underflow by depositing the following amounts: `[1, 1, 1, 1, 1, 1, 1, 9]`, resulting in them being minted `~2.6*10^56` yETH LP tokens. The attacker then makes a swap on the curve yETH/WETH pool, draining the pool of its WETH, for a profit of ~$1m.
Conclusion
Not only did this attack include a highly sophisticated AMM invariant exploit, but it also exploited an underflow which is likely only possible due to the existence of the invariant exploit. This combination of exploits allowed the attacker to not only drain the yETH pool, but also another pool containing the LP token. Both attacks, and even tornado cash deposits were all made in the same transaction, preventing any chance at rescue.
In my research, every writeup I came across misunderstood this attack in some way. Clearly, it's extremely rare to understand such a sophisticated exploit, providing for some serious alpha to developers and security researchers to fully wrap their heads around this.](https://pbs.twimg.com/media/G7V_LG3bcAAmYBP.png)
The MEV Capital USDC Market on Morpho has 12% exposure to xUSD, and there's 4.69M of liquidity to withdraw. You should do so ASAP, as the transaction to remove the xUSD Vault from NAV and socialize the losses went out 2d ago, and the timelock is 3d long.
https://t.co/EQeJJ164KY
Link to the vault: https://t.co/m0vyNCGeJN
How to turn $100k into 291 MILLION XPL (or ~$105m at current prices)
A VC invested ~$100k into Plasma equity via a SAFE and purchased token warrants allowing them to buy XPL at a price of ~$0.0000347.
In August 2025 the VC exercised the warrants and bought ~12.5m XPL for $433.75.
To turn this into 291m XPL we need a bit more context:
The original token warrants had a wording error, stating that the amount of XPL they were entitled to was based on the VC's total equity in Plasma - this would have entitled them to 2.6% of XPL's max supply.
The VC already held shares in Plasma due to M&A activities in 2024, and then obtained further equity via the SAFE agreements. In March 2025 they then purchased more equity via secondary markets.
Plasma noticed this error in July 2025 and amended the token warrants to clarify the XPL amount was based solely on the SAFE investment and NOT the total equity held - this entitled the VC to ~12.5m XPL as exercised above.
Since August 2025, the VC has taken the stance that they are entitled to an additional 279 MILLION XPL due to the wording in the original warrants (a total of 291m XPL), claiming that the amendment was invalid.
Plasma have now token the VC to court, asking the court to confirm that the amendments to the token warrants are valid, and that the funds are only entitled to 12.5m XPL.
Funnily enough, a partner of the VC also sits on the board of Plasma.
The courts will now decide whether you can turn $100k into 291m XPL, or only 12.5m XPL.
expectation vs reality
https://t.co/4Jr7ipNBUO
https://t.co/wwn5yY6ZPA
Shibarium was attacked yesterday & the bridge drained for nearly $3m. Here's how it happened👇
1/ Ryoshi Labs' validator (and perhaps others) were compromised or malicious from the start. They proposed a fraudulent checkpoint on Heimdall (Shibarium's consensus engine).
2/ Before the attack, Shibarium consensus was secured by ~15m staked BONE ($7m).
3/ The Ryoshi Labs validator 0x0752 submitted a fraudulent checkpoint.
👉 10/12 validators signed it as valid.
👉 These validators controlled ~40% of the weighted stake with ~6.5m BONE.
👉 The remaining 2 validators with 60% stake didn't sign it.
4/ Normally this checkpoint would be rejected on the Ethereum side, as this requires a >2/3 consensus.
5/ The attacker flash-loaned 6.4m BONE, delegating it to the Ryoshi Labs validator.
👉 Total stake became ~19.7m BONE
👉 Now those 10 validators that signed had just over 66% stake.
6/ This allowed a 2/3 attack, giving those validators the power to finalize any state they wanted on Ethereum.
At this point Shibarium was completely compromised.
7/ With consensus hijacked, all that was left to do was to drain the bridge.
8/ Finally, a portion of the stolen funds were used to repay the flashloan.
10/12 validators signing the fraudulent checkpoint is very strange and raises A LOT of questions
A brief investigation into the 80k BTC whale, and the "Salomon Bros" notices sent via OP_RETURN prior to the movements (TLDR at the bottom).
Salomon Bros was a HUGE investment bank with nearly a 100 year history before being acquired by Citibank in the early 2000s.
They revived separately as Salomon Encore a few years ago. Unclear whether they are currently active, but the CEO R. Adam Smith is well established and has a regular podcast which can be found on youtube.
Now onto the "Salomon Bros" website mentioned in the OP_RETURN messages.
Firstly - the "Salomon Brothers Inc" entity mentioned on the website hasn't existed for more than 25 years.
There was/is a serial trademark squatter targeting a bunch of Financial Institutions over the last 15 years.
They set up legitimate looking domains to make it look like they were doing business (as is the case with Salomon Bros).
Other squatted trademarks/domains (there's many more):
First Boston - https://t.co/MUz6GIDKJm
EF Hutton - https://t.co/3Df4K7tRzd
BayBank - https://t.co/CVmXDayx0H
All very similar layouts to the Salomon bros domain in the messages, and all built with GoDaddy website builder (same entity behind these and the Salomon bros website).
Some of these made their way through trademark courts in the last few years.
The serial trademark squatter has been around for a long time and it's unlikely they've pivoted to outright crime.
The most likely explanation behind these messages is that somebody acquired/hacked the Salomon Bros domain (and its contents) from the serial trademark/domain squatter and is now trying to target high networth crypto accounts.
There's some wallet recovery pages on their site which are private and require authorization to access - but adds more credibility that this is a phishing website.
GoDaddy metadata left behind on their website uses the locale 'en-IN', suggesting the person behind the current website is from India.
imo there are two possible reasons for the BTC movements:
1) The BTC whale seen the messages and moved their funds to be cautious.
2) The BTC whale fell for the phishing attempt, and somebody has contributed $8b to India's GDP.
If it's reason 2, then @jconorgrogan was right when he said this would be by far the largest heist in human history.
Finally, there was a test BCH transaction beforehand and some have questioned why the remaining BCH hasn't moved.
IF this was a successful phish, it's possible the BCH transaction was part of the phishing process ("prove you control the keys"), at which point they were convinced to transfer BTC to the phisher's wallets.
Lots of theorizing, but TLDR - the Salomon Bros OP_RETURN messages are most definitely phishing attempts and have no legitimacy.
As we've seen a lot of discussion around the depeg, let us summarize exactly what caused the movement in the deUSD @chainlink oracle.
First off, the deUSD oracle uses volume-weighted average price (VWAP) methodology. In simpler terms, the oracle assigns prices to the asset based on the price where most of the volume happens.
While highly reliable for uncorrelated assets, the VWAP algorithm is evidently poorly suited for pricing low-liquidity correlated assets. As seen yesterday, a single sandwich trade in a single block accounted for 50% of daily volume, and spiked Chainlink’s reported price.
MEV buy: https://t.co/IqViOaj78r
Victim buy: https://t.co/01Ia4Jn3iC
MEV sell: https://t.co/dTSlUZSpck
In reality, that price was located on a single, smaller DEX pool and lasted for less than a block. Others argued that low-liquidity was the cause, but deUSD is sufficiently liquid, with close to $10M in the top pools.
Furthermore, only the single sandwiched user experienced the price dislocation and reserve ratios returned to parity after the backrun was executed, as is standard with sandwich attacks. The observed inflated price was simply an abberation and not a real event outside of the sandwich.
To summarize, deUSD's "immaturity" or "illiquidity" (not true) was not the cause. Only using a VWAP oracle is just not a good setup for low-volume correlated DeFi assets.
Finally, it is entirely possible sophisticated actors might manipulate low-volume assets VWAP oracles' prices just by trading large volume in the smallest tracked liquidity pool in one block, only losing the trading fees, in order to profit from subsequent liquidations. We therefore urge curators to consider using different methodologies for stablecoin oracles.
We realize that choosing an appropriate oracle for low-volume correlated assets is not easy. In the very least, we would like to see @aave's price cap adapter used more across DeFi. Non-yield bearing stablecoins shouldn't fundamentally trade above 1$, so adding an upper cap just makes sense.
Shoutout @totomanov, as we took a lot of context from your tweets, and thanks to everyone who contributed in the discussion and did not use it as means to promote their own protocol.:)
Most Popular Users
Elon Musk 
@elonmusk
240.3M followers
Barack Obama
@barackobama
119.3M followers
Donald J. Trump
@realdonaldtrump
111.6M followers
Cristiano Ronaldo
@cristiano
109.9M followers
Narendra Modi
@narendramodi
106.9M followers
Rihanna
@rihanna
97.5M followers
NASA
@nasa
92.1M followers
Justin Bieber
@justinbieber
90.7M followers
KATY PERRY
@katyperry
87.3M followers
Taylor Swift
@taylorswift13
81.1M followers
Lady Gaga
@ladygaga
72.7M followers
Kim Kardashian
@kimkardashian
69.6M followers
Virat Kohli
@imvkohli
69.3M followers
YouTube
@youtube
68.6M followers
Bill Gates
@billgates
63.7M followers
The Ellen Show
@theellenshow
62.5M followers
Neymar Jr
@neymarjr
62M followers
CNN
@cnn
61.9M followers
X
@x
60.9M followers
Selena Gomez
@selenagomez
60.4M followers