DEV Community: mehvetero

The Hacker Who Lost $7.73M to a Bot — rsETH Safe Module Exploit

mehvetero — Tue, 15 Sep 2026 23:49:46 +0000

On September 15, 2026, someone found a bug in a custom router module attached to a Gnosis Safe holding over $7.73 million in Aave-wrapped rsETH. They built the exploit, submitted it to the mempool — and an MEV bot named Yoink copied the transaction and executed it first. The attacker showed up an hour later to scrape leftovers.

This write-up covers what I was able to verify on-chain and what I had to rely on others for. The router's source code is not published on Etherscan, so the internal vulnerability mechanism comes from SlowMist's bytecode analysis, credited below. Everything else — the Safe configuration, the money flow, the attacker timeline, and the current state — I read directly from the chain.

All read : https://x.com/mehvetero/status/2100007912953491857

$500 vs the 1inch DAO Treasury — Anatomy of a Live Governance Attack

mehvetero — Tue, 15 Sep 2026 11:08:50 +0000

On September 14, 2026, a fresh wallet with six transactions submitted two governance proposals against 1inch DAO's treasury Safe. One of the two can actually execute. This post breaks down exactly what happened, what can happen next, and what the on-chain parameters say about the timeline.

Every value in this post was read directly from Ethereum mainnet via eth_call or transaction receipt logs. No assumptions, no docs-only claims.

The attacker

Address: 0x6f25Cc4d6bD161e7F4514948AF1aE1B8bafF5AE1

Total lifetime transactions: 6. All on September 14, 2026.

Funding: 0.197702 ETH from 0x3f3e...0207b (ChangeNOW deposit address — anonymous instant exchange, no KYC) plus 0.0036 ETH from a second address. Total received: 0.2013 ETH. After posting two 0.1 ETH bonds and paying gas, the wallet holds 0.000913 ETH.

What 1inch uses

1inch DAO's treasury is a Gnosis Safe multisig at 0x7951c7ef839e26F63DA87a42C9a87986507f1c07 (7-of-12 threshold).

The Safe has a Zodiac RealityModuleETH enabled as a module. This module can execute transactions on the Safe without requiring multisig signatures — that is the entire point of SafeSnap governance. Proposals go through Reality.eth as an optimistic oracle: if no one disputes the answer within the timeout, the module can execute.

Two proposals, one live

The attacker submitted two proposals to two different RealityModuleETH contracts. Only one of them is actually connected to the treasury Safe.

Proposal 1 — "wave3-drain" (THE LIVE ONE)

Field	Value
Module	`0xa62d2a75eb39c12e908e9f6bf50f189641692f2e`
Module enabled on Safe	YES (verified via `isModuleEnabled()`)
proposalId	`wave3-drain`
questionId	`0x03b47cdd30ffa3f228f186bf7123ab6e73671c5b0c36bed8006eb84249e79f7d`
txHashes	5 batched operations
Submitted	Sep 14, 15:31:47 UTC
YES bond	0.1 ETH at 15:34:23 UTC
Proposal TX	`0x4db430aa...`
Bond TX	`0x47a4c2f6...`

This module is enabled on the treasury Safe. If the Reality.eth question finalizes as "YES" and the cooldown passes, executeProposal can run 5 transaction batches against the Safe.

The name "wave3-drain" is not subtle.

Proposal 2 — "wave5-accumulation-001" (CANNOT EXECUTE)

Field	Value
Module	`0xa7456392eb978a756264d54968f55baf227fcbcf`
Module enabled on Safe	NO (verified via `isModuleEnabled()`)
proposalId	`wave5-accumulation-001`
questionId	`0xf84299c435bfe991936dfdfec377cc4e700a70b7fddd465385cbe832d786dae1`
txHashes	1 batched operation
Submitted	Sep 14, 16:37:35 UTC
YES bond	0.1 ETH at 16:37:59 UTC
Proposal TX	`0xeb8e7593...`
Bond TX	`0xb3ecad6e...`

This module is not enabled on the treasury Safe. Even if the Reality question finalizes as "YES," executeProposal will revert because the Safe will reject the call. This proposal is either a decoy, a mistake, or aimed at a different Safe.

On-chain parameters (RealityModuleETH 0xa62d)

These values were read via eth_call against the live contract on Ethereum mainnet, cross-verified on two independent RPC endpoints.

Parameter	Value	What it means
`questionTimeout`	259,200 seconds = 72 hours	Time for the Reality.eth answer to be challenged. Each dispute resets the clock.
`questionCooldown`	259,200 seconds = 72 hours	Delay after the answer finalizes before `executeProposal` is allowed. This is the veto window.
`answerExpiration`	604,800 seconds = 7 days	Finalized answers expire after 7 days. Execution must happen within this window.
`minimumBond`	100,000,000,000,000,000 wei = 0.1 ETH	Minimum bond to post an answer on Reality.eth.
`oracle`	`0x5b7dD1E86623548AF054A4985F7fc8Ccbb554E2c`	RealityETH_v3_0 on Ethereum mainnet
`avatar`	`0x7951c7ef839e26F63DA87a42C9a87986507f1c07`	The treasury Safe this module controls

