DEV Community: mehvetero

How $951 Bought a $8.5M Vote: The Term Finance Governance Exploit

mehvetero — Thu, 27 Aug 2026 01:04:12 +0000

Zero bugs. Zero hacks. Just a vote.

On August 23, 2026, at 06:25 UTC, an attacker executed a single parameterless function call on Ethereum and walked away with $8.5 million from Term Finance's vaults. No exploit in the traditional sense — no reentrancy, no overflow, no oracle manipulation. The smart contracts worked exactly as designed. The attacker simply voted.

This is the anatomy of a governance takeover — the kind of attack that no code audit would have caught, because the code was never the problem.

The Target

Term Finance is an Ethereum-based fixed-rate lending protocol. Its yield products — the Meta Vaults — sit on Yearn V3 infrastructure with a custom governance layer bolted on top. Users deposit ETH and USDC into these vaults, which then deploy capital across strategies in Aave, Morpho Blue, and other lending markets.

At the time of the attack, Term's vaults held roughly $12.45 million in TVL, with $8.8 million on Ethereum mainnet.

The governance design: vault depositors receive a governance token (tmvETH) proportional to their stake. Token holders vote on proposals that control vault parameters — which strategies to add, what fee structures to use, where capital flows. A 7-day timelock and an LP veto mechanism were supposed to prevent hostile proposals from executing.

All of this worked as intended. That was the problem.

The Kill Chain

Day 0 — August 17, 05:01 UTC: The $951 Coup

Block 25,772,572. A fresh wallet (0xa908b347...) receives 0.9945 ETH from an intermediary funded by Tornado Cash. Two ETH total — seed money.

Block 25,772,675 (twenty minutes later). The wallet purchases 0.4852 tmvETH — the governance token for Term's ETH Meta Vault — for approximately 0.5 ETH.

Cost: roughly $951.

The total staked supply of gtmvETH at that moment: 0.5352.

The attacker now controls 90.66% of all voting power in the ETH Meta Vault. Four USDC strategy vaults fall under full control as well — their governance participation was even thinner.

The entire defense model assumed the electorate would be large enough that no single buyer could reach a majority. It wasn't. The governance token market was so thin that the protocol's security reduced to a liquidity depth question — and no one was watching the depth.

Day 0 — Proposals Submitted

With 90.66% voting power, the attacker submits governance proposals to the affected vaults. The proposals contain two critical actions, ordered deliberately:

Action 1: Set the timelock cooldown to zero.

This is the move that made everything else possible. The 7-day timelock was the last line of defense — after a proposal passes, there's supposed to be a mandatory waiting period before execution. The attacker's first action upon execution removes that waiting period for all subsequent proposals. One vote to end all future delay.

Action 2: Add a new "strategy" contract.

In Yearn V3 architecture, strategies are the modules that deploy vault capital into external protocols. The attacker's "strategy" is a contract whose sole purpose is to route withdrawn funds to the attacker's address (0x184f2e57b4...). It looks like a strategy. It functions as a drain.

Day 1–5 — Silence

The proposals sit in the timelock queue. The 7-day waiting period ticks.

Term Finance had an LP veto mechanism — liquidity providers could reject hostile proposals during this window. Nobody vetoed. The governance forum showed no discussion of these proposals. The monitoring infrastructure either didn't exist or didn't trigger.

Five days of a loaded gun sitting on the table, and nobody noticed.

Day 6 — August 23, 06:25 UTC: Execution

Block 25,816,049. The attacker calls 0x373058b8 on the governance executor contract (0x64e47780...). A single function, no parameters. Execute.

What happens inside this transaction — 78 log events in total:

The timelock cooldown drops to zero (Action 1 fires)
The malicious strategy is added to the vault roster
The Meta Vault begins withdrawing from its real strategies:
- Aave WETH pool: two sub-vaults redeemed
- Morpho Blue (0xbbbbbbbb...): two withdrawals via Yearn V3 wrapper
- Each redemption flows back through the Meta Vault aggregator (0x26fcb50e...)
Capital is routed to the attacker's strategy (0x184f2e57b4...)
The strategy forwards 2,841.74 WETH to the attacker wallet

Transaction: 0xd354a15b...

A separate execution drains the USDC vaults — approximately 1.68 million USDC, immediately swapped to DAI through on-chain DEX routes.

Total extraction: ~$8.5 million from a $951 investment.

Return on capital: 8,938x.

The Money Trail

Post-drain, the attacker moves quickly but not completely.

The 2,841 WETH is unwrapped to ETH and forwarded through a series of splitter contracts, all pointing to variations of 0xd518... addresses. Address poisoning tactics are visible in the transaction log — fake "EṬH" transfers (note the modified T character: Ṭ vs T) sent to similar-looking addresses, a social engineering technique targeting anyone monitoring the flow who might copy-paste the wrong destination.

