2 weeks ago by Ondo Finance
Between March 22 and April 19, 2026, onchain finance lost more than $625 million across six major security incidents.
The breadth of these attacks (social engineering, multisig compromise, cross-chain verification failures, DNS hijacking, vendor supply chain compromise) illustrates something important: there is no single class of vulnerability to defend against. Attackers are patient, coordinated, and well-resourced. As DeFi infrastructure grows more layered and operationally complex, the attack surface expands with it.
In the middle of this, many teams paused to assess exposure. Ondo did not. Our bridges stayed live, our assets stayed backed, and stolen funds were quickly frozen, the result of design decisions made well before any of these incidents occurred.
This post is about why we were prepared and why our clients should expect us to be.
Ondo exists to bring institutional-grade assets onchain. The customers who entrust us with that capital – treasuries, allocators, funds, and anyone holding USDY or transacting on Ondo Global Markets – are not paying for smart contracts. They are paying for the confidence that their assets will still be there tomorrow, through the next market crisis and the next novel attack.
That confidence is what our security work is for. It is not a compliance exercise or something we do in parallel to the product. It is the product. We put exceptional thought and rigor into our security posture because the people who rely on us deserve nothing less. And as the past month has shown, the difference between a protocol that stays live and one that doesn’t is often the result of the quality of decisions made months or years earlier.
Our security posture rests on five principles:
**Defense in depth. **No single control is sufficient. Every layer assumes the next will fail.
**Bound the blast radius. **Even a fully compromised component should not produce catastrophic loss.
Operational security is product security. **How we sign, monitor, and authorize is engineered with the same rigor as the contracts themselves.
**Onchain security begins offchain. **The attack surface extends through every vendor, library, and tool we touch.
**Paranoia is a practice. **The work is never done.
The rest of this post walks through recent incidents in our industry, each illustrating one of our security principles and why the same class of attack would not produce the same outcome in our systems. We then close with our last principle and what we’re working on next.
No single control is sufficient. Every layer assumes the next will fail.
On April 19, an attacker drained roughly $293 million from Kelp DAO, surpassing Drift to become the largest DeFi exploit of 2026 to date, by compromising the verification layer of a LayerZero bridge. The attacker drained approximately 116,500 rsETH (roughly $293 million) by targeting Kelp's bridge built on LayerZero. According to LayerZero's post-incident analysis, the attack did not exploit the LayerZero protocol, the DVN software, or key management. Instead, attackers compromised RPC nodes that the LayerZero Labs DVN relied upon to read chain state. They identified the relevant RPCs, swapped out the binaries on two of them, and launched DDoS attacks against the remaining clean nodes to force a failover to the poisoned ones. The malicious nodes were configured to show falsified data only to the DVN while continuing to report accurate data to other observers, engineered to evade LayerZero's own monitoring, which queried the same RPCs from different IP addresses.
This was a sophisticated, well-resourced operation. LayerZero attributed it with preliminary confidence to North Korea's Lazarus Group, specifically the TraderTraitor subunit. But the attack was only possible because of the configuration of the verification layer.
Kelp's OApp ran a 1-of-1 DVN configuration: a single verifier. Reporting indicates that roughly 40% of LayerZero protocols run the same configuration. That common configuration has an unambiguous technical consequence: a single verifier means a single point of failure. With one DVN, compromising the verifier's view of chain state is sufficient to forge a valid cross-chain message. With a properly diversified configuration requiring consensus across multiple independent DVNs, the same attack would have needed to compromise the RPC infrastructure of every DVN in the quorum simultaneously, a dramatically higher bar.
The aftermath was severe. Dozens of protocols froze their LayerZero OFT bridges out of caution, including USDT0, Ethena, ether.fi, Tron DAO, and Curve Finance. Aave saw roughly $8 billion exit as users feared bad debt from rsETH collateral going unbacked, contributing to a roughly 7% drop in DeFi TVL (about $10 billion) over 24 hours.
Ondo's USDY and Global Markets bridges did not pause. Here is why.
When we integrated with LayerZero, we made a deliberate decision: the security configuration was our responsibility, not the protocol's. LayerZero is such powerful infrastructure precisely because it doesn't prescribe a single security posture: it lets each issuer define its own DVN set, quorum thresholds, and confirmation depths. That flexibility is a feature. But it means the application layer must exercise scrutiny over the configuration.
We built five independent layers, each assuming the previous might fail:
**DVN diversity as a hard requirement. **Before integrating, we performed deep due diligence on LayerZero's DVN design space. Our conclusion was unambiguous: DVN diversity is non-negotiable. We require at least three DVNs to reach consensus before any cross-chain message is accepted, and we require each of those DVNs to have a different codebase and unique infrastructure. The latter is a supply chain mitigation: if multiple DVNs share an underlying software stack, a single zero-day could compromise all of them at once. Codebase diversity also protects against silent bugs in any individual DVN, not just deliberate compromise. LayerZero has confirmed that all OFT-standard tokens and applications running multi-DVN setups were unaffected by the Kelp incident.
**RPC-level diligence. **We didn't stop at DVN selection. The Kelp attack ultimately succeeded at the RPC layer, beneath the DVN. For each DVN in our configuration, we mapped out which RPC providers it relies on and the quorum it needs to reach consensus. We considered the question: if a sophisticated attacker targeted the RPC layer specifically, what is the minimum number of nodes they would need to compromise to forge a valid message past our DVN set as a whole? Answering that required going beyond documentation and engaging directly with DVN operators about their infrastructure. We did that work as part of our proactive threat modeling from the beginning, not in response to the Kelp incident.
**Confirmation thresholds. **We also thought carefully about block confirmation depths: how many blocks a DVN must wait before attesting to a message. This is an under-discussed dimension of bridge security. Short confirmation windows can be exploited through chain reorganizations or timing attacks under adversarial conditions. We modeled what depth is required to make reorganization-based attacks economically infeasible, and configured accordingly.
**Our own DVN, designed to “fail closed”. **One of the DVNs in our verification set is built from the ground up and operated by Ondo. We made that investment for a specific reason: we wanted at least one verifier whose failure modes we control end-to-end. In addition to proprietary checks, our DVN reads chain state through multiple independent RPC providers and requires unanimous agreement among them before attesting to any cross-chain message. If even one RPC disagrees, is unreachable, or returns inconsistent results, our DVN refuses to attest. It does not fall back to whichever providers are still responding. Failover, while convenient, is exactly the property the Kelp attackers weaponized when they DDoS'd the LayerZero Labs DVN's clean RPC nodes. A unanimous RPC quorum that fails closed cannot be coerced this way. A poisoned RPC disagrees with the honest ones and breaks unanimity, so no attestation is produced. A DDoS attack against honest RPCs causes the DVN to halt rather than silently route around the failure. Halting is recoverable. The alternative is not.
**Smart-contract-level rate limiting. **Even with all of the above, we operate on one foundational assumption: any component can fail. Vendors can be compromised. DVNs can be corrupted. Sophisticated attackers will find paths we haven't modeled. So we added a final layer: smart-contract-level rate limits on all bridging activity.
Each bridge pathway has limits customized to a comprehensive risk evaluation, large enough to support normal institutional flow, and small enough that even in the worst case (every DVN simultaneously compromised, every operational control bypassed, the verification layer producing forged messages without limit), the maximum loss in any window is bounded at the smart contract level. The blast radius is finite, known, and small relative to the size of the protocols that have been catastrophically drained this month. Outbound rate limits primarily serve as a UX optimization, but also act as an additional circuit breaker in unexpected scenarios.
Each layer assumes the previous one might fail. When the Kelp incident unfolded and teams across the industry scrambled to assess their exposure, we already knew our answer. We had modeled the worst case, bounded it, and stayed live.
Even a fully compromised component should not produce catastrophic loss.
On March 22, an attacker compromised an offchain key at Resolv Labs and used it to deposit roughly $100,000 in USDC into Resolv's USR stablecoin contract. The contract minted them approximately 80 million USR in return, a 500-to-1 ratio of issuance to collateral. The attacker extracted around $25 million before Resolv could pause, and USR briefly de-pegged to roughly $0.025.
The minting contract had no oracle check, no maximum mint limit, and no rate limit. It trusted whatever the privileged key authorized. Resolv had been audited 18 times and the contracts behaved exactly as written. The architecture itself was the vulnerability.
Ondo Global Markets is built so that this class of attack cannot produce a Resolv-scale loss, even in the worst case where a privileged key is fully compromised:
**Mint and redeem rate limits enforced at multiple levels. **Both mint and redeem flows are governed by rate limits enforced at the smart contract level, with limits set at multiple granularities.
**Oracle checks on mint and redeem prices. **Every mint and redeem is validated against a secondary onchain oracle system that approximates the price of the Global Markets tokens. A request that does not correspond to a sensible asset price is rejected onchain.
This kind of oracle-bounded design isn't new for us. Years ago, when designing Flux Finance, we enforced that the OUSG collateral oracle could only move proportionally with the short-term Treasury bill ETF SHV provided by Chainlink. The collateral could not move significantly in price if the underlying asset hadn't.
The architectural lesson from Resolv is the same lesson we apply across the stack: privileged offchain keys are a real and unavoidable part of how tokenized real-world assets work, but the smart contract must refuse to honor anything those keys try to do that doesn't make sense.
How we sign, monitor, and authorize with the same rigor as engineering the contracts themselves.
On April 1, attackers drained approximately $285 million from Drift Protocol on Solana through a months-long social engineering campaign that culminated in a 12-minute, $285 million drain. Kelp was the month's most technically complex incident, but the April 1 Drift attack revealed something equally important: operational security at the asset issuer level matters as much as protocol-level design.
The Drift vulnerability was not a smart contract bug. According to Drift's incident update, attackers (attributed with medium-high confidence to UNC4736, a North Korean state-affiliated group also tracked as AppleJeus or Citrine Sleet) spent six months posing as a quantitative trading firm, building relationships with Drift contributors at industry conferences, depositing over $1 million of their own capital, and onboarding an Ecosystem Vault to establish a credible operational presence inside the Drift ecosystem. They then used Solana's "durable nonces" feature to get Drift Security Council members to unknowingly pre-sign transactions weeks in advance — transactions that, when executed, transferred admin control to the attacker. At 16:05 UTC on April 1, the first pre-signed transaction submitted a proposal to transfer admin control. One second later, the second transaction approved and executed it. What followed was a roughly 12-minute drain of approximately $285 million.
The aftermath exposed a stark contrast in how asset issuers responded. Onchain investigator ZachXBT publicly criticized Circle for the fact that large amounts of stolen USDC were bridged from Solana to Ethereum via CCTP during U.S. business hours without being frozen.
Ondo's response was different. We were alerted to the incident quickly and took immediate, targeted action. We paused USDY where appropriate, and to our knowledge were the only RWA issuer to freeze assets in the attacker's address.
Two distinct things made that possible: the capability to freeze, and the operational readiness to use it quickly.
On capability: USDY is an asset designed for institutional use, and it includes administrative controls that allow us to blocklist addresses and freeze assets in clear cases of theft. That is a deliberate design decision. We believe issuers of tokenized real-world assets have a responsibility to be able to act when funds are demonstrably stolen, and we built USDY accordingly.
What we do to manage risk:
**Active monitoring and rapid response. **We maintain continuous monitoring of onchain activity related to our assets, with the operational infrastructure to assess and act quickly when something goes wrong.
**Dedicated signing infrastructure. **When we need to invoke administrative controls, we sign from purpose-built, isolated, hardened infrastructure — not general-purpose workstations. This matters for two reasons. First, it shrinks the attack surface for the kind of social engineering and supply chain attacks that have felled other protocols: the Drift attackers reportedly compromised contributor devices through malicious code repositories and a beta-testing wallet app delivered via Apple's TestFlight, which is precisely the threat model dedicated signing environments are built for. Second, it means our administrative actions, including emergency response actions like freezes, happen through hardened, well-rehearsed paths, not improvised ones under pressure.
**Clear signing and custom tooling. **Ondo believes clear signing is a critical risk control, and we prioritize infrastructure decisions and custom tooling to enable it. Every signer operates under a mandate not to sign critical transactions whose contents they cannot fully read, parse, and verify in human-legible form. If multiple layers of defenses fail, clear signing is the fallback.
**Timelocks on administrative actions. **Mandatory onchain delay windows between admin operations and execution are not bureaucratic friction. They are a critical line of defense. The Drift incident is a clear illustration: a zero-timelock Security Council migration eliminated the protocol's last line of defense, converting what could have been a queued, visible, pre-execution-detectable change into a near-instant cash-out. Timelocks apply to non-emergency admin actions; targeted emergency actions like freezing a specific address have separate, faster paths so we can respond to active threats in real time.
Being the only issuer to freeze attacker funds is not a marketing claim. It is evidence that our operational stack is meaningfully differentiated from the industry norm — and it is why our customers should expect that when an attack hits a counterparty they are exposed to, we will already be acting on their behalf.
We've described what we've built and why. We want to be equally honest about what we haven't.
Our response to Drift, while fast enough to freeze the stolen funds, was not as fast as it should have been. Detection latency translates directly into either prevention or loss, and the gap between "incident occurred" and "we noticed" was longer than we want it to be in the future. The monitoring investments described below are aimed at closing that gap.
Our threat model treats every component as fallible, but we are aware that there are classes of attack we may not have fully anticipated. We can model what we know about; the harder problem is staying alert to attack surfaces that don't yet have a name.
We have made deliberate trade-offs. Our security posture trades availability for security in several specific, visible ways: our DVN quorum requirement of at least three DVNs across all pathways, our DVN's requirement for unanimous agreement across multiple RPC providers, and our conservative block confirmation thresholds all introduce points where the system can halt or slow down under conditions that a more availability-oriented design would route around. A bridge transaction that takes longer than our users would prefer, or a temporary halt when any component disagrees with the others, is a real cost. Our administrative controls — including the freeze capability that let us act on Drift — represent a degree of centralization that is appropriate for tokenized real-world assets but would be inappropriate for many other kinds of crypto protocols. We believe these trade-offs are right for what we build. We acknowledge they are trade-offs.
Finally: we are saying these things publicly because we think the alternative — implying that everything is handled — is not credible and not useful. Security work is iterative. April 2026 has surfaced new attack patterns that will keep surfacing. We expect to write more on this as the threat landscape evolves.
The threat environment is not getting easier. State-sponsored actors with the resources of the Lazarus Group are now routinely targeting DeFi infrastructure. North Korea was responsible for roughly $2 billion in stolen crypto in 2025 — equivalent to about 60% of all digital asset funds stolen globally. That trend is not reversing.
We are responding with action:
**Real-time monitoring expansion. **We are substantially expanding our onchain and offchain monitoring systems, with real-time alerting that pages our security team the moment anomalous activity is detected. The Drift incident showed us that detection latency, even for a team that responded faster than most, directly translates into either prevention or a multi-million-dollar loss. We are investing to compress that latency further.
**Bug bounty expansion. **We are substantially increasing the scope and reward levels of our bug bounty program, and details will be published shortly. We want the best security researchers in the world finding our vulnerabilities before attackers do.
**Security engineering team expansion. **We are actively expanding our dedicated security engineering roles, including adversarial engineering positions focused on threat modeling, red-teaming, and building the next generation of defensive infrastructure for tokenized real-world assets.
**Reviewing every assumption in light of this spring. **We are conducting a comprehensive review across every Ondo product — bridge configurations, minting and redemption controls, oracle designs, administrative key infrastructure, signing procedures, monitoring coverage, and vendor dependencies — in light of the new attack patterns that have emerged this month. Nothing is exempt from reexamination.
**Security-first design for Ondo Perps. **As we build toward Ondo Perps, we are treating security and risk architecture as a launch prerequisite, not a post-launch iteration. We will share more specifics as the platform continues to be rolled out.
Ondo stayed intact through these incidents because of design decisions made well before any of them occurred. Security confidence, when it is real, is not arrogance. It is the product of having explicitly asked: what is the worst case, and have we bounded it?
That question does not have a permanent answer. The worst case keeps getting worse, and the assumptions that held yesterday will be tested again tomorrow. Some of them will fail. The only honest posture is to keep asking the question, updating the answer, and investing in the work.
The reason we do this is not abstract. Our clients trust us with their money. The difference between a protocol that is still whole after a month like this and one that is not is the result of security, engineering, and operational decisions made months or years earlier. Everything above — the bridge architecture, the rate limits, the signing infrastructure, the vendor scrutiny — exists because that trust has to be earned in code and in process.
The work is never finished. We are committed to doing it, relentlessly and with the seriousness that our clients deserve. Onward.
If you want to help secure the next generation of onchain finance, we'd like to hear from you.
TheStreet Crypto, "Major DeFi hack becomes the largest of 2026 yet," April 19, 2026. https://www.thestreet.com/crypto/markets/major-defi-hack-becomes-the-largest-of-2026-yet
Fortune, "Latest crypto hack sees thieves make off with $280 million from Solana DeFi platform Drift," April 2, 2026. https://fortune.com/2026/04/02/latest-crypto-hack-sees-thieves-make-off-with-280-million-from-solana-defi-platform-drift/
Chainalysis, "Drift Protocol Hack: How Privileged Access Led to a $285M Loss," April 2026. https://www.chainalysis.com/blog/lessons-from-the-drift-hack/
BingX coverage of CoW Swap post-mortem, "CoW Swap Publishes Post-Mortem on Domain Hijack; User Losses Estimated at $1.2 Million," April 2026. https://bingx.com/en/flash-news/post/cow-swap-report-says-cow-fi-domain-hijack-redirected-swap-cow-fi-to-phishing-site-estimated-user-losses-m
CoinDesk, "Popular DeFi platform CoW Swap warns users to stay away from its site after security breach," April 14, 2026. https://www.coindesk.com/tech/2026/04/14/popular-defi-platform-warns-users-to-stay-away-from-its-site-after-security-breach
DL News, "Justin Sun pleads with Kelp DAO hacker after $293m heist," April 2026. https://www.dlnews.com/articles/defi/justin-sun-pleads-with-kelp-dao-hacker-after-usd293m-heist/
The Block, "LayerZero says North Korea's Lazarus likely behind Kelp DAO exploit; blames single-point setup," April 20, 2026. https://www.theblock.co/post/398028/layerzero-kelp-dao-lazarus
CoinDesk, "LayerZero blames Kelp's setup for $290 million exploit, attributes it to North Korea's Lazarus," April 20, 2026. https://www.coindesk.com/tech/2026/04/20/layerzero-blames-kelp-s-setup-for-usd290-million-exploit-attributes-it-to-north-korea-s-lazarus
LayerZero post-incident statement, as quoted in The Block and CoinDesk coverage above (sources 9 and 10).
CoinDesk, "Kelp DAO hits back at LayerZero for trying to shift the blame after a massive exploit," April 20, 2026. https://www.coindesk.com/tech/2026/04/20/kelp-dao-claims-layerzero-s-default-settings-are-what-actually-caused-the-usd290-million-disaster
CoinMarketCap, "$293M Kelp DAO Hack Wipes $8B From Aave's TVL," April 2026. https://coinmarketcap.com/academy/article/dollar293m-kelp-dao-hack-wipes-dollar8b-from-aaves-tvl
CryptoTimes, "Drift Protocol Reveals North Korean State Hackers Behind $285M Exploit," April 6, 2026. https://www.cryptotimes.io/2026/04/06/drift-protocol-reveals-north-korean-state-hackers-behind-285m-exploit/
The Hacker News, "$285 Million Drift Hack Traced to Six-Month DPRK Social Engineering Operation," April 2026. https://thehackernews.com/2026/04/285-million-drift-hack-traced-to-six.html
Chainalysis, as cited in Fortune (source 2) and CoinDesk reporting on DPRK crypto theft, December 2025 / April 2026.
ZachXBT, post on X, April 2026. https://x.com/zachxbt/status/2040055788669165755
CoinDesk, "Resolv stablecoin drops 70% after $80 million exploit after attacker mints USR," March 23, 2026. https://www.coindesk.com/markets/2026/03/23/resolv-stablecoin-drops-70-after-usd80-million-exploit-after-attacker-mints-usr
Hyperbridge, "Update on Recovery Efforts and Next Steps," April 16, 2026. https://blog.hyperbridge.network/recovery-and-next-steps/
Reactions and replies to this article.
2xnmore
@2xnmore
This is the most honest security post-mortem I have read from any protocol this cycle. Most teams publish these after something breaks. ONDO published it while everything held. The detail that stands out: being the ONLY RWA issuer to freeze attacker funds during Drift is not a marketing stat. That is an operational gap across the entire industry, exposed in one incident. The 1-of-1 DVN configuration running across 40% of LayerZero protocols is the kind of systemic risk that does not get discussed until $293 million disappears overnight. Defense in depth means nothing if the architecture assumes nothing will fail. Bounding the blast radius at the smart contract level is what separates a paused protocol from a drained one. The institutions moving serious capital onchain are not looking for the highest yield. They are looking for the team that already asked the worst-case question before the attack happened. This is what that looks like in writing.