V3 actual_fee exceeds resource_bounds by 3644x — 15,518 STRK lost

[ttendoscopie-creator]

Summary

8 V3 INVOKE transactions on mainnet charged 1,270–2,240 STRK in gas fees each, while the signed resource_bounds cap the maximum fee at ~0.506 STRK. This represents a 3,644x violation of the resource bounds ceiling. Total loss: ~15,518 STRK.

According to Starknet fee docs, the ZK proof enforces that the sequencer cannot charge more than max_amount × max_price_per_unit. This enforcement appears to have failed.

Environment

• starknet.js: 8.9.2
• Network: Starknet Mainnet, version 0.14.1
• Block range: 7654710 — 7654901
• Date: 2026-03-12
• Account: Braavos `0x07dfa610d64cff230d00e1c64dc648465bfcf4c74b4c5e0541613af0873869f5`
• @avnu/avnu-sdk: 4.0.1

How execute() was called

```typescript
const feeEstimate = await account.estimateInvokeFee(swapCalls);
// ... fee validation ...
const result = await account.execute(swapCalls, { tip });
// ↑ No resourceBounds passed — starknet.js auto-estimates internally
```

Key issue: `resourceBounds` was NOT passed to `execute()`, so starknet.js re-estimated internally. The question is: did the internal re-estimation produce much higher bounds than the 0.506 STRK shown by `getTransactionByHash`?

Reproduction TX

TX hash: `0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc`

Signed resource bounds (from `starknet_getTransactionByHash`)

```
l2_gas: max_amount=0xdffea8 (14,679,720) max_price=0x8085c3900 (34.5 gwei) → max 0.506 STRK
l1_data_gas: max_amount=0x4b0 (1,200) max_price=0x5079c49f0 → max 0.000026 STRK
l1_gas: max_amount=0x0
tip: 0xb5e620f48000 = 0.0002 STRK

TOTAL MAX POSSIBLE FEE: 0.506676 STRK
```

Actual fee (from `starknet_getTransactionReceipt`)

```
actual_fee: 0x640f31aa1835efe060 = 1,845.769251 STRK (unit: FRI)
Ratio: 3,644x the resource bounds
```

Execution resources consumed

```
l2_gas: 9,227,785 units
l1_data_gas: 800 units
Expected fee at block gas prices: 0.212 STRK
```

On-chain balance verification

```
Block 7654709 (before): 10,233.995 STRK
Block 7654710 (after): 8,378.226 STRK
Change: -1,855.769 STRK (= 10 STRK swap + 1,845.77 fee)
```

The last Transfer event in the receipt confirms 1,845.77 STRK sent from account to sequencer address `0x1176a1bd84...`.

All affected transactions

#	TX Hash	Block	Fee (STRK)	Bounds Max	Ratio
1	`0x3b8da6...`	7654710	1,845.77	0.506	3,644x
2	`0x20db3c...`	7654718	1,893.77	~0.5	~3,738x
3	`0x32d6f7...`	7654725	1,893.77	~0.5	~3,738x
4	`0x5bfcc4...`	7654802	1,893.77	~0.5	~3,738x
5	`0x16693a...`	7654811	2,240.04	~0.5	~4,420x
6	`0x1368a2...`	7654885	2,240.04	~0.5	~4,420x
7	`0x564530...`	7654893	2,240.04	~0.5	~4,420x
8	`0x3b6b33...`	7654901	1,270.61	~0.5	~2,508x
Total			15,517.81

A normal transfer TX in the same session (`0xd75f2a...`, block 7654775) had a fee of 0.028 STRK — consistent with resource bounds.

Questions

1. Are the `resource_bounds` returned by `starknet_getTransactionByHash` guaranteed to match the values actually signed? Or could starknet.js be encoding them differently than the RPC reports? I see there was a prior fix "utilize provided resourceBounds value" (commit 65bea53) — could a similar issue affect auto-estimated bounds in v8.9.2?

