Liquidation Heist: Breaking down the reUSD oracle manipulation attack Last night an unknown wallet executed an oracle price manipulation attack which exposed highly levered looping trades in the PT-reUSD-10DEC2026/USDC Morpho market to be liquidated, resulting in $35,188,279 of liquidations and a net profit of $920,781 for the attacker. In this post I break down exactly what happened and what we can learn from it. The Morpho Market Setup In the last months, loopers have been flocking to a new form of yield arbitrage between reinsurance capital from Re (.xyz) and onchain borrow rates. The market which was attacked was the PT-reUSD-10DEC2026/USDC, which at it’s recent peak had $70m of borrows. The primary use case for this market was to loop reUSD Pendle PTs, which were consistently earning about 10-11% fixed yield against the 8.8% average borrow rate in this market. At a Liquidation Loan-To-Value (LLTV) of 91.5%, loopers could lever up to 10.5 times and as a result achieve an annual yield of 34.6%. Since reUSD is a senior tranche reinsurance token, that is immediately redeemable onchain against a cash buffer the size of 50% of its supply (source: re docs) - the risk of holding reUSD is in theory fairly low from both a strategy and duration point of view, making it a suitable candidate for looping trades. As a result, this Morpho market attracted tons of borrowers and lenders (including vaults from Wintermute, Steakhouse, RockawayX, Clearstar, Keyrock - none of which lost any funds in this event). The crucial kink in the armor of this trade from a loopers point of view, was the oracle configuration. It is configured as: PT/USDC price = min(Pendle 15-minute PT-to-USDC TWAP, 6% linear-discount curve). So it is the lower of either of the two rates: A linear discount model or a 15min time weighted average price (TWAP) of the PT denominated in USDC. Steakhouse eloquently expressed the case for this design (which I agree with) as “generally good practice for Pendle oracles to mitigate the possibility of bad debt in the event of an impairment in the underlying asset. “ In practice, what this means is that if there is an impairment of the underlying reUSD, the oracle will pick this up. The alternative which many markets deploy is to hardcode the price with a time-decay curve which can result in bad debt if the underlying is impaired as we have seen multiple times in the past. Fundamentally, the design is a risk transfer from borrowers to lenders. The position becomes safer for lenders to underwrite, but exposes borrowers at extreme levels of leverage to liquidation in the event of even a small impairment of reUSD or the PT. The attack On Aug-25-2026 04:28:47 AM UTC a wallet (0x854e3f3b521dbae34cb111ebef0dce41d8b5690d) freshly funded with 1m$ from Gate, mints 1m$ worth of reUSD, converts it to Pendle SY reUSD and proceeds to use the funds to aggressively purchase YT-reUSD-10DEC2026, which has the consequence of roughly doubling the YT price from 0.029 to 0.0575, consequently dropping the PT side to to 0.9425 at the bottom (the Pendle chart below doesn’t show the true bottom). Because borrower LTV ratios are calculated based on the value of the PTs as collateral, and these dropped in value by ~3%, this was sufficient to cause a cascade of liquidations. Liquidators earn a 2.616% incentive to perform liquidations in this event, which resulted in $920,781 in collected oracle bonuses. The main liquidator contract (0x51a453d677396F62fbb1dff9925a205fa96fAB5e) was funded by the same Gate wallet at the same time as the oracle manipulator address, so we can safely assume this was the same actor. Borrowers lost a total of $1,203,803 from the oracle bonus and liquidation at an unfavorable market rate. Because of relatively high rate of effective leverage, the equity losses amounted to approximately 30-40% for the affected borrowers (see img below). The legality of this market operation is dubious at best. Given the funds came from a CEX at a relatively large size, it should be possible to trace the manipulation back to a specific entity. The legal precedence here is unclear, but this smells like crime. Oracle design The fundamental question this event raises is one of oracle design. Is it wise, to configure markets with 15 min TWAPs on thin liquidity, and support 70m$ of borrow capacity? I would argue the design is better than hardcoding oracles as many PT looping markets do, which has blown up for lenders more than once. A major challenge for borrowers is understanding the risks present in oracle design - which I believe as an ecosystem we need to do a better job at communicating. It is a wide and unstandardized design space, that is highly technical, which has huge implications on the risk for both borrowers and lenders. The devil, is truly in the detail. In this case, the oracle meant a risk transfer from lenders to borrowers. At the same time, borrowers are able to capture 34.6% yields at 10x leverage, so you might rightfully say “no wonder this comes at some risk!” - If you are levered to your tits and earning 30%+ yield, then you simply cannot cry in the casino. I do think there is a fair critique to the oracle set-up in terms of it’s configuration compared to it’s design objectives. If the goal is to guard against impairment of reUSD - the oracle configuration should perhaps have some check against underlying impairment, before printing a lower value. This could balance both the needs of borrowers and lenders, without enabling this type of heist. Relying on Pendle secondary prices at a 15m TWAP, can be relatively easily manipulated, even with $30m+ of liquidity, as we saw today. At the same time, we cannot truly say the current design had a “bug”, in a sense the bug for the borrower is a feature for the lender. Every blow-up is a chance to make the system itself more resilient, having spent a fair bit of time underwriting vault risk I think it is clear we have come quite far over the past year in terms of risk management and oracle configurations, but there is more work to be done. Onwards. Give @robdogeth to stay up to date on crypto and vault risk.

