Signed by Nobody: The BLS Identity Exploit That Drained $9M from Bonzo Lend

On July 11, 2026, a threat actor exploited a vulnerability in the BLS Signature verification mechanism of Supra’s Oracle Smart Contract that allowed the attacker to submit a price update and steal ~$9M in real assets.

In this post we are gonna go learn:

• What are oracles and why Bonzo Lend needs them
• What are BLS Signatures and why are they used in web3
• The point at infinity and why Buzz Lightyear has nothing to do with it

Oracles and Why Bonzo Lend Can’t Live Without One

Bonzo Lend is a lending protocol on Hedera. You deposit SAUCE tokens as collateral and it decides how much you can borrow against them, based on SAUCE’s current USD price.

However, smart contracts can’t reach the outside world. There is no built-in HTTP request, no price API you can query directly, no external feed the EVM can pull on its own. The virtual machine is a sealed, deterministic environment. So every lending protocol needs something to push the current price into the contract. That thing is a price oracle.

Now if you are managing one of these oracles, you can’t let just anyone write the price. If you could, anyone would set SAUCE to an astronomical figure, borrow every asset in the pool and walk away. So the oracle needs authentication, the smart contract needs cryptographic proof that the price came from a trusted source and nobody tampered with it in transit.

The standard tool for authentication is a digital signature. Supra runs a committee of off-chain nodes that observe real market prices, sign them, and push signed updates on-chain. Once the pushed updates arrive, the contract verifies the signature before deciding whether or not to update the price.

Based on this we can deduce that whoever controls whether verification passes controls the oracle, and by extension, every lending decision Bonzo makes.

BLS Signatures: The Aggregation Superpower

A committee oracle like Supra is not one signer: it’s N nodes, and you only trust a price if a quorum of them agree. With ordinary ECDSA, you’d need to put N separate signatures on-chain and verify each one. This method is expensive, verbose, and hard to scale as the committee grows. BLS signatures solve this with aggregation.

Each committee node signs the price independently and produces its own signature. What makes BLS special is that those individual signatures can be mathematically folded into one: a single value that represents all of them. The same operation works on the public keys: combine them into one aggregate key. Now the on-chain contract has one signature and one key, and runs exactly one check. The security guarantee is the same as if it had verified every signer individually, as in, the math is constructed so that the combined signature is only valid if all the underlying individual ones were.

BLS relies on a mathematical operation called a pairing, running on a specific elliptic curve: BN254, or alt_bn128 as Ethereum calls it, the same curve behind precompiles 0x06, 0x07, and 0x08.

A pairing is a function e that takes two curve points and produces a value in a third mathematical space. Verifying a BLS signature reduces to one equation:

σ is the signature, P is the public key, m is the message, and H(m) is that message hashed to a curve point. Both sides have to match.

However, pairing computation is expensive, far too expensive for raw EVM bytecode without making every oracle update costly in gas. Precompiles solve that: special contracts at fixed addresses that run native code outside the EVM, making operations like pairing cheap enough to use on-chain. The 0x08 precompile exists specifically for this check, rearranged into a form it can evaluate directly:

Feed it the points, get back TRUE or FALSE. That’s its entire job.

The Point at Infinity (and Beyond!)

Elliptic-curve groups have an identity element: a neutral value you can add to any point without changing it. That element is the point at infinity, written O. It’s the zero of the group.

The point at infinity is the thing you add to a curve point and get exactly that curve point back. So pairing O with any point always returns 1, regardless of what the other input is:

Now watch what happens when an attacker hands the verifier σ = O and P = O and asks it to verify a message of their choosing:

The verification equation $e(\sigma, G2) == e(H(m), P)$ becomes $1 == 1$ (True) for any message, with no secret key, no real signatures, no committee involvement whatsoever.

This is the BLS zero-key / identity-element forgery.

You might ask: the Supra committee’s public keys are registered on-chain, so how did an attacker force the aggregate to zero?

A Supra price update carries the aggregate signature σ and a signer bitmap indicating which committee members signed. The contract reconstructs the aggregate public key by summing the keys of the flagged members:

P_agg = P_signer1 + P_signer2 + ...  (only those flagged in the bitmap)

The Supra incident report adds a specific detail: an out-of-range committee identifier produced zero-valued key material instead of being rejected outright. Through that path, the attacker arrived at P_agg = O and σ = O. The verifier ran e(O, G2) == e(H(price), O), got 1 == 1, which returned TRUE.

Conclusion: $9M Gone

Once the oracle accepted the fabricated price, the rest was history:

• 00:39:53 UTC: the attacker deposits 250 SAUCE into Bonzo Lend as collateral.
• 00:51:39 UTC: they submit the fraudulent price update for SAUCE/wHBAR (pair 425) with a zero signature and a zero aggregate key. The verifier returns TRUE and the contract updates the price. SAUCE is now roughly 12 orders of magnitude above its real value.
• 00:51:47–00:51:57 UTC: at the phantom valuation, 250 SAUCE appears to the protocol as millions in collateral. Bonzo Lend trusts its oracle and allows borrowing against it: ~$9.05M in USDC and WHBAR exits the protocol.
• 01:36 UTC: the legitimate Supra oracle restores the correct price.
• 01:41 UTC: the real assets are gone and Bonzo pauses the protocol.

As of today (2026-07-18), Hedera Foundation has decided to issue a compensation and cover for Bonzo impacted users.

Resources

• Supra Security Incident Report
• Hedera Foundation Compensation Announcement — Bonzo Finance