Two Oracle Failures This Week Came Down to a Signature Nobody Checked. We Shipped That Bug on Our Own Proof of Reserves in May, and Caught It. Here Is How to Check Whether Anyone Is Checking Yours.

Two protocols lost money this week to the same underlying mistake, on two different chains, through two different mechanisms. Neither was a broken smart contract in the usual sense. In both, a system was handed a signed message, treated it as authentic, and acted on the numbers inside it, and in both, the signature was not what it appeared to be. This is a read of what happened and what it teaches, not a victory lap. We are a pre-audit protocol at Genesis scale, we say so everywhere, and as it happens we shipped a version of this exact mistake ourselves in May. So the useful thing here is the shape of the failure and the check that catches it, including the check that catches it on us.

Ostium: an authorized signer is still a single point of total failure

On July 15, 2026, the perpetuals venue Ostium, on Arbitrum, had its public liquidity vault drained inside a roughly five-minute window. As reported by on-chain security firms including PeckShield, Cyvers and Blockaid, the attacker fed the protocol future-dated price reports through an authorized oracle-signer path, so the reports arrived validly signed, then looped open-and-close trades against those fabricated prices in batched transactions, compounding a small starting margin many times over before the team halted trading within about an hour. The signatures were real. The prices were not. The contracts did exactly what they were told, because what they were told arrived correctly signed.

The instructive part is not how the signing path came to be abused, which Ostium has not settled in public and which we are not going to guess at. It is what a single authorized signer is allowed to do when nothing downstream disputes it. One key that can assert a price, with no second source to disagree and no bound on how far a single report can move, is a single point of total failure regardless of who holds it or how carefully. That is a design property, not a moral one, and the lesson holds whether the signer was a stolen key, a compromised machine, or something else Ostium has yet to name. The protocol halted quickly and had published no final loss accounting as of the day after; the point here is the shape of the exposure, not blame for it.

The tell: nobody agrees on how much was lost

Here is the detail that should stay with you. Days after the drain, the reported loss still ranged from about eighteen million dollars, per Blockaid's initial estimate, to roughly twenty-four million, per later on-chain analysis from PeckShield, with Cyvers landing near twenty-three point seven in between. These are competent firms reading the same public chain, and they printed a spread of a third or more, in part because some measured against the whole protocol and some against the specific vault, and few said which base they used. The vault balance itself is a public number on Arbitrum. Anyone can read it and get one answer. When the size of a loss is a matter of whose estimate you happened to see, that is not a data problem, it is a verification problem: the reserve was never something a holder was expected to read for themselves, so a range of secondhand numbers became the record. A dollar you can only learn about by trusting an intermediary is a dollar you are not verifying.

Bonzo: a verifier that ran a check identity inputs silently satisfy

Four days earlier, on July 11, 2026, the Hedera lending market Bonzo was drained of roughly nine million dollars. The fault here was not in Bonzo's own lending contracts, which behaved as designed on a price their oracle vouched for. It was in the verification layer. Per reporting across CoinDesk, The Block and others, and consistent with Bonzo's incident report, the attacker submitted a price update whose cryptographic signature was zero, against a committee key that was also zero. Bonzo's oracle vendor, Supra, ran its signature check, and because the pairing equation used to verify a signature is trivially satisfied when its inputs are the identity element, the check returned true. The verifier did not skip a step. It ran a real check that a maliciously chosen all-zero input silently passes. From there the attacker posted an arbitrary price, deposited a few dollars of one token, and borrowed millions against the fabricated valuation.

The distinction between "the check was skipped" and "the check ran and passed on a degenerate input" is the whole lesson, and it is the failure mode people most often miss, because a green light was showing the entire time. To Bonzo's credit the aftermath moved the right way: the Bonzo Finance Foundation announced it would restore affected pre-exploit user positions with support committed by the Hedera Foundation, with new redemption contracts placed under audit, and Supra deployed a fix. We are not asserting that the underlying class of bug is now provably closed everywhere it lives, only that this instance was patched and this set of users is being made whole.

We shipped this exact mistake in May, on our own reserves

It would be easy to write the paragraphs above and imply we are above them. We are not, and pretending otherwise is the opposite of the point. Our flagship "don't trust, verify" surface is an hourly Proof of Reserves signed by a strategist key and served at /api/por/signed. In late May 2026 we found, and then found again, that this surface had the same disease the two incidents above turned on. Both write-ups are in our public repository; here is the honest version.

On May 28 we caught that the endpoint advertised an integrity flag, signer_matches_expected, that did not actually recover the signature at all. It compared the payload's self-declared "signer" field against the address we expected, as a plain string. No signature was ever recovered from the message. Because the endpoint pulls the signed file from our bot over a plaintext hop, an attacker able to sit on that hop could have served forged solvency numbers, labeled them with our expected signer address, attached a junk signature, and the endpoint would have returned a reassuring, green, signer-matched result over fabricated figures, at precisely the moment, a stress event, when an attacker is most motivated to paint a solvent picture. That is Bonzo's failure in miniature: a check that was being displayed as verification without doing the verifying.