It might be all of finance, including offchain banking, actually should be in bunker mode

Four significant model releases in a week, and the interesting part is how differently they trade off. Fable 5.1 is still the best coder. I run it on low, which now feels comparable to the previous version at max. Astra is stronger at reasoning and planning and weaker at code, so it gets everything that is not code. Cheaper than Fable and about as fast. Gemini Flash is around 100x cheaper and roughly on par with Opus 5, and it is the first Google model I would actually reach for. Muse is in the same class on speed and price. Knowing which model to point at which job has become its own skill.

Fable 5.1 is insanely good In one shot, it was able to increase the speed of a monte carlo model I built by over 10x whilst maintaining byte-identical outputs. It is truly a new level of commercially available machine intelligence that will unlock the development of more complex products using AI. What is available behind the scenes at Anthrophic is likely much further advanced than Fable 5.1. If Fable could enact such levels of complex optimization, I think it is reasonable to assume that internally similar models can autonomously accelerate and optimize the development of LLMs at Anthrophic. There is a wide debate about when we will reach RSI (recursive self improvement) of models. I would argue on some level we must already be there. Even if the whole architecture and development is not autonomous, Fable 5.1 is at a level of intelligence where it can meaningfully contribute towards model development and optimization, autonomously. Fable will get distilled by open source in a matter of weeks/months, such that the rest of the ecosystem catches up. When they do, Anthrophic will release the next model, and so forth. There is no incentive for Anthrophic to release their best models, because whatever gets released will rapidly be copied. As such, there is really no way to tell how far along Anthrophic and Open AI are internally as they harvest the results of RSI. The level of capability we are just now getting access to, was already available to selected partners 6 months ago (Mythos). The Hugging Face incident further illuminated the size of the gap between what insiders and the public have access to. What is becoming abundantly clear is that access to the true frontier, is becoming increasingly privileged and even if open source catches up to what is commercially available, I they are far behind what the frontier has to offer behind the scenes, and as RSI accelerates development the gap might only be increasing.

The smart contract auditing business will not exist in 12 months

The agentic future is here

Over the last couple of weeks I’ve been running agentic workflows that don’t break on long tasks. The problem with orchestrating a big job through a single agent is that the orchestrator gets overloaded. It’s holding the whole plan, all the context, and every sub-task in one place. Past a certain point, it simply degrades. The fix we developed at Cork was to stop treating orchestration as one layer. Now, a sub-agent can itself be an orchestrator. So there’s a meta-orchestrator at the top that breaks the job into waves, and each wave gets its own orchestrator sub-agent that manages the actual agent workers underneath it. The top level never has to hold everything at once; it delegates whole phases down. In practice, this means a single skill can spin up as many orchestrators as the task needs instead of being capped by what one agent can track. I’ve run 12 hour tasks this way, and it holds up. We’ve folded this workflow into our execution skill, so that pattern now supports a lot of what we run internally at Cork; risk memo generation, market underwriting, and other multi-stage tasks that used to choke previous agent setups. There is, of course, still a ceiling to how big a task you can decompose before the overhead of multi-agent coordination eclipses the benefits. I haven’t quite found that ceiling yet, but the pattern emerging is pretty clear: long-horizon agent work is a matter of delegation, not of context.

