VII Finance — more value extracted by liquidations than expected (`normalizedToFull`)

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 61329-more-value-can-be-extracted-by-liquidations-than-expected-du. Standalone Foundry PoC and full write-up: 61329-more-value-can-be-extracted-by-liquidations-than-expected-du_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/liquidation-logic · liquidation-manipulation · integer-bounds

Reproduction: a self-contained Foundry PoC that compiles & runs in an isolated project with only forge-std — no fork, no RPC, no anvil_state. Full trace: output.txt. PoC: test/61329-more-value-can-be-extracted-by-liquidations-than-expected-du_exp.sol.

AuditVault taxonomy — lang/solidity · platform/cyfrin · has/poc · severity/high · sector/dex · sector/lending · sector/nft · genome: liquidation-logic · liquidation-manipulation · variant · integer-bounds · liquidation-underwater

Key info#

TL;DR#

1. Liquidation / value transfer walks every enabled tokenId and converts a unit-of-account amount into an ERC-6909 amount via normalizedToFull.
2. normalizedToFull multiplies by totalSupply(tokenId) instead of the sender's own ERC-6909 balance of that tokenId.
3. When the violator owns less than 100% of any tokenId, each leg of the transfer is inflated; the liquidator receives more value than requested.
4. Fix: multiply by balanceOf(sender, tokenId).

The vulnerable code#

function normalizedToFull(uint256 tokenId, uint256 amount, uint256 currentBalance) public view returns (uint256) {
    // @audit => multiplying by the total ERC-6909 supply of the specified tokenId is incorrect
    return Math.mulDiv(amount, totalSupply(tokenId), currentBalance); // @> VULN
}

Recommended fix:

-       return Math.mulDiv(amount, totalSupply(tokenId), currentBalance);
+       return Math.mulDiv(amount, balanceOf(_msgSender(), tokenId), currentBalance);

Root cause#

balanceOf(sender) is the sum of unit-of-account values across enabled tokenIds. For each tokenId the code must convert amount / currentBalance into a fraction of the sender's claim on that tokenId. Using totalSupply treats the sender as if they owned 100% of every tokenId, so partial ownership inflates the ERC-6909 amount transferred on every other leg as well.

Preconditions#

• Sender has enabled multiple tokenIds (or one partially owned tokenId).
• Sender owns less than 100% of at least one enabled tokenId (prior partial transfer / partial liquidation / shared position).
• A value-denominated transfer(to, amount) is executed (liquidation path).

Attack walkthrough#

1. Borrower wraps two positions (tokenId1, tokenId2), full supply 100 each.
2. Borrower transfers half of tokenId1 to another account → owns 50 + 100 = 150 value.
3. Liquidator requests transfer of 75 (half of remaining value).
4. Bug: tokenId1 transfers 75 * 100 / 150 = 50 (all remaining); tokenId2 transfers 75 * 100 / 150 = 50 → 100 value seized vs 75 requested (+25 surplus).
5. Correct formula would transfer 25 + 50 = 75.

Diagrams#

Impact#

Liquidated accounts incur larger losses than the liquidation parameters specify. Repeated partial liquidations amplify the surplus extraction.

Sources#

• AuditVault finding #61329
• Cyfrin 2025-07-15 vii-v2.0 report
• Vulnerable source: kankodu/vii-finance-smart-contracts — ERC721WrapperBase.normalizedToFull (fixed in b7549f2)

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 61329-more-value-can-be-extracted-by-liquidations-than-expected-du_exp (evm-hack-registry mirror).
• AuditVault finding: 61329-more-value-can-be-extracted-by-liquidations-than-expected-du.

Alerts & third-party analyses

• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.