Bug: Rate limit blocks withdrawExecute after fee deduction reduces amount below minimum

Brouie commented

2026-04-08 07:31:52 +00:00

(Migrated from gitlab.com)

Mainnet v0.1.82 (179afcb)

Current behavior: opBNB->BSC (nonce 3, hash 0x0ce3c003...) and BSC->opBNB (nonce 30, hash 0xb952b402...) both stuck at Approved. Operator cannot execute withdrawExecuteMint because the post-fee amount falls below the deposit rate limit minimum. Transfers are approved but permanently stuck.

Expected behavior: Operator should be able to execute approved transfers. Rate limit checks should account for fee deduction, or the frontend should prevent deposits that will result in post-fee amounts below the withdrawal minimum.

Design choices needed:

Should rate limit check use pre-fee or post-fee amount?
Should frontend warn/block deposits that will be stuck after fee deduction?
Should operator have a bypass for approved transfers already past cancel window?

Affected transfers:

opBNB->BSC nonce 3: 0x0ce3c0034257e90811f655513cbb0e680b8d0e76364f986816190a5d2c08c5df
BSC->opBNB nonce 30: 0xb952b402c54e9e7da873767183b2a1afa18d920f10bfa4f43ec1e9bbff1bb84b

Context: opBNB test token rate limits are very small (~0.005 testa) due to default 0.0001% of supply. Deposit succeeded with small amount but withdrawal execution is blocked by the same rate limit after fee deduction.

**Mainnet v0.1.82 (179afcb)** **Current behavior:** opBNB->BSC (nonce 3, hash 0x0ce3c003...) and BSC->opBNB (nonce 30, hash 0xb952b402...) both stuck at Approved. Operator cannot execute withdrawExecuteMint because the post-fee amount falls below the deposit rate limit minimum. Transfers are approved but permanently stuck. **Expected behavior:** Operator should be able to execute approved transfers. Rate limit checks should account for fee deduction, or the frontend should prevent deposits that will result in post-fee amounts below the withdrawal minimum. **Design choices needed:** - Should rate limit check use pre-fee or post-fee amount? - Should frontend warn/block deposits that will be stuck after fee deduction? - Should operator have a bypass for approved transfers already past cancel window? **Affected transfers:** - opBNB->BSC nonce 3: 0x0ce3c0034257e90811f655513cbb0e680b8d0e76364f986816190a5d2c08c5df - BSC->opBNB nonce 30: 0xb952b402c54e9e7da873767183b2a1afa18d920f10bfa4f43ec1e9bbff1bb84b **Context:** opBNB test token rate limits are very small (~0.005 testa) due to default 0.0001% of supply. Deposit succeeded with small amount but withdrawal execution is blocked by the same rate limit after fee deduction.

PlasticDigits commented

2026-04-09 02:52:34 +00:00

(Migrated from gitlab.com)

mentioned in commit b9c6d54e0b

mentioned in commit b9c6d54e0b24a87fffdb697079db43dd7a29f7f8

PlasticDigits commented

2026-04-09 02:52:43 +00:00

(Migrated from gitlab.com)

Frontend change pushed to main (b9c6d54) to mitigate deposits that pass the old gross-only minimum but fail withdraw execution after the bridge fee: we now validate against post-fee net vs the destination minimum, show the minimum send (gross) in the MIN label, and added a MIN preset that sets gross so net clears min + 1 base unit after fees.

This does not change contracts or unblock already-stuck transfers; it reduces new stuck "Approved" cases from small amounts + tight rate-limit mins.

@brouie Could you QA on a route with a small minTransfer (e.g. test token) and confirm MIN + submit behave as expected?

/cc @brouie

Frontend change pushed to `main` (`b9c6d54`) to mitigate deposits that pass the old gross-only minimum but fail withdraw execution after the bridge fee: we now validate against **post-fee** net vs the destination minimum, show the **minimum send** (gross) in the MIN label, and added a **MIN** preset that sets gross so net clears min + 1 base unit after fees. This does not change contracts or unblock already-stuck transfers; it reduces new stuck "Approved" cases from small amounts + tight rate-limit mins. @brouie Could you QA on a route with a small `minTransfer` (e.g. test token) and confirm MIN + submit behave as expected? /cc @brouie

Brouie commented

2026-04-10 04:15:03 +00:00

(Migrated from gitlab.com)

mentioned in issue #105

Brouie commented

2026-04-20 04:05:33 +00:00

(Migrated from gitlab.com)

@PlasticDigits Verified fixed on build v0.1.82 - f227b6f (frontend bundle main-CvcBOh67), 4/20 mainnet.

Test route: opBNB -> BSC, testa (tight rate limit chain)
MIN shown: 0.1005 (gross)
MAX shown: 2.046 (balance 2.046497)

MIN preset

Clicked MIN -> fills 0.100503 gross, YOU WILL RECEIVE shows 0.10 TOKENA-CB net (post 0.5% fee). Math checks out: net clears destination minimum + 1 base unit after fee as designed.

Below-MIN block

Entered 0.05 (below MIN 0.1005) with recipient filled. BRIDGE EVM TO EVM button shows blocked icon overlay and is not clickable. Net shown 0.04975.

MAX preset

Clicked MAX -> fills 2.046497 (full balance), YOU WILL RECEIVE 2.036265 net. Button active and clickable.

All three behaviors work as described in b9c6d54. Closing.

@PlasticDigits Verified fixed on build v0.1.82 - f227b6f (frontend bundle main-CvcBOh67), 4/20 mainnet. **Test route:** opBNB -> BSC, testa (tight rate limit chain) **MIN shown:** 0.1005 (gross) **MAX shown:** 2.046 (balance 2.046497) ## MIN preset Clicked MIN -> fills 0.100503 gross, YOU WILL RECEIVE shows 0.10 TOKENA-CB net (post 0.5% fee). Math checks out: net clears destination minimum + 1 base unit after fee as designed. ## Below-MIN block Entered 0.05 (below MIN 0.1005) with recipient filled. BRIDGE EVM TO EVM button shows blocked icon overlay and is not clickable. Net shown 0.04975. ## MAX preset Clicked MAX -> fills 2.046497 (full balance), YOU WILL RECEIVE 2.036265 net. Button active and clickable. All three behaviors work as described in b9c6d54. Closing.

Brouie (Migrated from gitlab.com) closed this issue

2026-04-20 04:05:41 +00:00

Brouie commented

2026-04-20 04:14:20 +00:00

(Migrated from gitlab.com)

mentioned in issue #108