2. When `execute()` is called without `resourceBounds`, how are the internal bounds computed? Is it possible the auto-estimation produces bounds much larger than what `getTransactionByHash` returns?

3. Does the 50% `feeMarginPercentage` overhead apply to the auto-estimated bounds? Even with 2.25x overhead, 0.506 STRK × 2.25 = 1.14 STRK — still far from 1,845 STRK.

4. Could this be a Starknet sequencer issue rather than a starknet.js issue? Should this be reported to starkware-libs/sequencer instead?

Workaround applied

Passing the `resourceBounds` from `estimateInvokeFee()` explicitly to `execute()`:

```typescript
const feeEstimate = await account.estimateInvokeFee(swapCalls);
const result = await account.execute(swapCalls, {
tip,
...(feeEstimate.resourceBounds ? { resourceBounds: feeEstimate.resourceBounds } : {}),
});
```

This prevents the double-estimation and ensures the bounds validated by the gas check are the same ones used in the transaction.

[tabaktoni]

Hello, I will investigate this (But I need to get some time to dig into the details here)
What probably happened here is that the auto-estimate runs at the moment of execution and could have some on-chain spikes based on what you said.
You mentioned Avnu. Are you using Paymaster?

1. Yes
2. It internaly call account.estimateInvokeFee(data) at the moment of execution.
3. Yes, the fee margin is auto-applied if the user does not provide resource bounds.
4. You would need to check the tx trace in blocks, and you can also call estimate on the history block to reproduce what happened.

I'm sorry for your loss. These numbers seem insane to be charged 3644x the regular fee, so yes i think you should also elevate this.
Also i would recommend you to switch to v10 when released or v9 for now, as I maintain only the latest major version.

[ttendoscopie-creator]

Thanks @tabaktoni for looking into this.

To answer your question: yes, AVNU SDK is involved. The swaps were executed via @avnu/avnu-sdk (quoteToCalls → account.execute), which internally uses the paymaster.

As described in the original report, resourceBounds was NOT passed to execute() at the time of the incident — starknet.js re-estimated internally. The workaround (passing explicit resourceBounds from our own estimateInvokeFee) was applied immediately after.

However, this raises a deeper concern: even the "workaround" is not safe if estimateInvokeFee itself returns inflated bounds during a spike. The bot trusts the estimate, signs with those bounds, and the sequencer is authorized to charge up to them.

Since the incident, I've added a hard cap on resourceBounds: max_amount × max_price_per_unit is now capped to a configurable absolute maximum per resource category. Any TX whose estimate exceeds this is rejected before submission. This is a workaround — the root cause should be fixed in starknet.js or the sequencer.

Request: can you or the StarkWare sequencer team reproduce this?

• Primary TX: 0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc (block 7654710)
• 8 affected TXs total, blocks 7654710–7654901 (2026-03-12)
• Call estimateInvokeFee on the historical block where each TX was included
• Compare the estimate with the actual_fee charged (1,845 STRK vs 0.506 STRK bounds)
• Check if the resourceBounds in the signed TX match what getTransactionByHash reports, or if something modified them between signing and inclusion

This data would tell us exactly where the 3644x multiplier comes from: estimation bug, serialization bug, or sequencer overcharge.

Regarding reimbursement

If this turns out to be a sequencer bug — charging beyond the authorized resource_bounds that were signed and proven on-chain — we expect a refund of the overcharged amount (15,518 STRK). The Starknet fee docs explicitly state that "the ZK proof enforces that the sequencer cannot charge more than max_amount × max_price_per_unit". If that enforcement failed, this is a protocol-level bug, not user error.

If the root cause is in starknet.js (internal re-estimation producing insane bounds), the fix should ensure estimateInvokeFee never returns bounds that deviate more than a reasonable margin (e.g., 2-3x) from actual network conditions, and the reimbursement question should be escalated to StarkWare.

Re: v9/v10 migration

