Bonzo Lend Oracle Exploit

On 2026-07-11, an attacker drained roughly $9.05M from Bonzo Finance's money-market, Bonzo Lend — which Bonzo describes as Hedera's largest lending protocol — using a 250-token collateral deposit worth a few dollars. Nothing in Bonzo's own code broke. The attacker forged a price by submitting an all-zeros signature to a third-party Oracle whose verifier never checked whether the signature was real. The math the verifier asked for was answered correctly; the question was wrong.

This follows a recurring pattern: an audited, correctly-functioning protocol fully drained because it trusted an external component that wasn't. The failure was one missing input-validation check in a BLS Signature (Boneh–Lynn–Shacham) verifier.

Summary

Date: 2026-07-11, ~00:51 UTC (Hedera mainnet).
Protocol: Bonzo Lend, the lending market of Bonzo Finance — an Aave v2 fork adapted to the Hedera Token Service (HTS). Self-described as Hedera's largest Decentralized Finance (DeFi) lender by Total Value Locked (TVL).
Root cause: Supra's on-chain Pull Oracle verifier accepted a price update whose BLS Signature was the point at infinity ([0,0]) against a committee public key that was also the point at infinity. The Bilinear Pairing check is trivially satisfied by identity inputs, so it returned true. The verifier had no Subgroup Check or non-identity rejection, so it read that true as a valid committee signature.
Manipulation: A forged SAUCE/wHBAR price inflated ~12 orders of magnitude turned 250 SAUCE (~a few dollars) into effectively unbounded borrowing power.
Loss: ~6.63M USDC + ~34.52M WHBAR (Wrapped HBAR) — ~$9.05M — to the primary attacker; a second wallet took ~$1M and self-identified as a white-hat.
Fund flow: ~$5.25M bridged from Hedera to Ethereum via LayerZero and swapped to ETH/WBTC within hours.
Blame surface: Bonzo's contracts and Hedera's core network were not compromised. The defect lived entirely in a third-party oracle verifier contract, which Supra later patched.

The Trigger

Bonzo Lend prices collateral through Supra, a Pull Oracle. In a pull model, price reports are not pushed on a schedule by the oracle operator — anyone can submit a signed report on-chain, and an on-chain verifier decides whether to accept it by checking the signature of the oracle's signing committee. That design moves the entire trust boundary onto one thing: the signature check. If the verifier can be convinced a fake report is signed, the price is whatever the submitter says.

On 2026-07-11 at 00:51:39.646 UTC, attacker account 0.0.10633526 (hashscan) submitted a price update for Supra pair 425 (SAUCE/wHBAR) in transaction 0xd50c55e2...a10a60 (hashscan). The update referenced committee ID 2 and a message hash committeeHash = 0xd4e6b48a...bf3f7f, and in the field meant to hold the committee's BLS Signature it carried the value [0,0] — the elliptic-curve point at infinity. The referenced committee public key also resolved to the point at infinity.

The verifier accepted it. That single acceptance is the whole exploit; everything after is Bonzo's lending logic doing exactly what it was told.

Timeline of Events

All times UTC. Anchored to on-chain consensus timestamps from the Hedera mirror node and Bonzo Finance's incident report.

timeline
    title Bonzo Lend Oracle Exploit (UTC, 2026-07-10 to 07-11)
    Jul 10 22.09 : Attacker account 0.0.10633526 created : Ethereum-side wallet pre-funded (~1 ETH, reported from Tornado Cash)
    Jul 11 00.39.53 : 250 SAUCE deposited as collateral (worth ~a few dollars)
    Jul 11 00.51.39 : Zeroed-signature update accepted for SAUCE/wHBAR (pair 425)
    Jul 11 00.51.47 : 6.63M USDC borrowed against the inflated collateral
    Jul 11 00.51.57 : 34.52M WHBAR borrowed
    Jul 11 01.11-01.36 : Second wallet 0.0.683607 borrows ~$1M on the same price
    Jul 11 01.36 : Legit Supra feed self-corrects SAUCE to ~0.1964 HBAR
    Jul 11 01.41 : Bonzo pauses Bonzo Lend and Bonzo Points
    Jul 11 later : ~$5.25M bridged to Ethereum via LayerZero, swapped to ETH/WBTC

Figure 1: Sequence from wallet setup to fund exfiltration. Eight seconds separated the forged price from the first borrow.

The attacker account was created at 22:09:23 UTC — about 2.7 hours before the exploit — and the Ethereum-side consolidation wallet received its first funds at 22:43 UTC, before any borrowing. This was staged, not opportunistic.

Impact by the Numbers

