Crypto Security

A Valid Signature, a Fake Transaction: How the Ankr Bridge Lost $304,500

Five forged receipts, one tiny Optimism deposit, and $304,500 lost. The Ankr bridge exploit shows why a valid signature doesn't prove an event happened.

On November 9, 2026, an attacker used five withdrawal requests to extract approximately $304,500 from Ankr’s Ethereum cross-chain bridge, according to blockchain security firm SlowMist. All five requests referred to the same small transaction on Optimism. The surprising part was that each forged receipt carried a cryptographically valid signature from the bridge’s trusted signer.

The bridge accepted the signatures and released the assets. Yet the withdrawals did not match the events that had actually occurred on the source chain. The case exposes a distinction that is easy to miss: a valid signature does not, by itself, prove that the statement being signed is true.

SlowMist published its findings on November 9. Read the incident record and the researchers’ original disclosure.

Why a bridge needs proof from another blockchain

A cross-chain bridge moves value between networks that do not automatically share a single record of transactions. Imagine depositing tokens on Optimism and expecting corresponding assets to be released on Ethereum. The contract on Ethereum needs trustworthy evidence that the deposit actually happened.

Depending on the bridge design, that evidence may take the form of a receipt or message approved by a trusted signer or validator system. The receiving contract checks the proof before paying out. But there are two separate questions: Was this message authorized by a recognized signer? And did the event described in the message really happen?

A signature check can answer the first question. It does not necessarily answer the second.

What happened at Ankr

According to SlowMist’s analysis, the attacker submitted five forged cross-chain receipts to Ankr’s Ethereum bridge on November 9. Each referred to the same genuine Optimism transaction, while changing material details such as the recipient, token and withdrawal amount.

Reports examining the underlying transactions identified the original Optimism deposit as approximately 0.0044 ankrETH, from November 3. That deposit had already been redeemed. The later withdrawal requests nevertheless led to payouts of other assets from the Ethereum bridge.

The decisive detail: SlowMist reported that the five forged receipts all had valid signatures from the bridge’s trusted consensus signer. The bridge’s withdraw() path accepted them without independently verifying that the claimed source-chain events matched reality.

The reported losses varied as monitoring progressed: Blockaid’s initial alert estimated roughly $292,000, while SlowMist’s later analysis put the total near $304,500. These are security researchers’ estimates, not a final audited recovery figure.

Infographic showing how one Optimism deposit was used to create five forged bridge receipts with valid signatures, resulting in $304,500 in unauthorized withdrawals.

Why did the signatures pass?

A digital signature authenticates data, not reality

A digital signature binds a specific message to a signing key. If verification succeeds, the verifier can establish that the message was signed using the corresponding private-key authority and has not been altered since it was signed. This is powerful, but its scope is narrow.

Suppose a signed bridge receipt says: “A user deposited 100 tokens on chain A; release 100 tokens on chain B.” Verifying the signature tells the receiving contract that the receipt meets its signer-authentication rule. It does not independently prove that the deposit of 100 tokens occurred.

That second claim requires an additional trust assumption or verification mechanism. If a system treats signer approval as sufficient evidence of the underlying event, the integrity of the signing process becomes part of the bridge’s critical security boundary.

One source transaction, multiple claims

The Ankr case also illustrates the importance of binding a payout to the exact source event it represents. A bridge must distinguish a new, valid claim from an old deposit being repackaged with different fields. A check that only prevents reusing an identical receipt is not necessarily equivalent to preventing repeated payouts for the same source deposit.

Public reporting supports the broader conclusion that the forged receipts were accepted despite referring to the same source transaction. It does not, on its own, establish every implementation detail of the bridge’s replay-protection logic.

Where did the valid signatures come from?

That remains an open question. SlowMist identified valid signatures on unauthorized receipts, but said the origin of those signatures was still under investigation. A compromised signing key is one possibility; a flaw in the off-chain approval process is another. Neither should be presented as a confirmed root cause without further evidence.

This uncertainty matters. “A valid signature was used in an unauthorized withdrawal” is a supported observation. “The signer’s private key was stolen” is a much stronger claim, and the available findings do not establish it.

How can bridges reduce this class of risk?

Different bridge architectures make different trade-offs, but several principles follow from the incident:

Verify the underlying event. Where practical, use independently verifiable source-chain proofs rather than relying solely on the approval of an off-chain signer.
Bind each payout to a unique deposit. The amount, asset, recipient, source chain and source-event identifier must be checked consistently so one event cannot authorize different withdrawals.
Enforce replay resistance at the event level. Mark an underlying source event as consumed, rather than assuming an identical signed message is the only form of duplication.
Treat signers as critical infrastructure. Harden signing services, separate duties, monitor anomalous approvals, and plan for suspension and incident response.

None of these measures is a universal guarantee. Verification proofs add complexity; validator systems have governance and operational risks; and additional signers do little if they share the same compromised verification process.

What should DeFi users take from this?

Using a bridge means depending on more than the transaction you personally submit. Assets may remain exposed to the design and operation of the protocol after your deposit succeeds. Before moving substantial funds, look at how the bridge validates source-chain events, what authority can release funds, whether controls are independently audited, and how failures are handled.

Diversifying exposure across protocols and limiting the amount left in a bridge are risk-management choices, not protections against every exploit. A clean interface or a successful transaction signature cannot tell you, by itself, whether the bridge’s internal verification model is sound.

The real lesson: valid signature ≠ valid event

The Ankr incident was not a failure of signature mathematics. The critical issue, according to the researchers’ published analysis, was the gap between validating the authorization on a receipt and validating the source-chain event the receipt claimed to represent.

Cryptography can prove that a message meets a signature-verification rule. Establishing whether the message describes something that actually happened requires a separate, reliable basis for trust.