The fix was to recover the signer cryptographically, server-side, from the message hash and signature, and to gate the flag on that recovery. Then on May 29 we caught that the fix was still incomplete: freshness was being measured from an unsigned timestamp field, so a single genuine signature could be replayed forever with every number underneath it rewritten. Closing that meant binding the whole signed preimage, rehashing it and requiring it to match the signed hash, so that every displayed figure and the timestamp are bound to the signature, not merely accompanied by it. We rate that second one High severity. We wrote both down, dated, with the vulnerable code quoted, and we did it about ourselves before anyone asked. That is the same posture as our Honesty Index, which lists Kerne's own advertised-versus-realized yield first, and worst, by design.

The check: is the signature verified, or just shown?

The portable lesson from all three cases, the two this week and our own, is that a signature is only worth what the thing checking it actually does. A signed attestation you cannot re-verify is a claim wearing a uniform. So here is what to check on any protocol that shows you a signed reserve or price, and how to run it on us.

• Can you recover the signer yourself, not just read a green flag? A trustworthy attestation lets you take its message and signature and recover the signing address independently, rather than trusting a "verified" badge the same server printed. Our endpoint recovers the signer server-side and exposes the result, and /verify recovers it again in your own browser, so the badge is not the evidence, the recovery is.
• Are the numbers bound to the signature, or just next to it? Ask whether the displayed figures rehash to the signed hash, or whether they are unsigned fields sitting beside a real signature. If they are not bound, they can be swapped while the signature stays valid, which is exactly the replay hole we closed on ourselves on May 29. Our /api/por/signed now returns hash_matches and a single verified field that is only true when the signer is recovered, matches, is fresh, and the numbers rehash.
• Is the on-chain part readable without trusting the signer at all? The strongest reserve figure is one you do not have to take signed, because you can read it from the chain directly. Our on-chain leg is at /api/por, and the Ostium episode is the cautionary version of this: the vault balance was public the whole time, and the loss was still reported as a range because almost nobody read it.
• Is there a second source, or one signer? One authorized key that can assert a price or a reserve, with nothing to disagree, is the Ostium shape. We disclose our own remaining single-signer surfaces, the attestation signer and the strategist role, and what each can and cannot do, on our open-gaps page at /legible, rather than leave you to discover them.

Being signed is not the same as being verified

Every one of these systems showed a green light. Ostium's prices were validly signed. Supra's check returned true. Our old endpoint said signer-matched. The gap between a signature existing and a signature being checked is where the money went, and it is invisible from the outside unless the protocol hands you the tools to close it yourself. That is the entire reason we build the verification into the product instead of asking you to trust the dashboard, and the reason we publish our own failures in it. If you hold or lend against someone else's synthetic dollar and want this same question, is the attestation actually verified or only displayed, answered about them, that is what an independent counterparty read is for. And you can hold the same standard against us, right now, at /verify.

Figures are as of July 17, 2026 and move as more is disclosed; nothing here is investment advice, and nothing here asserts a root cause Ostium has not confirmed, insider wrongdoing by any party, or that any vendor's bug class is provably closed. The Ostium incident, an authorized oracle-signer path used to submit future-dated signed price reports and drain the public liquidity vault on Arbitrum on July 15, 2026 within a roughly five-minute window, with reported losses ranging from about eighteen million dollars per Blockaid's initial estimate to roughly twenty-four million per later on-chain analysis from PeckShield, Cyvers near twenty-three point seven, and no final accounting published as of the day after, is per reporting by CoinDesk and Crypto Briefing, with each figure attributed to its firm. The Bonzo incident, a price update carrying a zeroed BLS signature against a zeroed committee public key that Supra's verifier accepted because the pairing check was not guarded against zero and identity inputs, used to borrow roughly nine million dollars against a few dollars of deposited SAUCE on Hedera on July 11, 2026, is per reporting by CoinDesk and a technical walk-through by CryptoSlate, consistent with Bonzo's own incident report; the subsequent commitment by the Bonzo Finance Foundation, with Hedera Foundation backing, to restore affected pre-exploit positions through redemption contracts under a Halborn audit is per Crypto Times. Kerne is not affiliated with Ostium, Bonzo, Supra, PeckShield, Cyvers, Blockaid, or the Hedera Foundation. Kerne's own May 2026 Proof-of-Reserves relay defects and their fixes are documented in our public repository; the current endpoint recovers the signer and binds the figures, verifiable live at /api/por/signed and reproducible at /verify, with the on-chain reserve leg at /api/por and our open-gaps list at /legible. A verification pass proves an attestation is authentic, fresh and bound to its numbers; it is not an audit and not a solvency opinion.