METRIC	FIGURE	NOTES
Total drained (primary attacker)	~$9.05M	Wallet A
USDC borrowed	6,634,528.20 USDC	(hashscan token)
WHBAR borrowed	34,518,389.36 WHBAR	~$0.07/HBAR reference (hashscan token)
Second wallet (white-hat)	~$1M	Excluded from the $9.05M headline
Collateral deposited	250 SAUCE	~a few dollars (hashscan token)
Price inflation	~12 orders of magnitude	Raw injected feed integer on the order of 10^30
Bridged to Ethereum	~$5.25M	~2,284 ETH + ~15.58 WBTC (snapshot varies)
Bonzo TVL after	~$3.06M	Down ~77% in 24h
Hedera network TVL	Down ~40% (24h)	To ~$25.7M; window/denominator varies by tracker
HBAR price reaction	Slipped to ~$0.069	Down on the day; exact delta varies by source
Time from forged price to first borrow	~8 seconds	—

The USDC and WHBAR borrow amounts are exact to the raw units recorded in Bonzo's report; ETH/WBTC bridged figures are snapshot-dependent and vary by a few percent across trackers.

Key Mechanics

The exploit had three parts — the signature bypass, the price forgery it enabled, and the borrow that turned a forged price into stolen funds. Only the first was a defect; the other two are those components working as designed.

The signature bypass

Supra's committee signs price reports with a BLS Signature — a pairing-based scheme where a valid signature is verified by a Bilinear Pairing equation of the form e(signature, G₂) = e(H(message), pubkey). The pairing e(·,·) is a bilinear map; the equation holds only when the signature genuinely corresponds to the committee's key over that message. That is the normal case.

The point at infinity — call it O — is the identity element of the curve group. Bilinearity forces e(O, X) = 1 for any X, where 1 is the identity of the pairing's target group. So if you submit signature = O and the referenced pubkey = O, both sides of the verification equation collapse to 1, and the equation is satisfied regardless of the message. The check passes without any committee ever signing anything.

Hedera exposes pairing arithmetic through a system precompile at 0.0.8 (hashscan). Supra's verifier built the pairing check from the attacker's inputs, handed it to the precompile, and the precompile returned 1 (true). The precompile was correct: identity inputs really do satisfy the equation. The bug was that the verifier 0.0.4323006 (hashscan) treated a mathematically-true pairing as proof of a committee signature, because it never rejected identity or off-subgroup inputs.

flowchart TD
    A["Attacker submits price update<br/>pair 425, committeeHash 0xd4e6b48a...<br/>signature = [0,0] (point at infinity)"] --> B["Supra verifier 0.0.4323006<br/>requireHashVerified_V2"]
    B -->|"builds pairing check from<br/>identity signature + identity pubkey"| C["Hedera pairing precompile 0.0.8"]
    C -->|"e(O, X) = 1 = e(O, Y)<br/>equation holds → returns true"| B
    B -->|"MISSING: reject identity /<br/>off-subgroup inputs first"| D["Update accepted as<br/>committee-signed"]
    D --> E["Bonzo SupraOracle adapter 0.0.7308480<br/>reads forged SAUCE price"]

Figure 2: identity-element inputs pass through the pairing precompile, and the verifier reads the resulting true as a committee signature.

Rejecting the identity element and performing a Subgroup Check on both the signature and the public key is a standard, well-known requirement of secure BLS verification, precisely because degenerate inputs like this one otherwise validate. Its absence is the proximate root cause.

The price forgery

With submission accepted, the attacker set SAUCE's reported price to a value inflated by roughly twelve orders of magnitude over the real market price of ~0.2 HBAR — the raw feed integer written in was on the order of 10³⁰ (a 1 followed by thirty zeros) before the pair's decimal scaling. The market price of SAUCE never moved and no SAUCE changed hands — there was no Automated Market Maker (AMM) to manipulate and no Flash Loan in the sequence. The attacker manufactured a number inside the oracle, not a trade in the market.

The borrow

Bonzo Lend is an Aave v2 fork. Borrowing capacity is a function of collateral value times each asset's loan-to-value ratio, and a position is only liquidated when its health factor drops below threshold. Bonzo's SupraOracle.sol adapter 0.0.7308480 (hashscan) read the forged price and fed it to the LendingPool 0.0.7308459 (hashscan), which valued 250 SAUCE at an astronomical figure. Even a conservative LTV against a collateral valued in the trillions exceeds every pool's entire liquidity, so the attacker simply borrowed all of it — 6.63M USDC and 34.52M WHBAR — while the position still reported as massively over-collateralized. No liquidation fired and nothing reverted.

Bonzo's report is unambiguous on this: "At no point did Bonzo Lend's contracts malfunction, deviate from their logic, or process anything incorrectly." That is the crux: correct code fed a forged input executed correctly, with a catastrophic result.

Key Actors

