Breakpoint 2025: Security Block: Asymmetric Research

A $160 million vulnerability. A signature verification bypass that could have drained an entire cross-chain bridge. These aren't hypothetical scenarios—they're real security flaws discovered by Asymmetric Research in production Solana programs over the past year. At Breakpoint 2025, Felix Wilhelm, co-founder and CTO of the web3 security firm, delivered a sobering assessment of Solana program security, revealing both promising improvements and alarming patterns that continue to put billions of dollars at risk.

Summary

Felix Wilhelm's presentation at Breakpoint 2025 offered a comprehensive look at the state of Solana security, highlighting both positive maturation and persistent challenges that threaten the ecosystem's stability. As Solana has grown into one of the most active blockchain networks, the security landscape has evolved—but not always in the right direction.

The talk centered on four major themes: the ongoing struggle of new developers navigating Solana's complex security requirements, the dangerous erosion of institutional knowledge as projects age, the concerning tradeoffs being made in the name of compute unit optimization, and the underappreciated risks posed by oracle compromises. Each of these areas represents a potential vector for catastrophic losses, and Wilhelm illustrated each with real-world examples from his firm's security research.

What makes Wilhelm's analysis particularly valuable is its grounding in actual vulnerabilities discovered in production systems. The examples cited—including critical bugs in Relay Link and Marginfi—demonstrate that even well-funded, audited projects can harbor devastating security flaws. The message is clear: security on Solana requires constant vigilance, improved tooling, and a fundamental shift in how developers approach defensive coding practices.

Key Points

New Developer Onboarding Challenges

The influx of new development teams to Solana throughout 2024 has created a significant security gap. While experienced Solana developers have deep knowledge of the runtime's quirks and potential pitfalls, newcomers—especially those migrating from the EVM ecosystem—repeatedly fall into the same traps that have existed for three to four years.

Wilhelm identified several particularly problematic areas. Instruction introspection, which involves reasoning about what happened in a transaction before or after your program executes, remains extremely difficult to implement correctly, especially when combined with Cross-Program Invocation (CPI). The SECP and ED25519 native programs for signature verification are another minefield—while powerful, they're remarkably easy to misuse in ways that create critical vulnerabilities.

The Relay Link vulnerability serves as a stark example. This intent-based cross-chain bridge attempted to use ED25519 signature verification to protect fund withdrawals, but the implementation didn't properly parse the instruction format. Instead, it extracted the signer key and messages from hard-coded offsets—a fundamentally broken approach that allowed attackers to completely bypass signature verification and potentially steal all funds in the protocol.

The Update Safety Crisis

As Solana matures, a new category of risk has emerged: the danger of making changes to battle-tested code. Wilhelm outlined a familiar pattern where core development teams design, build, and audit a protocol, launching with deep understanding of all security-critical invariants. Success follows, the protocol runs for months or years, and then developers move on to new projects, retire, or get promoted out of hands-on coding roles.

When the time comes for a "small bug fix" or minor feature addition, the institutional knowledge that made the original code secure may have evaporated. New developers—even highly skilled ones—may not understand subtle invariants that affect seemingly unrelated parts of the codebase. Auditors reviewing incremental changes likely aren't familiar with the full system either.

The Marginfi example is particularly instructive. This mature, heavily-audited lending protocol with $160 million at stake introduced a seemingly simple "transfer to new account" instruction. Reviewed in isolation, it appeared harmless—signatures were correct, logic was straightforward. But it failed to integrate properly with Marginfi's flash loan functionality, creating a path for attackers to take flash loans and simply walk away without repayment.

The CU Golfing Security Tradeoff

The growing interest in compute unit optimization represents both a sign of ecosystem maturity and a concerning security trend. Projects like Pinocchio, P-Token, and Humidify demonstrate that Solana developers are becoming sophisticated enough to squeeze maximum efficiency from the runtime. However, this optimization often comes at the direct expense of security safeguards.

Heavy CU optimization typically involves removing "safety belts" that normally protect against vulnerabilities. Unsafe Rust code eliminates memory safety guarantees. Assembly makes code harder to review and reason about. Ownership checks get removed when developers believe they understand runtime semantics well enough to know they're "unnecessary." Battle-hardened SDK functionality gets reimplemented in faster but less-tested ways.

Wilhelm was direct in his assessment: even the best developers in the space make mistakes. He pointed to pull requests from Pinocchio and P-Token—projects written by elite developers—that contained serious vulnerabilities. One had an integer underflow in unsafe code leading to out-of-bounds writes; another had a missing ownership check that could cause fund loss during batch instruction processing. If projects representing the pinnacle of Solana development expertise can harbor such bugs, average projects should think twice before abandoning their safety rails.

Oracle Risks: The Overlooked Attack Vector

Wilhelm's final major concern targets what may be the ecosystem's most underappreciated risk: oracle compromises. DeFi protocols fundamentally depend on price oracles, yet developers often fail to consider what happens when price feeds are corrupted—whether through compromise, malfunction, or misconfiguration.

