Composability Attack Deep Dive: How an Attacker Stole $128k Without an Exploit

On April 24, 2025, Blockaid’s real-time exploit detection systems flagged suspicious activity involving the Zora claim contract and the 0x Settler contract.

Initial indicators suggested an active exploit: unexpected value movement, attacker-controlled addresses, and non-standard contract calls.

However, technical analysis quickly confirmed otherwise. No contracts were compromised, neither ZORA’s nor 0x's.

Zora’s airdrop process assigned $ZORA tokens to 0x Settler, a permissionless contract designed to execute arbitrary transactions. The attacker used this behavior to claim the allocation and swap it for ETH, extracting $128,000 in assets.

This case underscores a fundamental reality of the onchain world: in a fully permissionless environment, failure to anticipate composable behaviors can be just as costly as traditional exploits.

In fact, this is a new class of onchain risk, a Composability Attack. In this attack type, independent, secure components combine in unexpected ways to create exploitable conditions.

Blockaid’s early detection of the incident ensured immediate visibility into the event, reinforcing the critical role proactive security infrastructure plays in safeguarding the onchain ecosystem.

Understanding Composability Attacks

A Composability Attack occurs when two or more independently secure systems interact in an unexpected way that creates an exploitable condition, without requiring any vulnerabilities in the systems themselves.

Unlike traditional exploits, which target bugs or permission errors in contract code, a Composability Attack exploits the emergent behavior of permissionless, composable smart contract systems.

In this incident, all contracts involved behaved exactly as intended. The attack that took place was only made possible because of how these systems interacted in relation to one another.

In permissionless environments, composability risks are just as real and just as dangerous as traditional code-level vulnerabilities.

Blockaid’s detection surfaced this attack path in real time, demonstrating yet again the advantages of real-time monitoring over static analysis and contract audits, as it enables teams to monitor not just contracts, but how these contracts compose across different onchain interactions.

Technical analysis

This incident stems from an unexpected interaction between two components: Zora’s airdrop claim mechanism and the 0x Settler contract.

Understanding how each system works independently and how their combination created an attack path is key to understanding the event.

Zora’s claim mechanism

Zora’s airdrop system allowed eligible addresses to claim $ZORA tokens using a claim contract.

Through the claim(address _claimTo) function, recipients could trigger a transfer of their allocated tokens to any specified destination.

A critical point is that this design made no distinction between externally owned accounts (EOAs) and smart contracts. If an address was listed as eligible, it could claim tokens, whether it was a user-controlled wallet or a deployed contract.

Importantly, this was not a design flaw.

As Zora’s tyson explained, many eligible users rely on smart wallets, DAOs, and multisigs, all implemented as smart contracts. Filtering out contract addresses would have excluded a significant portion of real users.

0x Settler contract design

One of these smart contracts was the 0x Settler.

The 0x Settler contract is the core execution layer of 0x. It’s a contract that dynamically updates based on the latest deployments, and it allows 0x users to handle swaps without requiring passive token allowances.

However, the Settler itself is permissionless in who can call it. Anyone can send calldata to the Settler’s execute entry point, instructing it to forward an arbitrary call to a specified target contract.

Critically:

• Settler does not enforce strict ownership checks.
• It forwards calldata exactly as provided, without additional validation.

While this design enables flexible decentralized swaps, it also means that if the Settler itself is the recipient of assets, like an airdrop, anyone can trigger interactions on its behalf.

This concept is explicitly mentioned in 0x’s documentation about Settler:

How the components combined to create an attack path

Given the mechanics of both systems, the allocation of tokens to the 0x Settler contract created an unexpected vulnerability.

Although Zora intended to allocate tokens to the 0x ecosystem, they mistakenly assigned them to a permissionless contract (the 0x Settler) where anyone could initiate actions on its behalf.

This oversight allowed anyone who understood the interaction to claim the tokens originally meant for 0x.

Technically, the exploit path was simple:

• Call execute() on the Settler.
• Instruct it to invoke Zora’s claim() function.
• Redirect the allocated tokens to their own wallet (using address _claimTo).

Again, each system individually behaved exactly as intended. The failure came from the emergent behavior between two permissionless components, a Composability Attack, representing a vulnerability born entirely from the way the two systems interacted.

How the exploit happened in practice

On April 24, 2025, the attacker executed the following sequence:

Step 1: Fund an Address - The attacker funded a newly created address on Base with enough ETH to cover transaction fees.

View funding transaction →

Step 2: Construct a Malicious execute() Call - They built calldata instructing the Settler to call the Zora claim contract’s claim(attacker_address) function.

Step 3: Trigger the Call via Settler - By invoking execute(), the attacker forwarded the malicious calldata to Zora’s contract. Because the Settler was the eligible recipient, the claim succeeded, transferring 5,500,777 ZORA tokens.

View exploit transaction →

Step 4: Swap and Bridge the Proceeds - The attacker immediately swapped the stolen $ZORA tokens for ETH and bridged the funds off Base via the Across Protocol.

View bridge transaction →

Full Incident Timeline

Lessons Learned and Takeaways

The Zora / 0x incident highlights a critical truth about building in permissionless environments: Security does not end at contract audits. It extends to every assumption made about how systems interact.

Several key lessons emerge from this event:

Allocation processes should verify recipient behavior

It is not enough to check if an address is valid. Protocols should verify that airdrop recipients are capable of securely holding and managing allocations, especially when smart contracts are involved.

Composability introduces invisible attack surfaces

Each contract independently behaved correctly. It was their interaction, Zora’s open eligibility plus Settler’s arbitrary execution, that created an exploitable pathway that allowed a composability attack.

This type of attack must be part of the threat model, and teams must proactively account for how third-party contracts could behave in adversarial scenarios.

Real-time monitoring is essential

Even without traditional vulnerabilities, emergent threats can move value rapidly across chains. Blockaid’s real-time exploit detection provided immediate visibility, enabling protocols and ecosystems to assess and respond before further damage could occur.

Conclusion

Ultimately, this incident underscores a key reality of onchain security: In permissionless systems, mistakes in assumptions can be as dangerous as technical vulnerabilities.

The attacker did not compromise smart contracts; they compromised the expectation that an address would behave safely, without verifying what permissions and behaviors it exposed.

This incident also highlights the power of real-time detection - the Blockaid Platform surfaced the anomaly within seconds, providing immediate clarity at a moment when traditional defenses would have seen nothing wrong.

It’s rapid detection and response tools like this that make it possible to understand, contain, and respond to incidents like this and stop them before further losses occur.