Bug: actual_fee exceeds signed resource_bounds by 3644x — 15,518 STRK overcharged

[ttendoscopie-creator]

Sequencer Bug: actual_fee exceeds signed resource_bounds by 3644x — 15,518 STRK overcharged

Summary

On March 12, 2026, 8 transactions on Starknet mainnet were charged fees 3,644x higher than the resource_bounds signed and submitted in the transaction. A total of 15,518 STRK (~$3,100 at the time) was transferred from my account to the sequencer, despite the signed resource_bounds authorizing a maximum of 0.506 STRK per transaction.

This has been investigated by @PhilippeR26 (starknet.js collaborator) and @tabaktoni (starknet.js maintainer) in starknet-io/starknet.js#1597. Both confirmed that starknet.js behaved correctly — the issue is on the blockchain/sequencer side.

Evidence

Primary transaction

• TX hash: 0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc
• Block: 7654710
• Date: 2026-03-12

Signed resource_bounds (from getTransactionByHash)

resource_bounds: {
    l1_data_gas: { max_amount: '0x4b0', max_price_per_unit: '0x5079c49f0' },
    l1_gas: { max_amount: '0x0', max_price_per_unit: '0x472a0078fd55' },
    l2_gas: { max_amount: '0xdffea8', max_price_per_unit: '0x8085c3900' }
}

Maximum authorized fee: 0.506 STRK

Actual fee charged

The STRK contract transfer event in the transaction shows:

• From: my Braavos account (0x7dfa610d...)
• To: sequencer (0x1176a1bd84444c89232ec27754698e5d2e7e1a7f1539f12027f28b23ec9f3d8)
• Amount: 0x640f31aa1835efe060 = 1,845.77 STRK

Multiplier: 1,845.77 / 0.506 = 3,644x the authorized maximum

8 transactions affected

All between blocks 7654710–7654901 on 2026-03-12. Total overcharge: 15,518 STRK.

Analysis by starknet.js maintainers

@PhilippeR26 (collaborator):

"Without specific user instructions and margins, starknet.js has automatically defined and requested a max fee of 0.506 STRK, and the blockchain has generated an automatic fee transfer of 1845 STRK, breaking the limitation requested by the transaction request. No evidence how this 1845 STRK value has been calculated."

"My personal point of view is that all actions on Starknet.js side are legit. I can not say the same thing on blockchain side..."

@tabaktoni (maintainer):

"These numbers seem insane to be charged 3644x the regular fee."

Full thread: starknet-io/starknet.js#1597

Why this is a protocol-level bug

The Starknet fee documentation states:

"The ZK proof enforces that the sequencer cannot charge more than max_amount × max_price_per_unit."

This guarantee was violated. The signed resource_bounds authorized a maximum of 0.506 STRK, but 1,845.77 STRK was charged. Either:

1. The sequencer charged beyond the signed bounds — a direct violation of the fee protocol
2. The ZK proof did not enforce the bounds — a proving system bug
3. The STRK transfer was triggered by something other than the fee mechanism — which would indicate a different kind of vulnerability

In any case, this is not user error and not an SDK bug. The SDK signed a valid transaction with valid bounds. Something on the blockchain side overrode those bounds.

Reproduction steps

1. Call getTransactionByHash on 0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc → verify resource_bounds = max 0.506 STRK
2. Call getTransactionReceipt → verify actual_fee charged
3. Check the last transfer event in the TX → 1,845.77 STRK sent to sequencer
4. Call estimateInvokeFee on the historical block 7654710 for the same calldata → verify what estimate the network would have returned at that moment
5. Repeat for all 8 affected TXs (blocks 7654710–7654901)

Request

1. Investigation

Please investigate the root cause: why did the sequencer charge 3,644x the authorized resource_bounds? Was the ZK proof enforcement bypassed?

2. Refund

We request a refund of the overcharged amount: 15,518 STRK (total overcharge across 8 transactions). The signed bounds authorized ~4 STRK total; 15,522 STRK was charged.

3. Fix

Regardless of the root cause, the resource_bounds enforcement must be guaranteed. Other users relying on this protocol-level safety are exposed to the same risk.

Context

The transactions were AVNU SDK swaps (quoteToCalls → account.execute) on a trading bot. The bot has since implemented a hard cap on resource_bounds as a workaround, but this is a band-aid — the protocol should enforce the signed bounds as documented.

Account & contact

• Account: 0x7dfa610d64cff230d00e1c64dc648465bfcf4c74b4c5e0541613af0873869f5
• GitHub: @ttendoscopie-creator
• Original issue: V3 actual_fee exceeds resource_bounds by 3644x — 15,518 STRK lost starknet-io/starknet.js#1597