Planned, but this bug affects any version that relies on estimateInvokeFee returning sane values. A hard cap mechanism (either in the SDK or as a user-configurable maxFee parameter in execute()) would be the proper fix regardless of version.

[ttendoscopie-creator]

Hi @tabaktoni — following up on this. Any progress on the investigation?

To summarize what's needed:

1. Reproduce: call estimateInvokeFee on block 7654710 for TX 0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc and compare with the actual_fee charged
2. Root cause: determine if the 3644x fee multiplier came from the estimation, serialization, or the sequencer itself
3. Reimbursement path: if this is a sequencer or SDK bug, who handles the 15,518 STRK refund — StarkWare or the SDK team?

The hard cap workaround is in place on our side, but other users of starknet.js + AVNU are exposed to the same risk until this is fixed.

Happy to provide any additional data or traces. Thanks!

[PhilippeR26]

Hello,
As you already wrote, if you use :

const txH="0x3b8da656f920607a8b529f204e15037c877c74c727defc93890fdab292695bc";
const tx = await myProvider.getTransactionByHash(txH);

you will see what has been calculated and sent by starknet.js to the node:

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' }
  },
tip: '0xb5e620f48000'

• Tip is conform to your code (0.0002 STRK)
• resource Bounds automatically estimated and sent by account.execute() was (as you already calculated) 0.5064762630234432 STRK. Without user customization of margins ( https://starknetjs.com/docs/next/guides/configuration#config ), the default 50% margin was added to all estimated resource bounds values. Compared with the resource really consumed (0.212 STRK), the ressourceBounds calculated & sent by Account.execute() are fully legit.

What is interesting is to analyze the events of this transaction, in particular the last one:

{
    data: [
      '0x7dfa610d64cff230d00e1c64dc648465bfcf4c74b4c5e0541613af0873869f5',
      '0x1176a1bd84444c89232ec27754698e5d2e7e1a7f1539f12027f28b23ec9f3d8',
      '0x640f31aa1835efe060',
      '0x0'
    ],
    from_address: '0x4718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d',
    keys: [
      '0x99cd8bde557814842a3121e8ddfd433a539b8c9f14bf31ebf108d12e6196e9'
    ]
  }

It means :
The STRK contract (0x4718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d) has sent (0x99cd8bde557814842a3121e8ddfd433a539b8c9f14bf31ebf108d12e6196e9) 1845.769250576343752800 STRK ('0x640f31aa1835efe060', '0x0') from your Braavos account to the address 0x1176a1bd84444c89232ec27754698e5d2e7e1a7f1539f12027f28b23ec9f3d8 .
This is the address of the sequencer.

So, in summary, 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...

[ttendoscopie-creator]

Following @PhilippeR26's analysis confirming that starknet.js behaved correctly and the overcharge originated on the blockchain side, I've escalated this to the sequencer team:

starkware-libs/sequencer#13545 — Bug: actual_fee exceeds signed resource_bounds by 3644x — 15,518 STRK overcharged

The issue includes all evidence, reproduction steps, and the refund request. Thank you @PhilippeR26 and @tabaktoni for the thorough investigation.

[ttendoscopie-creator]

@PhilippeR26 — Thank you again for the detailed analysis. Your conclusion that starknet.js was legit and the overcharge came from the blockchain side was key to moving this forward.

I've opened a formal bug report on the sequencer repo: starkware-libs/sequencer#13545

Given your position as a starknet.js collaborator and your direct analysis of this incident, would you be able to forward or escalate this to the StarkWare team? Your technical credibility on this would carry significant weight — especially the finding that the signed resource_bounds (0.506 STRK) were violated by a 1,845 STRK charge, which should be impossible per the fee protocol documentation.

The sequencer issue contains all evidence, reproduction steps, and the refund request for the 15,518 STRK overcharge.

Thank you for your help on this.

[tabaktoni]

How did you set the tip in your example? from where?
const result = await account.execute(swapCalls, { tip });

It looks like the fee came from the tip*l2_gass , and tip is not resource-bounded

[ttendoscopie-creator]

@tabaktoni — Great catch, let me investigate the tip.

Where the tip comes from

The tip was set in our bot code:

const tip = 200_000_000_000_000n; // 0.0002 STRK — intended as a small priority boost
const result = await account.execute(swapCalls, { tip });

This was copied from AVNU documentation examples. The intent was a flat 0.0002 STRK priority fee, not a per-unit multiplier.

The math confirms your hypothesis

tip             = 0xb5e620f48000 = 200,000,000,000,000 FRI
l2_gas consumed = ~9,200,000 units (from actual execution)
tip × l2_gas    = 200,000,000,000,000 × 9,200,000 = 1.84 × 10^21 FRI ≈ 1,840 STRK

This matches the 1,845 STRK charged almost exactly. The tip was applied per unit of gas, not as a flat amount.

The problem

1. The tip parameter in starknet.js execute() is interpreted as per-unit-of-gas, but this is not obvious from the API. A user passing tip: 200_000_000_000_000n expects to pay 0.0002 STRK total, not 0.0002 STRK × millions of gas units.

2. There is no safety check. starknet.js computes resource_bounds with a 50% margin (0.506 STRK total), but the tip is not bounded by anything. The total fee (resource_bounds + tip × gas) can exceed the resource_bounds by orders of magnitude without warning.

3. The signed resource_bounds (0.506 STRK) were supposed to be the maximum the sequencer could charge. The tip effectively bypasses this cap.

Suggested fix for starknet.js

At minimum, account.execute() should:

• Warn or reject if tip × estimated_gas > resource_bounds_total (i.e., if the tip alone exceeds what the user authorized as max fee)
• Document clearly that tip is per-unit, not flat — the current API gives no indication
• Consider adding a maxTip or tipBudget parameter that caps the total tip amount

Regarding the 15,518 STRK

The root cause is now clearer: it's not a sequencer bug, it's an SDK UX issue — the tip parameter silently allows unbounded fees. However:

• The user (me) had no way to know that tip: 0.0002 STRK would result in a 1,845 STRK charge
• starknet.js computed resource_bounds of 0.506 STRK, giving the impression that this was the max fee
• 8 transactions were affected before I noticed (total: 15,518 STRK)

Is there any mechanism (StarkWare, AVNU, or ecosystem fund) to recover fees charged due to SDK misuse that the SDK should have prevented? I understand this may not qualify as a "sequencer bug" anymore, but it's still a design flaw that cost a user $3,100.

I've removed the tip from our bot and added a hard cap on total fees. But other users passing tip to execute() are exposed to the same risk right now.

Thank you both @tabaktoni and @PhilippeR26 for the investigation. The tip hypothesis explains the numbers perfectly.

[tabaktoni]

Default tip behavior:
If no tip is explicitly set, starknet.js calculates the median tip from the last 6 blocks (configurable). This ensures transactions pay a minimal tip while still getting included. Multiple tip strategies are also available for users who need more control.

Preventing mistakes like this:
This is valid feedback and something I want to address. Rejecting the transaction outright isn't an option — it would break behavior under network load — but we can add warnings when a tip value results in a disproportionate increase to the overall resource bounds (e.g. a 2× multiplier). I'll also review the docs to make sure the tipping behavior is clearly documented with explicit warnings.

On fee recovery:
I genuinely understand the frustration here, and losing $3,100 is significant. That said, I can't agree that the SDK bears responsibility for this. starknet.js is a low-level tool that gives developers direct access to network primitives — it's intentionally unopinionated about transaction parameters. If SDKs were held liable for developer misconfiguration, no open-source SDK ecosystem could survive. This is also a free, community-built tool maintained without any commercial backing.

For compensation, your best path is to reach out to the Starknet Foundation directly — they may be better positioned to evaluate ecosystem-level situations like this.

That said, I do want to use this as a signal to improve the developer experience around tipping. I'll track that as a follow-up.