Off-chain oracles present particular challenges because their data sources and trustworthiness are often opaque. The recent Moonwell compromise illustrated this risk when an unsupported Chainlink oracle feed quoted highly inflated prices, enabling an attacker to drain over a million dollars from the protocol. While that particular loss was relatively contained, Wilhelm predicted more such attacks as on-chain security improves and attackers seek softer targets.

The recommended defense is mechanism design that assumes oracle failure is possible. Price limits, emergency halt mechanisms, and other defensive measures can contain the blast radius of a corrupted price feed, preventing a single point of failure from completely compromising a protocol.

Facts + Figures

• Asymmetric Research discovered a vulnerability in Marginfi that could have led to $160 million in losses through flash loan exploitation

• The Relay Link cross-chain bridge had a complete signature verification bypass due to hard-coded offsets in instruction parsing

• Moonwell DeFi lost over $1 million due to a malfunctioning Chainlink oracle feed quoting inflated prices

• The same categories of security mistakes have been repeated for three to four years as new developers onboard to Solana

• Even heavily-audited, mature projects like Marginfi can introduce critical vulnerabilities through seemingly minor code changes

• Pinocchio, one of the highest-quality CU-optimized projects in the ecosystem, had a bug involving integer underflow in unsafe code leading to out-of-bounds writes

• P-Token had a vulnerability related to missing ownership checks that could cause fund loss during batch instruction processing

• Asymmetric Research is developing stress testing tools for oracle compromises to help protocols evaluate their exposure

• New Anchor framework updates aim to address pitfalls around duplicated mutable accounts and provide secure signature verification helpers

Top Quotes

"Every time you look at the instruction system and try to reason about what happened in the transaction before or after you, that's really hard to get right, especially once you involve CPI."

"The thing with safety belts is that you don't need them if you don't write bugs. So the argument could be, well, I just write perfect code and then everything is great. But even if you look at the projects that are developed by the best people in the space, you see even the best developers don't always get it right."

"A lot of the stuff we have on chain is really brittle. It's really important to have defense in depth measures to make sure you don't introduce these bugs two years after your launch."

"An attacker is always going to look for the weakest spot. So if your on-chain code is perfect, then maybe your oracle provider is actually the weakest spot in your security story."

"The average developer project should be really careful before deciding to remove these safety belts and drive fast."

"Heavy optimizations and security are kind of at odds with each other. A lot of the CU optimization stuff is basically removing safety belts that you normally have from the memory-safe language that you're writing in."

"We are pretty confident that we are going to see more and more of these kind of attacks or compromises in the future, especially when the on-chain attack surface gets more hard."

Questions Answered

What are the most common security mistakes new Solana developers make?

New developers consistently struggle with instruction introspection—attempting to reason about what happened before or after their program in a transaction. This becomes especially dangerous when combined with Cross-Program Invocation. The SECP and ED25519 native programs for signature verification are another frequent source of critical bugs, as their complexity makes them easy to misuse. Framework-specific issues like duplicated mutable accounts, where modifications can silently disappear, and bump seed canonicalization also trap many newcomers. These same mistakes have been observed for three to four years, suggesting the need for better tooling and documentation.

Why are mature, audited projects still vulnerable to security exploits?

Even heavily-audited projects face significant risk when making updates long after launch. The original developers who understood all security-critical invariants may have left the team or moved to other roles. When new developers—even highly competent ones—make changes to unfamiliar code, they may inadvertently break assumptions that affect other parts of the system. Auditors reviewing incremental changes also likely lack familiarity with the full codebase. The Marginfi vulnerability demonstrated this perfectly: a simple new instruction that seemed harmless in isolation created a critical flaw when it interacted unexpectedly with existing flash loan functionality.

Is compute unit optimization worth the security risks?

While CU optimization demonstrates ecosystem maturity and benefits users through reduced costs, it frequently involves removing critical security safeguards. Unsafe Rust code, assembly, removed ownership checks, and reimplemented SDK functionality all increase vulnerability surface. Wilhelm pointed out that even elite developers working on showcase optimization projects like Pinocchio and P-Token have introduced serious bugs. Projects should carefully weigh whether compute savings justify abandoning battle-tested safety measures, especially given that even the best developers make mistakes.

How serious are oracle risks for DeFi protocols?

Oracle risks are significantly underappreciated and likely to become more prominent attack vectors as on-chain security improves. The Moonwell compromise showed how a single malfunctioning price feed could enable an attacker to drain over a million dollars. Because off-chain oracles often lack transparency about their data sources and security posture, developers may not fully understand their exposure. Protocols should assume oracle failure is possible and implement defensive measures like price limits and emergency halt mechanisms to contain potential damage from corrupted feeds.

What's being done to improve Solana security?

Multiple initiatives are underway to strengthen the ecosystem. The Anchor framework is introducing secure-by-default APIs that make common operations harder to misuse, including safer signature verification helpers. Improved tooling including static analysis and the new Anchor fuzzing capabilities help catch vulnerabilities before deployment. Asymmetric Research is developing oracle compromise stress testing tools so developers can simulate attacks against their mainnet deployments. Security-focused events like their CTF (Capture The Flag) and educational talks on fuzzing and binary decompilation aim to build community knowledge around secure development practices.