As of this analysis, the consolidation wallet 0xD5183d8BfC65a50863C62aF2538198A8288FFc13 holds:

Asset	Amount	USD Value
ETH	2,543.15	~$6.15M
DAI	1,679,642.45	~$1.68M
Total		~$7.83M

Approximately $670K has been spent on gas, forwarding, and partial exits. The bulk remains untouched — either the attacker is patient, or they're waiting for attention to die down.

Why Every Safeguard Failed

The Timelock Paradox

A 7-day timelock is only useful if someone is watching. Term Finance's governance participation was so low that the proposals passed with zero opposition. But the deeper design flaw is subtler: the timelock itself was governed by the same vote that it was supposed to protect against.

The attacker's first action — setting cooldown to zero — is the governance equivalent of using the first wish to wish for unlimited wishes. If the entity that controls the timelock is the same entity the timelock is supposed to constrain, the timelock is decorative.

The Veto That Wasn't

LP veto rights existed on paper. No LP exercised them. This isn't an implementation failure — it's a participation failure. The mechanism assumed LPs would:

Monitor the governance forum
Understand the proposals
Recognize the threat
Act within the window

Each assumption was individually reasonable. Together, they built a defense that required four human actions in sequence, any one of which could fail to happen. The attacker only needed one to not happen. It was all four.

The Token Distribution That Nobody Checked

The most fundamental failure: at the moment of attack, the governance token had a total staked supply of 0.5352 gtmvETH. The entire security model — the votes, the timelock, the veto — was downstream of a single assumption: that this number would be large enough to make a hostile majority prohibitively expensive.

It cost $951.

No monitoring system checked this number. No circuit breaker fired when a single address acquired 90% of voting power. The protocol treated governance token concentration as someone else's problem.

The Architecture Lesson

This exploit belongs to a class that traditional smart contract audits cannot catch. The code functioned correctly. The governance mechanism executed as specified. The timelock enforced its rules. Every require passed, every assert held, every state transition was valid.

The vulnerability was economic, not technical:

Governance security is a function of participation, not mechanism design. A perfectly designed voting system with 0.5 participants is less secure than a flawed one with 10,000.
Timelocks must not govern themselves. If a governance vote can modify the timelock parameters, the timelock provides exactly one window of protection — the first one. After that, the attacker owns the clock.
Token concentration is a security metric. Protocols that expose governance power through thin markets need circuit breakers: minimum quorum, concentration alerts, automatic pause when a single address crosses a voting threshold.
The veto window is a monitoring commitment, not a safety feature. A veto mechanism that nobody monitors is indistinguishable from no veto mechanism at all.
$951 is cheaper than an audit. The attacker spent less on this entire operation than most protocols spend on a single smart contract review. The audit would have found nothing — the code was clean. The governance design was the attack surface, and no auditor was looking at token distribution depth.

What Should Have Existed

Minimum quorum: proposals below X% participation cannot execute, regardless of vote ratio
Concentration alert: if a single address holds >Y% of voting power, governance enters emergency mode (pause + multisig override)
Timelock immutability: core safety parameters (timelock duration, veto window) cannot be modified through governance — they require a multisig or are hardcoded
Strategy whitelist with independent approval: new strategy contracts require approval from a separate security council, not the same governance that benefits from the strategy
Active monitoring with auto-pause: governance proposal submission triggers alerts to all LPs, and proposals modifying safety parameters auto-escalate to a higher approval threshold

None of these are novel. All of them existed in other protocols before this attack. They just weren't implemented here.

Timeline

Date	Event
Aug 17, 05:01 UTC	Attacker wallet funded via Tornado Cash (2 ETH)
Aug 17, 05:21 UTC	0.4852 tmvETH purchased (~$951) → 90.66% voting power
Aug 17 (est.)	Governance proposals submitted
Aug 17–22	6-day timelock window — zero vetoes, zero discussion
Aug 23, 06:25 UTC	Proposals executed: timelock zeroed, malicious strategy added, 2,841.74 WETH drained
Aug 23, 06:25+ UTC	USDC vaults drained (~1.68M USDC → DAI)
Aug 23	Term Labs shuts down all Meta Vaults, revokes DAO governance roles
Aug 26 (this analysis)	$7.83M still in consolidation wallet

On-chain data sourced via Alchemy Ethereum mainnet RPC. All addresses and transaction hashes are independently verifiable on Etherscan.

BlueMove Was Not an Overflow Bug — How a Cross-Version Reserve Desync Drained 714,000 SUI

mehvetero — Tue, 11 Aug 2026 19:23:45 +0000

