How the Notional Finance V1 Escrow Exploit Turned a $2^128 Debt Into Zero

The reported Notional Finance incident was not a conventional collateral shortfall. The alleged weakness was an accounting mismatch: a massive fCash debt was created at the 2^128 boundary, then reduced to zero when the protocol narrowed it to uint128 while calculating free collateral. With the liability recorded as zero at that critical point, the account could appear solvent and withdraw assets it should not have been able to access. 416

The public reconstruction is based on on-chain monitoring and security-researcher reporting, rather than a published protocol post-mortem. That distinction matters: the movements of funds are observable, but the definitive call sequence, full impact, and remediation status were not confirmed in the reporting available at the time. 34

The accounting failure: a debt that evaluated as zero

Notional V1 represented future cash obligations as fCash. According to CertiK's public alert, the attacker used two mintfCashPair() calls to create a -2^128 liability. During free-collateral valuation, an unsafe conversion to uint128 reportedly truncated that value to 0. 16

In practical terms, the exploit path described by researchers was:

1. Create an extreme negative fCash position. The attacker generated a liability at the exact size where narrowing it to a 128-bit unsigned integer could discard the debt representation. 416
2. Trigger collateral valuation. The escrow's accounting reportedly converted the liability with an unsafe uint128 downcast.
3. Make debt disappear in the check. Instead of reflecting an enormous negative obligation, the calculation treated the value as zero. 46
4. Pass the withdrawal gate. With the debt omitted from free-collateral accounting, the account could appear to meet the conditions for withdrawing the escrow's liquid stablecoins. 46

This is why the issue is better understood as a narrowing-conversion and accounting-invariant failure than as a generic “integer overflow.” The critical reported effect was that a negative liability became zero precisely in the valuation path that was supposed to stop an undercollateralized withdrawal. 416

What was reportedly drained

On-chain reporting placed the loss at approximately 69,257 DAI and 1,650,824 USDC, or about $1.728 million. The assets were reportedly swapped into approximately 689.2 ETH and then deposited into Tornado Cash. 215

The contract identified in reporting was the Notional Finance escrow at 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. One report identified a setup transaction from an address ending in Ce38 at 11:58:47 PM UTC on September 3, 2026, followed roughly three minutes later by the drain transaction early on September 4. 1723

Investigators publicly associated two Ethereum addresses with the transfers:

• 0xC954…De69
• 0xDaCC…Ce38

Those labels describe an on-chain investigative association, not an identification of a person, organization, or ultimate controller. 11

Why the ETH route complicated recovery

The reported conversion from DAI and USDC into ETH changed the recovery landscape. The stablecoin transfers were plainly traceable on Ethereum, while the subsequent conversion dispersed the assets into ETH. The reported Tornado Cash deposits then added a privacy layer intended to obfuscate transaction origin, destination, and counterparties. 229

That does not make blockchain analysis impossible, nor does it establish who controlled any later withdrawal. It does mean the direct, asset-by-asset trail from the exploited escrow to a later recipient becomes substantially less straightforward once funds enter a mixer. 29

What remained unknown

At the time of the reports, Notional had not issued a public incident response, and several material questions remained open:

• the definitive technical root cause and complete exploit call flow;
• whether the reported transactions represented the full set of affected contracts, accounts, and assets;
• the final loss after swaps, fees, or any subsequent transfers;
• available pause, upgrade, compensation, or recovery options; and
• the attacker's identity and whether the publicly labelled addresses were the only wallets under common control. 3411

The reported cause should therefore be treated as a strong preliminary reconstruction, not a substitute for an audited post-mortem or an official incident report.

The security lesson for legacy DeFi systems

A legacy contract is not low risk merely because it is old or no longer central to a product's roadmap. If it still custody-holds assets or retains access to minting, settlement, collateral, or withdrawal flows, it remains an active financial attack surface.

For protocol teams, the reported Notional V1 failure highlights several controls worth validating together:

• use checked narrowing conversions and explicitly reject values that cannot be represented safely;
• test signed debt, settlement, and collateral calculations at numeric boundaries such as 2^128;
• encode solvency and conservation rules as invariants, then test them across multi-call sequences;
• review whether privileged or unusual call paths can compose minting, settlement, and withdrawals in an unintended order; and
• restrict callers and call flows wherever a function is unsafe outside its intended context.

The broader pattern is familiar in DeFi: a small defect in representation or authorization can become a full loss when it reaches a withdrawal path holding liquid assets. The key defense is not simply auditing individual functions, but proving that the system's accounting invariants continue to hold across every reachable sequence of calls.