Notary-sponsored transaction fees are not bounded by the individual payer deposit

Finding IDs

F-NEO-NOTARY-001

Status

fixed publicly

Fixed in

v3.10.1; network deployment not independently verified

Note

Notary-assisted transaction validation must account for each depositor's balance and fees already reserved by pending transactions. The 3 July 2026 patch introduces primary/secondary payer tracking, uses the individual Notary.BalanceOf value for sponsored transactions, accumulates mempool fees against that payer and rejects missing or negative balances during persistence. Regression coverage accompanies the accounting change. These changes are included in release v3.10.1. The evidence supports a released deposit/fee-accounting fix, not confirmation that every network node upgraded, that funds were stolen or recovered, or that a particular deployed chain reproduced the reported effect. Public-source review does not establish vendor attribution, an assigned severity or a fresh end-to-end retest.

F-NEO-NOTARY-001: Input / state handling. Fee accounting uses a shared payer boundary instead of the individual notary depositor and accumulated obligations. Reviewed 26 Sep 2026. Mechanism assessed by 1seal.

Mechanism source for F-NEO-NOTARY-001

Security area (1seal assessment): Integrity. Fee accounting uses a shared payer boundary instead of the individual notary depositor and accumulated obligations. Reviewed 26 Sep 2026.

• Source: github.com (external) ↗
• F-NEO-NOTARY-001
• v3.10.1: payer-specific pending-fee accounting
• v3.10.1: notary persistence checks
• v3.10.1 release
• Classification source