On July 11, 2026, at 22:13 UTC, an attacker began draining liquidity pools on BlueMove DEX, a Sui-based AMM. Within 23 minutes, approximately 714,000 SUI — roughly $528,000 at the time — had crossed a Wormhole bridge as USDC. The contracts were immutable. The pools were empty. There was no way to patch or freeze.

BlueMove called it "a long-standing arithmetic overflow bug in the legacy AMM contract." Tyler Simpson of Quantum Void Labs called it a backdoor — a function shipped in a May 31 upgrade that set the stage for the drain.

Both accounts identify real pieces of the story. Neither captures the mechanism that made the drain possible.

I decompiled every module of both package versions, tested Move's integer behavior directly, and traced the attack transactions command by command. To the best of my knowledge, this is the first public analysis that identifies the actual exploit path: a reserve desynchronization between two callable versions of the same package. Both versions write reserve_x after every operation, but they write different values — V1 writes pool.token_x.value(), V-latest writes escrow.token_x.value(). When a V1 swap runs on a pool whose main liquidity lives in the escrow, reserve_x drops to the small pool.token_x balance, while the escrow retains the large one. The next V-latest mint divides by this deflated reserve_x, inflating LP tokens by the ratio between the two balances.

See all- https://mehvetero.com/

How One Missing Assert Drained $1.14M From Aftermath Finance — A Signed Integer Exploit on Sui

mehvetero — Sat, 01 Aug 2026 14:17:38 +0000

A technical breakdown of the Aftermath Finance perpetuals exploit (April 29, 2026). How a negative fee value bypassed validation, inflated collateral, and allowed an attacker to drain $1.14M USDC in 36 minutes — and what a single line of code would have prevented.

https://mehvetero.com/

How a Missing `assert!` Drained $3.44M From Typus Finance — and Why the Code Looked Correct

mehvetero — Sat, 01 Aug 2026 14:15:29 +0000

On October 15, 2025, at 13:05 UTC, an attacker began draining Typus Finance's TLP liquidity pool on the Sui network. Thirty-four minutes later, the contracts were paused — but the pool was already empty. Over the hours that followed, the stolen SUI, xBTC, and suiETH were swapped to USDC on-chain, then bridged to Ethereum via Circle's CCTP in 14 transactions. Total loss: $3.44 million.

The root cause was a single line of Move code that looked like an authorization check — called the right function, passed the right arguments, sat in the right place — but silently discarded its result. The oracle module had been live for eleven months.

I pulled the vulnerable source from GitHub, compared it against the post-incident rewrite, and traced the attack on-chain. This is what I found.

https://mehvetero.com/

Three Sui Exploits, One Disease — Why "The Math Looked Fine" Keeps Costing Hundreds of Millions

mehvetero — Mon, 27 Jul 2026 19:36:42 +0000

Cetus lost $223M to a shift overflow. Aftermath lost $1.14M to a negative fee. Bucket Protocol ships a decimal scaling bug today. All three passed audits. All three have the same root cause.

I've spent the last month reading exploit post-mortems, scanning production Sui contracts, and building lint rules to catch what I kept seeing. After the third time the same shape showed up, I stopped thinking of these as separate incidents.

They're the same bug wearing different clothes.

https://mehvetero.com/

I Built an Open-Source Security Linter for Sui Move — Here's What It Found on Real Protocols

mehvetero — Fri, 24 Jul 2026 14:30:38 +0000

I've been building move-test-gen, a security tool for Sui Move smart contracts. It started as a test generator and grew into a coverage checker with mutation testing and a security linter. This post covers what it does, what it found when I pointed it at production DeFi protocols, and how to use it in your own CI.

The Problem

Sui's built-in linter has 6 rules — all focused on object handling (self-transfer, share-owned, etc.). Nothing about arithmetic overflow, missing access control, or unsafe type casting. MoveScanner exists but is closed-source and commercial.

If you're writing Move and want a slither-equivalent that checks security patterns on every PR — there isn't one. Or there wasn't.

What move-test-gen Does

Three layers, each independent:

Layer 1 — Assert pairing. Scans every assert! and abort in your source modules, every #[expected_failure] in your tests, and tells you which abort paths have no test coverage. Runs in seconds, needs only Node.js.

Layer 2 — Mutation testing. Injects deterministic bugs (flip a < to >=, comment out an assert!) and checks whether your test suite catches them. If a mutant survives, the test that should have caught it is too weak. 7 operators, exhaustive mode. Needs sui CLI.

Layer 3 — Security lint. 4 rules that scan for common vulnerability patterns:

