Summary
On March 12, 2026, 8 transactions were charged fees vastly exceeding their signed resource_bounds. The primary TX was charged 1,845 STRK while the signed max_amount × max_price_per_unit was 0.506 STRK — a 3644x overcharge. Total loss across 8 TXs: 15,518 STRK (~$3,100 at the time).
This was first reported in starknet-io/starknet.js#1597, where the starknet.js maintainer acknowledged the issue and suggested escalating to StarkWare.
The problem
According to Starknet fee documentation, the ZK proof enforces that the sequencer cannot charge more than max_amount × max_price_per_unit. If this enforcement held, the overcharge should have been impossible.
Either:
- The sequencer charged beyond the signed bounds (protocol-level bug)
estimateInvokeFee returned insane bounds that were then signed (SDK bug, but sequencer should still cap)
- Something modified the
resource_bounds between signing and inclusion
Evidence
- Primary TX:
0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc (block 7654710)
- 8 affected TXs, blocks 7654710–7654901
- All TXs were AVNU swaps via
account.execute (starknet.js v6)
- Detailed analysis with all TX hashes in the original issue
Request
- Reproduce: Call
estimateInvokeFee on the historical blocks where each TX was included, and compare with the actual_fee charged
- Verify: Check if the
resource_bounds in the signed TX match what getTransactionByHash reports
- Explain: What caused the 3644x multiplier?
- Refund: If this is a sequencer bug, we request a refund of the overcharged amount (15,518 STRK)
Related
Summary
On March 12, 2026, 8 transactions were charged fees vastly exceeding their signed
resource_bounds. The primary TX was charged 1,845 STRK while the signedmax_amount × max_price_per_unitwas 0.506 STRK — a 3644x overcharge. Total loss across 8 TXs: 15,518 STRK (~$3,100 at the time).This was first reported in starknet-io/starknet.js#1597, where the starknet.js maintainer acknowledged the issue and suggested escalating to StarkWare.
The problem
According to Starknet fee documentation, the ZK proof enforces that the sequencer cannot charge more than
max_amount × max_price_per_unit. If this enforcement held, the overcharge should have been impossible.Either:
estimateInvokeFeereturned insane bounds that were then signed (SDK bug, but sequencer should still cap)resource_boundsbetween signing and inclusionEvidence
0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc(block 7654710)account.execute(starknet.js v6)Request
estimateInvokeFeeon the historical blocks where each TX was included, and compare with theactual_feechargedresource_boundsin the signed TX match whatgetTransactionByHashreportsRelated