Verus & Ostium: Same Protocols, Hacked Twice, Same Excuse
Once is bad luck. Twice is a business model.
Verus got hit. Then Verus got hit again. Ostium got hit. Then Ostium got hit again. Different protocols, same script — a 'compromised key,' a fresh multisig, a promise of hardening, and a queue of users about to fund the third round. We looked at the pattern instead of the press release.
The Scheme
Two protocols — Verus (a ZK-friendly chain that keeps rebuilding its bridge) and Ostium (a perpetuals DEX on Arbitrum) — were exploited within weeks, patched, then exploited again on the same class of bug: keys that shouldn't have been hot, oracle signers that shouldn't have been reusable, and privileged upgrade paths nobody bothered to time-lock. Combined losses run into the double-digit millions.
The patch closed the door the attacker walked through. It didn't close the door next to it.
The Uncomfortable Part: This Wasn't A Zero-Day
In crypto, a 'sophisticated attack' usually means 'we forgot to rotate a key.' Both Verus and Ostium got hit by a class of failure that's been in every security checklist since 2022: privileged addresses with permanent power, oracle signers with shared secrets, and upgrade functions without a time-lock in front of them.
Verus got drained, blamed a compromised signer, redeployed, and got drained again — because the redeploy inherited the same operational model. Ostium got drained via oracle abuse, patched the specific oracle, and got drained again via a related mispricing path. Same building, different window.
The scary bit isn't that these bugs exist. It's that both teams shipped 'the fix' fast enough to look decisive, but not slow enough to understand what actually broke. In DeFi, speed of announcement now correlates inversely with quality of remediation.
'We've patched it' is a marketing statement. 'We've re-architected it' is a security statement. Learn the difference.
Anatomy Of A Repeat Exploit
A repeat exploit isn't a coincidence. It's a signature. It means the root cause was misdiagnosed the first time, the incident review was optimised for the tweet-length explanation, and the underlying trust assumption — 'this key is safe,' 'this signer set is honest,' 'this price feed is monotonic' — was never actually challenged.
In Verus's case, the trust assumption was that a small operator set could custody bridge reserves without a threshold-signing setup that would survive one compromised laptop. In Ostium's case, the assumption was that a perp DEX could rely on an oracle path that hadn't been stress-tested against a coordinated wick.
Both teams held the incident post-mortem in public — which is the right move — and both quietly declined to publish a full threat model. That's how you get to round two. The public sees a fix. The attacker sees a hint.
The first exploit is a bug. The second exploit is a policy.
Vocabulary Decoded: The Second-Hack Playbook
What the announcement said vs what it actually meant:
"Compromised private key"
What it sounds like:
An unlucky, highly targeted attack against a hardware wallet held by a specific team member.
What actually happened:
A hot key, on an internet-connected machine, with permanent authority over the protocol, was used because it was convenient. It got phished, malware'd, or leaked via a supply-chain package. 'Compromised' is passive voice for 'we chose speed over ceremony.'
"Oracle manipulation"
What it sounds like:
A sophisticated on-chain price attack that no reasonable team could have predicted.
What actually happened:
The protocol picked an oracle with a thin liquidity source and no TWAP fallback, because a real oracle costs money and shipping a testnet fork costs nothing. The attacker printed a wick and drained the perp side. It's not manipulation if the design invited it.
"We've upgraded the contracts"
What it sounds like:
The vulnerable code has been replaced by hardened, audited, time-locked code.
What actually happened:
A single admin key pushed a new implementation behind an upgradeable proxy, sometimes without a time-lock, sometimes without a fresh audit. 'Upgraded' can mean 'we changed one function.' It rarely means 'we changed the trust model.'
Every second-hack post-mortem uses the same three phrases. Ask why.
How A Protocol Gets Hit Twice
Four steps, every time. The names change; the sequence doesn't.
Step 1: Ship Fast, Trust Wide
Launch with a small multisig, a hot signer, and an upgradeable proxy behind a single admin key. TVL grows before governance does. The trust surface is already larger than the team is willing to admit in public.
Every 'decentralised' protocol has a founder's laptop in the loop. You just have to look for the plug.
Step 2: Get Hit Once, Announce Quickly
An attacker finds the obvious lever — a compromised signer, a mispriced oracle, an unchecked upgrade path. Funds move. The team posts a 200-word statement using the words 'isolated,' 'contained,' and 'compromised.' A patch ships in under 48 hours.
The clock on the second exploit starts the moment the first patch is announced. Because now the attacker knows what the team missed.
Step 3: Fix The Symptom, Not The System
The patch closes the exact function used. The trust model — who holds what key, which oracle feeds which market, who can upgrade what proxy — doesn't change. The team is exhausted, users want the protocol back online, and 're-architecting' loses to 'redeploying.'
'The pause button worked' is not an achievement when the pause button is the only thing standing between users and a repeat.
Step 4: Get Hit Again, Blame The Attacker
A related path — same key set, same oracle family, same upgrade surface — is exploited two to eight weeks later. The second statement is shorter than the first. It says the words 'sophisticated' and 'coordinated.' It does not say the word 'us.'
Sophisticated means the attacker read the first post-mortem carefully. Which, to be fair, is more than most users did.
Technical Kill Chain: The Repeat Pattern
Reconstructed from the public incident notes of both protocols, plus SlowMist and PeckShield alerts:
T-0: First Exploit Lands
A privileged signer or oracle path is abused. Funds exit through a bridge or a perp payout. The team notices via a Discord ping from a whitehat, not from internal monitoring.
'We were alerted by community members' is the sentence that ends every incident review no security team wants to write.
T+24h: The Statement
A post-mortem is published. It correctly identifies the immediate cause. It does not publish the threat model, the key custody diagram, or the oracle dependency graph. Users are asked to be patient.
The post-mortem is optimised for legal, not for security. That's why it reads like a press release with a chart.
T+3–14d: The Redeploy
New contracts are deployed. Sometimes with a fresh multisig, sometimes not. The upgrade path is preserved. The oracle vendor is swapped, not the oracle architecture. TVL comes back faster than the audit does.
A redeploy inside the same trust model isn't a fix. It's a reroll.
T+2–8w: Round Two
A second exploit — often by a different attacker who read the first post-mortem — hits a related surface. Losses are smaller than round one, because users have withdrawn. Reputation losses are larger, because now it's a pattern.
The second hack is where the retail bagholders find out what 'battle-tested' actually costs.
Two exploits. Same trust model. Same excuse. Different attacker. That's not bad luck — that's a spec.
The Repeat Offender Ledger: Round One vs Round Two
Two protocols, four incidents, one trust model. Laid side by side, the pattern stops looking like bad luck and starts looking like the attacker's business plan.
| Case file | Round one | The “fix” | Round two |
|---|---|---|---|
| Verus | Compromised bridge signer; reserves drained | Redeploy in days, same key set | Drained again — the key was never the bug |
| Ostium | Oracle path abused on the perp side | Vendor swapped, architecture untouched | Related mispricing, same feed family |
| Both | Alerted by Discord, not by monitoring | 200-word post-mortem | Second statement shorter than the first |
A thief who returns to the same house isn't bold. He just knows nobody changed the lock — they only varnished the door.
Who Else Runs This Pattern
The pattern didn't die with Verus and Ostium. Three three-minute checks tell you whether the protocol open in your other tab is next on the list.
1. Upgrade without time-lock
Find the proxy on the explorer: if the admin can swap implementation instantly, there's no perimeter.
2. Signers that never changed
Compare today's multisig with the pre-incident one. Same addresses = same risk.
3. A single price feed
If the docs name one vendor and no TWAP or deviation cap, you've seen the ending.
Three tabs, three minutes. More due diligence than half the seed round managed.
Why Users Come Back Anyway
The uncomfortable truth is that the users who get drained in round two are usually the ones who watched round one from the sidelines and thought the patch made things safer. It didn't. It made things targeted.
Yield Amnesia
An 18% APY on a redeployed contract looks like a bargain. It's a rebate for accepting undocumented risk. The market forgets in six weeks.
'They've Been Through It'
There's a folk belief that a protocol which survived an exploit is safer for it. It's the opposite. A protocol that survived is a protocol that's proven it will announce first and re-architect later.
Fear Of Missing The Recovery
'It'll never be this cheap again' is the second-most-expensive sentence in DeFi. The first is 'the team has this handled.'
The Ecosystem Vouch
A tier-1 investor tweets 'we still believe.' A partner protocol whitelists the new address. Users read that as due diligence. It's marketing collateral.
Repeat exploits don't survive on user stupidity. They survive on user hope — and hope is the only asset in crypto with unlimited supply.
How Not To Fund Round Three
Six rules for the next time a 'we've been exploited' post lands in your feed:
- Rule 1: Wait 60 days, minimum, after any post-mortem Not 6 hours. Not 6 days. Two full months of clean operation on the redeployed contracts, with public monitoring, before you re-enter.
- Rule 2: Read the threat model, not the tweet If the team hasn't published a key custody diagram, an oracle dependency graph, and a time-lock policy, they haven't finished the incident review.
- Rule 3: Check whether the upgrade path was time-locked A protocol whose admin key can push code instantly has no meaningful security perimeter. Governance without delay is theatre.
- Rule 4: Watch the signer set, not the branding If the multisig signers didn't change after a signer compromise, nothing changed. A rebrand is not a rotation.
- Rule 5: Assume oracle patches are partial Swapping a vendor is not swapping an architecture. Ask whether TWAP, circuit breakers, and manipulation caps were added — or just a new URL.
- Rule 6: Size for round two, not round one If you must return, size the position for the loss you'd accept in a second exploit. Because in a repeat pattern, round two is already priced in.
Got a Suspicious Message?
Use our AI-powered detector to analyze potential scams instantly.
Key Takeaways
- 1Verus and Ostium were both exploited twice on the same class of failure — privileged keys and oracle assumptions the first patch didn't touch.
- 2A repeat exploit is a diagnosis, not a coincidence. It means the trust model wasn't changed, only the specific function that got abused.
- 3'Compromised private key,' 'oracle manipulation,' and 'we've upgraded the contracts' are the three phrases that show up before every round two. Track them.
- 4Speed of announcement now correlates inversely with quality of remediation. A 24-hour patch is a symptom of pressure, not competence.
- 5Ecosystem vouches after an exploit are marketing, not due diligence. A tier-1 investor's tweet is not a security audit.
- 6If you must re-enter a protocol that was drained: wait 60 days, verify the signer set changed, verify the upgrade path is time-locked, and size for a second hit.
Once is a bug.
Twice is a policy.
Frequently Asked Questions
Sources & Citations
Research for this investigation compiled from publicly available blockchain data, security reports, and community documentation.
ostium.io
slowmist.com
peckshield.com
Verification: All blockchain transactions and addresses referenced in this article can be independently verified through the linked blockchain explorers. We encourage readers to conduct their own verification.
Methodology: Every case requires at least three independent sources plus verifiable on-chain evidence before publication. Full standards: /methodology
Legal notice: This assessment is based on publicly available data, including on-chain records, official statements and reported incidents. It is journalistic and educational analysis, not legal advice, an accusation of criminal conduct or a court finding. Named companies, projects, domains, wallets and individuals are described as reported by the cited sources; a company name may appear because fraudsters impersonated it, not because the company did anything wrong. If you believe something is inaccurate or out of date, write to cryptostrapon@proton.me and we will correct it and log the change. Editorial policy