Rule	Severity	What it catches
MOV-001	HIGH	`public fun` with `&mut` but no capability, key, or witness — missing access control
MOV-002	HIGH	`u64 * u64` without `u128` promotion — arithmetic overflow risk
MOV-003	MEDIUM	Division by a variable without prior zero-check
MOV-004	MEDIUM	`(expr as u64)` downcast from u128/u256 without overflow assert

MOV-002 and MOV-004 use a lightweight Move parser (scripts/move-parser.mjs) that tracks variable types through declarations, casts, and naming conventions. So it knows that numerator1 assigned from liquidity_u256 << RESOLUTION is u256 — no false positive on the multiplication.

What It Found on Real Protocols

I ran the linter against four production Sui DeFi protocols:

Kriya DEX — 1 finding

🔴 HIGH  spot_dex.move:187  [MOV-001]
  public function modifies state without capability check:
  `update_pool` takes &mut but no capability parameter

This is the same access control gap I reported manually in a 6-finding security review. The rule catches it in under a second on 3 source files.

Scallop Lending (172 files) — 2 findings

🔴 HIGH  liquidation_evaluator.move:143  [MOV-002]
  `LIQUIDATION_CAP_DIVISOR * debt_price_raw` — overflow risk

🟡 MEDIUM  limiter.move:189  [MOV-004]
  `(i as u64)` — downcast without overflow check

Initial run hit 82 false positives. Generic functions fun name<X, Y>() were invisible to the regex, test modules were scanned, Sui-specific patterns like Witness<T> and Version params weren't recognized. 9 commits to fix all of that. After hardening: these 2 legitimate findings, zero false positives on production code.

Bucket Protocol — Fix PR Submitted

MOV-002 flagged three sites in compute_collateral_value_to_buck and compute_buck_value_to_collateral where mul_factor (which safely promotes to u128 internally) is followed by a raw u64 multiplication that undoes the protection. I submitted a fix PR — three lines changed, u128 intermediate cast.

The overflow doesn't affect current deployments (SUI is 9 decimals = BUCK decimals, so the scaling factor is 1), but adding a collateral type with higher decimals would break liquidation, redemption, and health checks. The OtterSec V1 audit caught a related conversion issue but not the overflow in the fix itself.

How to Use It

One-liner (no install)

npx mehvetero/move-test-gen sources tests --lint

In CI — GitHub Action

# .github/workflows/move-security.yml
name: move-security
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: mehvetero/move-test-gen@v1.3.0
        with:
          sources: sources
          tests: tests
          lint: 'true'

Layer 1 + lint runs in seconds with zero dependencies. For mutation testing, add mutate: 'true' and install sui — there's a nightly schedule example in the repo.

Marketplace: move-test-gen coverage check

As an Agent Skill

The tool is also an agentskills-compatible skill. Install:

npx skills add mehvetero/move-test-gen

Then ask your coding agent: "Generate edge-case tests for sources/vault.move" — it produces #[test] and #[expected_failure] functions covering boundary values, arithmetic overflows, access control violations, and economic edge cases.

Agent Skill listing: agentskills Discussion #451

How It Compares

	move-test-gen	Sui built-in linter	MoveScanner	Aptos move-mutation-tools
Open source	Yes	Yes	No	Yes
Security rules	4 (MOV-001~004)	0 (object-handling only)	Many (undisclosed)	0
Mutation testing	Yes (7 operators)	No	No	Yes (Aptos only)
Sui support	Yes	Yes	Yes	No (Aptos only)
CI integration	GitHub Action	CLI flag	Commercial	CLI
Parser	Lightweight (function-level types)	Full compiler	Full compiler	Full compiler
Price	Free	Free	Paid	Free

The gap this fills: there's no open-source tool that does security-focused static analysis on Sui Move. The built-in linter handles object patterns. MoveScanner is commercial. Aptos has mutation tools but they don't work on Sui. This tool covers the middle ground — regex + parser based, not compiler-grade, but catches the patterns that actually show up in exploits.

Measured, Not Trusted

The tool has an eval lab (eval/) with 5 campaigns, 13 scenarios, and 47 rounds of testing. Frozen prompt templates, retirement-by-saturation protocol, dated records. The methodology is borrowed from TheColliery — full lineage in the RESULTS.md.

The lint rules were validated against Kriya DEX, Scallop (172 files), Bucket Protocol, and Turbos CLMM. Every false positive fix gets a selftest pin before it ships — 11 regression cases, all enforced in CI.

What's Next

More rules — clock staleness, upgrade policy, shared object access patterns
Parser improvements — tracking types through function calls, not just declarations
More protocol scans — each scan either validates the rules or finds a new pattern to handle
Contribution: if you have a Move security pattern that should be a rule, open an issue or PR a rules/mov-NNN-*.mjs file

Repo: github.com/mehvetero/move-test-gen
Marketplace: move-test-gen coverage check
Blog: mehvetero.com