The CrossCurve Exploit: How Olympix Would Have Prevented the $1.4M Loss

Date: February 1, 2026
Protocol: CrossCurve (formerly EYWA)
Amount Lost: $1,441,892
Root Cause: Missing access control in cross-chain receiver contract
Chains Affected: Multiple, including Arbitrum (primary), Ethereum, and others

What Is CrossCurve?

CrossCurve is a cross-chain bridge protocol that connects multiple blockchain networks. Its architecture combines Axelar-based receiver contracts with internal PortalV2 bridge contracts. The receiver contracts are responsible for validating inbound cross-chain messages and authorizing the PortalV2 contracts to release funds, but only in response to legitimate transactions. The protocol had previously touted its multi-validation architecture, involving Axelar, LayerZero, and its own EYWA Oracle Network, as a security strength.

On February 1, 2026, that architecture failed. A single missing validation check was all it took.

What Happened

The attacker identified that CrossCurve’s ReceiverAxelar contract contained an expressExecute() function, designed for expedited cross-chain execution, that was publicly callable and lacked any meaningful source validation.

The attack followed a straightforward pattern:

1. Spoofed message origin. The attacker generated a fresh commandId and supplied a fake sourceChain and sourceAddress to make the transaction appear to be a legitimate cross-chain message from Axelar.
2. Crafted a malicious payload. The attacker constructed an ABI-encoded payload instructing the contract to mint or transfer approximately 999.8 million EYWA tokens to their own wallet.
3. Bypassed validation. The contract’s only check was whether the commandId had been used before. Since the attacker supplied a fresh identifier, the check passed. The confirmation threshold was also set to 1, effectively disabling multi-guardian verification.
4. Executed across multiple chains. The contract decoded and executed the attacker-controlled payload, updated internal state to simulate a valid cross-chain receipt, and transferred tokens to the attacker’s wallet. The same process was repeated across multiple networks.

By the time CrossCurve shut down the platform, the PortalV2 contract’s balance had dropped from approximately $3 million to near zero. The attacker converted stolen tokens to WETH via CoW Protocol on Arbitrum and bridged funds to Ethereum via the Across Protocol. While EYWA was also minted on Ethereum, frozen CEX deposits and limited liquidity prevented further liquidation there. Most stolen assets remained in attacker-controlled wallets.

Root Cause Analysis

The vulnerability was straightforward: the expressExecute() function in the ReceiverAxelar contract was missing the check that verifies a message originated from the Axelar Gateway before executing it.

In a properly implemented Axelar integration, the gateway validation check is the primary security boundary. It ensures that only messages authorized by the Axelar network can trigger token releases. CrossCurve’s implementation omitted this check entirely, replacing it with only a commandId uniqueness check, a trivially bypassable control that the attacker exploited with a fresh identifier on every call.

Two compounding factors made the impact worse:

• Public function exposure. expressExecute() had no access control restricting who could call it.
• Disabled quorum verification. The confirmation threshold of 1 removed the multi-guardian check that could have caught the unauthorized execution.

Anyone could call the function, supply arbitrary source chain data, and trick the contract into releasing funds as if a legitimate cross-chain transaction had occurred.

How Proactive Security Would Have Prevented This

The CrossCurve exploit is a textbook example of a vulnerability class that static analysis and continuous security testing are built to catch. This is not a complex, novel attack. It is a missing access control check on a publicly callable function, a finding that appears in smart contract security audits regularly and is well within the detection capabilities of automated tooling.

Static Analysis Would Have Flagged the Missing Gateway Check

Olympix’s static analysis engine scans smart contract code for known vulnerability patterns during development. A missing Axelar gateway validation on an external execution function, where the contract processes arbitrary caller-supplied data without verifying its origin, is exactly the kind of finding our tooling surfaces.

Rather than waiting for a security audit, or a post-exploit investigation, developers would have received a warning the moment the vulnerable code was written. The fix is a one-line change: add the gateway validation check before executing any payload. Finding it at code-writing time costs minutes. Finding it after a $3M exploit costs significantly more.

Mutation Testing Would Have Exposed the Inadequate Validation Logic

The commandId uniqueness check gave a false sense of security. It passed tests, but it was not a meaningful security control. It could be trivially bypassed by supplying a new identifier on every call.

Olympix’s mutation testing tool identifies gaps like this by systematically modifying smart contract logic and checking whether existing tests catch the changes. If no test fails when the gateway validation check is removed or altered, that is a signal that the test suite does not actually verify the security property it needs to verify. Mutation testing makes these blind spots visible before deployment.

Fuzzing Would Have Surfaced the Attack Path

Olympix’s fuzzing tooling generates adversarial inputs automatically and tests whether they can trigger unintended behavior. An expressExecute() function that accepts arbitrary sourceChain, sourceAddress, and ABI-encoded payload inputs is a natural fuzzing target. The attacker's exact technique of supplying crafted inputs to bypass validation would have been discovered in testing.

The Broader Problem: Audits Are Not Enough

CrossCurve is not an outlier. This exploit follows the same pattern as the 2022 Nomad bridge hack and dozens of other cross-chain bridge incidents. Despite significant investment in layered validation architecture, a single implementation flaw in a critical function was sufficient to drain the protocol.

The industry’s default answer to smart contract security is the audit: bring in external reviewers before launch, get a clean report, ship. Audits are point-in-time snapshots. They do not cover code changes made after the audit concludes. They do not run continuously as the codebase evolves. And they are only as good as the reviewer’s attention during a fixed engagement window.

CrossCurve had previously received early support from Curve Finance founder Michael Egorov and positioned its multi-validation architecture as a security differentiator. None of that prevented a publicly callable function from missing a critical validation check.

Shifting security left means integrating security testing into the development process itself, not bolting it on at the end. When vulnerability detection happens at the point of code-writing, the cost of finding and fixing bugs is low. When it happens after an exploit, the cost is measured in millions of dollars, user trust, and in some cases, protocol survival.

Key Takeaways

For developers building cross-chain protocols:

Access control on execution functions is not optional. Any function that processes messages from external sources and triggers fund movements must verify the origin of those messages before executing. The Axelar gateway validation check exists for this reason. Skipping it removes the primary security boundary of the entire integration.

Set confirmation thresholds to values that provide meaningful security. A threshold of 1 defeats the purpose of multi-guardian verification.

For the broader ecosystem:

Architecture complexity does not equal security. A protocol can have multiple validation layers and still be vulnerable if any single layer fails. Security must be verified at the implementation level, not assumed from the design level.

Continuous, automated security testing integrated into development workflows from day one is not a luxury for high-risk code like cross-chain bridges. It is a requirement.