ACTOR	ROLE	IDENTIFIER
Attacker (Wallet A)	Executed the exploit and exfiltration	Hedera `0.0.10633526` (hashscan) / EVM `0x9a496615...d6a494` (etherscan)
Wallet B	Borrowed ~$1M on the same forged price; claimed white-hat status via Discord	Hedera `0.0.683607` (hashscan)
Bonzo Finance	Victim protocol; paused Lend + Points	LendingPool `0.0.7308459` (hashscan)
Supra	Oracle provider; owner of the flawed verifier	Verifier `0.0.4323006` (hashscan), pull oracle `0.0.4323024` (hashscan)
Hedera	Underlying network; pairing precompile behaved correctly	System contract `0.0.8` (hashscan)
Ethereum consolidation wallet	Received bridged proceeds	`0xaf20D792...6dD93e` (etherscan)

The Hedera-side attacker key and the Ethereum consolidation wallet are provably linked: at 01:08:47 UTC the attacker EVM address 0x9a496615...d6a494 sent 37.0053 ETH to 0xaf20D792...6dD93e in tx 0x5f80d203...eaf058 (tx). Note that 0xaf20D792...6dD93e also received numerous dust transfers from lookalike addresses sharing the attacker's 0x9a49…a494 leading and trailing characters — these are address-poisoning spam, not attacker-controlled.

Root Causes

One missing check was the bug; several structural choices turned it into a $9.05M loss.

Missing input validation in a BLS verifier: no rejection of the identity element, no subgroup check. This is the direct defect — the only one of the three that was a code bug.
Permissionless pull-oracle submission: because anyone can submit a signed report, the verifier is the sole gatekeeper. A pull design concentrates all trust into the signature check, which raises the cost of that check being wrong to everything.
No consumer-side sanity bounds: Bonzo consumed a single oracle price with no deviation cap or circuit breaker (see Oracles for standard consumer-side defenses). A collateral price jumping twelve orders of magnitude in one block has no market basis, and a deviation bound would reject it regardless of signature validity.
Thin-liquidity collateral: SAUCE is a low-liquidity asset accepted as collateral. Manipulation leverage scales inversely with how hard the asset is to move — and here the asset didn't even need to be moved.
Trust was relocated, not eliminated: Bonzo's contracts were audited and correct, but that protected nothing, because the trust had been moved to an external verifier outside that audit scope. Enumerating every external dependency and its failure modes is the defense that contract-scoped audits miss.

Aftermath

Bonzo Lend's TVL fell ~77% to roughly $3.06M within 24 hours as users exited; Hedera's network-wide DeFi TVL dropped by a reported ~40% (to roughly $25.7M), and HBAR slipped to around $0.069. Bonzo paused Bonzo Lend and the Bonzo Points program; its Vaults, Bridge, and BONZO/xBONZO staking products were unaffected and stayed live.

Supra acknowledged the vulnerability, characterized it as a degenerate BLS signature paired with a zero-valued public key accepted for the single SAUCE/wHBAR feed, and deployed a fix to the verifier on Hedera mainnet. Bonzo could only describe the mechanism in detail after the patch let them inspect the corrected contract. Hedera publicly stated the incident was confined to a third-party oracle verifier and did not involve its core network.

The primary attacker's funds were bridged to Ethereum via LayerZero — roughly $5.25M — and swapped into ETH and WBTC, then dispersed. Those funds were not recovered. Wallet B's ~$1M was the subject of a separate white-hat return negotiation via Discord. As of mid-July 2026, Bonzo had not published a reimbursement plan, reopening date, or withdrawal terms for the paused pool. The incident landed inside a bad stretch for DeFi — roughly $28–35M lost across Bonzo, BonkDAO, and Summer.fi in the same week — and was widely framed as a case study in cross-chain oracle-verifier risk.

Lessons

A correct precompile is not a correct verifier. Cryptographic building blocks answer exactly the question posed. Returning true for identity inputs is correct math; the application must reject degenerate inputs before it trusts the result. Non-identity and subgroup checks are a required part of BLS verification, not optional hardening.
Bound your oracle at the consumer. A valid signature only proves who signed — not that the number is sane. A lending market can cap per-update price deviation and reject implausible jumps regardless of who signed them, so the protocol survives a compromised oracle rather than only a healthy one.
An audit covers the code inside its scope, not the system around it. Bonzo's audited contracts worked perfectly and still lost $9.05M. Audit scope that stops at your own contract boundary leaves the largest trust assumption — the external oracle — untested.
Pull oracles move the trust boundary onto the verifier. Permissionless submission is convenient and gas-efficient, but it makes the verifier the only thing standing between an attacker and an arbitrary price — so that verifier carries the protocol's entire trust assumption and must be validated accordingly.
Thin collateral is dangerous even with an honest oracle. Accepting low-liquidity assets as collateral compounds every other failure. Here it didn't even require a market trade — a negligible collateral outlay was enough once the price was forged.

References

Changelog

DATE	AUTHOR	NOTES
2026-07-15	Artificial.	Generated by robots. Gas: 120 tok
2026-07-15	Denizen.	Reviewed, edited, and curated by humans.