Timeline (wave3-drain, undisputed scenario)

Sep 14, 15:34 UTC — Attacker posts YES bond (0.1 ETH)
                     72-hour question timeout starts

Sep 17, 15:34 UTC — If undisputed, Reality answer finalizes as YES
                     72-hour cooldown starts
                     Safe signers can veto during this window

Sep 20, 15:34 UTC — Cooldown ends, executeProposal becomes callable
                     5 transaction batches run against the treasury Safe

Sep 21, 15:34 UTC — Answer expires (7-day answerExpiration)
                     Execution no longer possible after this point

If someone posts a "NO" bond at any time during the question timeout, the clock resets. The escalation continues until one side stops bonding. The last answer standing after 72 hours of silence wins.

During the 72-hour cooldown, the 7-of-12 Safe signers can intervene — remove the module, move funds, or otherwise prevent execution.

The treasury

Safe: 0x7951c7ef839e26F63DA87a42C9a87986507f1c07

Verified holdings at time of writing (Etherscan):

Asset	Amount	Value
Aave Ethereum USDC	2,712,464	~$2.71M
ETH	257.53	~$647K
WETH	243.45	~$612K
1INCH	4,650,219	~$433K
WBTC	1.92	~$150K
DAI	128,520	~$129K
USDT	81,984	~$82K
Other (67 tokens)	—	—
Total		~$4.76M

The 5 transaction hashes in wave3-drain are opaque — SafeSnap commits to the hash without revealing the operations until execution. What they target (token approvals, transfers, or something else) is not publicly visible.

The attack economics

Item	Cost
ChangeNOW funding	0.1977 ETH (~$497)
Second funding	0.0036 ETH (~$9)
Gas (4 transactions)	~0.0003 ETH (~$0.75)
Total spent	~$507
Bonds (refundable if YES wins)	0.2 ETH (~$502)
Non-refundable cost	~$6 (gas + ChangeNOW fee)

If wave3-drain passes unchallenged, the attacker spends $6 in gas to gain execution rights over ~$4.76M.

How to block wave3-drain right now

Post a "NO" bond on the Reality.eth question. The question ID is 0x03b47cdd30ffa3f228f186bf7123ab6e73671c5b0c36bed8006eb84249e79f7d on RealityETH_v3_0 at 0x5b7dD1E86623548AF054A4985F7fc8Ccbb554E2c (Ethereum mainnet). Minimum bond: 0.1 ETH. This resets the 72-hour clock.
Safe signers: Even if the question finalizes, you have 72 hours of cooldown before execution is possible. During that window, you can remove the RealityModuleETH from the Safe or move assets.
Longer term: Raise the minimum bond. 0.1 ETH for a $4.76M treasury means the cost of an attack attempt is $6 in gas. Consider restricting who can call addProposal or requiring a minimum token balance.

Pattern recognition

This is the same vulnerability class as Term Finance ($8.5M, August 2026), which I analyzed previously. Different mechanism — Term was token-weighted voting, 1inch is an optimistic oracle — but the same root cause: governance security that depends on human attention fails when nobody is paying attention.

Term Finance: $951 bought 90.66% of the vote. Nobody else voted.
1inch DAO: $6 in gas submitted a drain proposal. Nobody disputed it yet.

The wave numbering tells the story. Wave 1 through wave 4 were apparently blocked. Each time, someone noticed and disputed. The attacker keeps trying because the cost is near zero and they only need to succeed once.

The code is correct. The parameters are configured. The 72+72 hour design gives the signers time. The question is whether anyone is watching the clock.

On-chain references

Attacker:      0x6f25Cc4d6bD161e7F4514948AF1aE1B8bafF5AE1
Treasury Safe: 0x7951c7ef839e26F63DA87a42C9a87986507f1c07
RealityModule: 0xa62d2a75eb39c12e908e9f6bf50f189641692f2e (enabled)
RealityModule: 0xa7456392eb978a756264d54968f55baf227fcbcf (NOT enabled)
Reality Oracle: 0x5b7dD1E86623548AF054A4985F7fc8Ccbb554E2c (Ethereum)

wave3-drain questionId:
0x03b47cdd30ffa3f228f186bf7123ab6e73671c5b0c36bed8006eb84249e79f7d

wave5-accumulation-001 questionId:
0xf84299c435bfe991936dfdfec377cc4e700a70b7fddd465385cbe832d786dae1

Every value in this post was read from Ethereum mainnet via eth_call or transaction receipt parsing. No transactions were submitted.

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