How novel frontier models has radically changed skills engineering For a while, my team has been at the cutting edge of AI skills engineering, adopting sophisticated pipelines involving novel methods for orchestration, reinforcement learning loops and layers of context engineering. With the release of Fable, GPT 5.6 and Opus 5, we noticed major regressions across our stack. We sought out to investigate this further and have arrived at several interesting conclusions as it relates to skills engineering in the paradigm of these new highly capable reasoning models. Why legacy skills are regressing performance? The frontier of prompt and skills engineering in the days of Opus 4.3-4.8, surrounded making a less capable agent, think harder and perform reasoning steps, whilst managing a limited useful context window. This was achieved by splitting work into many discrete steps, with optimized context loads and bespoke orchestration patterns to manage all of it. The net result, was that you could make a collection of agents actively reason and perform highly complex tasks. Achieving Fable like performance 6+ months ago. What changed with the latest generation of models, is that these steps have largely been internalized in the reasoning element of the model. I theorize, that the models have largely been trained on the existing base of skills that users have leveraged in the past, as such largely incorporating skills pipelines into the foundation. In this paradigm, a simple prompt without a skill, effectively costs and behaves as the past models would do with a complex skill. If you then additionally apply this heavy skill machinery on a complex reasoning model, you end up with the models massively over-thinking. Surprisingly, we found as a result, the new models began to actively skipping pipeline steps. We thought skipping the steps caused regression, but in reality it made the models more performant. It is interesting the model understood that the instructions were not helpful to the goal and knew better than to follow them blindly. See below screenshot of real results comparing Fable and Opus 5 on a solidity coding task, comparing a new simplified version of our skills, the legacy skill running normally and the legacy skill running normally but enforcing all steps in the process. A few interesting conclusions can be drawn: 1. Generally on a cost/time/quality basis, simplified skills outperform complex legacy skills 2. Skipping steps generally improves the time/cost/quality tradeoff quite meaningfully, which means the models intuition of skipping steps actually is beneficial to the user 3. Running the full legacy skill without skipping steps is extremely expensive/slow in the context of an advanced reasoning model Adapting to the new paradigm We have ran several similar tests and benchmarks, and the general direction of travel we see in terms of skill and prompt engineering is one of simplification. The purpose of a skill is no longer to enforce reasoning, but rather to guide it. Provide context references, style guidance, output validation etc. - but doing so in the context of single or a very narrow set of agents. Our large skills pipelines had all of these core elements, bundled together with a huge orchestration machinery which now gets in the way. The same applies to claude md files and prompts, which should be simplified as well. You don't need to tell the agent, "don't make mistakes, my work depends on it" for it to thoroughly reason. Getting the best results with advanced models I would boil down the key behaviors that with current frontier models result in the best performance to the following: 1. Provide rich context on the task 2. Clearly state your intention and goal of the task, articulating what you want done, is more important than ever 3. In repeatable workflows, apply simple skills to enforce format and ways of working In a sense, the advancement of reasoning models has democratized access to high level reasoning agents. Previously, it required advanced skills engineering pipelines, now these pipelines are somewhat redundant as the logic is internalized at the foundational level. The foundational skill of managing context, providing clear instructions and prompts and enforcing workflows in skills is as important as ever with all our benchmarks and tests reinforcing this. The frontier is evolving faster and faster - the above insights may work today, but are going to be obsolete in a few months. It raises real questions around investments in skills pipelines and the longevity of skills. But in my opinion, the performance impact of advanced AI capabilities are simply too attractive to not stay at the frontier. Even if it means rebuilding your whole stack every few months. If you want to stay up to date on AI systems engineering, give @robdogeth a follow for more similar content.

Prompt engineering has changed a lot in the last year and I think most people are still stuck in the old ways of doing it. It used to take a bag of tricks to get good output. Telling the model not to make mistakes, telling it your job depended on the answer. Crafting some complex personality for the AI to embody. All of it was effectively caveats and qualifiers to try to get the AI to “try harder.” That has stopped mattering with the last couple of model generations. They’re smart enough now that those extra tricks are mostly noise. What works now better than anything else is direct intention: saying what you want clearly and completely and letting the agent handle the rest. Basically, it has become a lot simpler. But that performance and ease, of course, comes with a cost that we’re really now just starting to realize. These models have achieved this next bar of performance by throwing a lot more compute at the problem — so they’re slower and more expensive to run.

For a while everyone had effectively unlimited token budgets and the game was token-maxing That’s flipping to token efficiency, which coincidentally will probably require as much time as we were previously spending on our prompt “bag of tricks” The previous mass instinct of just picking the strongest model and using it for everything will continue to prove wildly inefficient for how expensive it gets Contextual selection of different models for different tasks will grow more and more important

Wonder why Claude reset it's usage limits?

This says a lot about how good chat gpt 5.6 is Personally prefer it over fable (especially with how slow/expensive it is) and I am clearly not the only one thinking this way

April 14: DeFi lending is calm, yields at 2.2%. April 19: $13B has fled lending markets, those same yields are at 6.58%. The people who captured the difference didn't panic. Cork's buffer is what makes not panicking possible.

Over the last couple of weeks, I replaced our project management layer at Cork with an agent. The setup is straightforward. A repo holds read credentials for Granola, Slack, Notion, Drive and the Github commits. A scheduled Cronjob fires every 4 hours, pulls the diff since the last run (new transcripts, messages, commits), and runs it through a classifier that maps each artifact to an owner and an active workstream. Output writes to a public dashboard: who’s working on what, what was shipped, status of each feature in development and progress towards quarterly goals etc. No more moving tickets on a kanban; that whole workflow is now automated. The main constraint we built that makes this work: the agent only ingests what’s readable in the shared workspace. A decision made in a DM is invisible. So the team has moved almost everything into public surfaces. Commit frequently to remote, threads in channels instead of DMs. Working in private now has a direct cost (it doesn’t get counted), and working in public now has a direct and measurable benefit. The system still has some limitations and kinks, information that is untracked leaves minor gaps and crunching large volumes of data automatically can at times cause miss-annotations, but it’s directionally where the future of task tracking will go, enabling us to focus on the real work instead of boring reporting tasks.