code/cl8y-bridge-monorepo

Fork 0

bug: transfer amount mismatch - wallet debits 10 TESTA but bridge processes ~0.03 TESTA #9

New issue

Closed

opened 2026-03-01 15:03:56 +00:00 by PlasticDigits · 3 comments

PlasticDigits commented

2026-03-01 15:03:56 +00:00

(Migrated from gitlab.com)

Frontend Bug Report

Issue Title

bug: transfer amount mismatch - wallet debits 10 TESTA but bridge processes ~0.03 TESTA

Environment

Device Type: Desktop
Device Model: Unknown (QA desktop machine)
OS Version: Linux
Browser Version: Chrome (exact version unknown)
Wallet Used: Terra wallet + MetaMask/EVM destination wallet (exact wallet names not captured)
Network / Chain: Terra Classic (source) -> BNB Chain (destination)
Page: Transfer and Status

Steps to Reproduce

Connect wallets for a Terra Classic -> BNB Chain transfer.
Enter transfer amount 10 TESTA (user expected full 10 to bridge).
Submit and sign the transfer transaction.
Open transfer status/details view after submission.
Compare user-entered amount with amount shown as processed/transferred.

Expected Behavior

The processed/bridged amount should match the submitted amount (10 TESTA), minus only clearly disclosed fees/slippage shown in UI before confirmation.
If any conversion or decimal normalization occurs, the UI should explicitly display it before signing.

Actual Behavior

User reports wallet balance/transaction appears to take the full 10 TESTA.
Transfer/status view appears to process only about 0.03 TESTA (screenshot also shows an unexpectedly reduced amount context, e.g. 9.97 in status card).
This creates a major mismatch between expected transfer amount and displayed processed amount.

Severity

High

Evidence (screenshots / recordings)

See auto-uploaded screenshot below (status/details card for this transfer).

Console Errors (if available)

# Not captured during this run.

Transaction Hash (if applicable)

Not recorded yet (should be added if available from wallet/history page).

Source

Found during manual QA testing
Reported by a user

Auto-uploaded Evidence

photo_2026-03-02_00-02-44-1cc18eae-521a-4917-84a6-b83d67491be3.png

## Frontend Bug Report ### Issue Title - bug: transfer amount mismatch - wallet debits 10 TESTA but bridge processes ~0.03 TESTA ### Environment - Device Type: Desktop - Device Model: Unknown (QA desktop machine) - OS Version: Linux - Browser Version: Chrome (exact version unknown) - Wallet Used: Terra wallet + MetaMask/EVM destination wallet (exact wallet names not captured) - Network / Chain: Terra Classic (source) -> BNB Chain (destination) - Page: Transfer and Status ### Steps to Reproduce 1. Connect wallets for a Terra Classic -> BNB Chain transfer. 2. Enter transfer amount `10 TESTA` (user expected full 10 to bridge). 3. Submit and sign the transfer transaction. 4. Open transfer status/details view after submission. 5. Compare user-entered amount with amount shown as processed/transferred. ### Expected Behavior - The processed/bridged amount should match the submitted amount (10 TESTA), minus only clearly disclosed fees/slippage shown in UI before confirmation. - If any conversion or decimal normalization occurs, the UI should explicitly display it before signing. ### Actual Behavior - User reports wallet balance/transaction appears to take the full `10 TESTA`. - Transfer/status view appears to process only about `0.03 TESTA` (screenshot also shows an unexpectedly reduced amount context, e.g. `9.97` in status card). - This creates a major mismatch between expected transfer amount and displayed processed amount. ### Severity - High ### Evidence (screenshots / recordings) - See auto-uploaded screenshot below (status/details card for this transfer). ### Console Errors (if available) ```shell # Not captured during this run. ``` ### Transaction Hash (if applicable) - Not recorded yet (should be added if available from wallet/history page). ### Source - [x] Found during manual QA testing - [x] Reported by a user ### Auto-uploaded Evidence - [photo_2026-03-02_00-02-44-1cc18eae-521a-4917-84a6-b83d67491be3.png](https://raw.githubusercontent.com/PlasticDigits/cl8y-qa-evidence/main/2026-03-02/1772377398-photo_2026-03-02_00-02-44-1cc18eae-521a-4917-84a6-b83d67491be3.png) - ![photo_2026-03-02_00-02-44-1cc18eae-521a-4917-84a6-b83d67491be3.png](https://raw.githubusercontent.com/PlasticDigits/cl8y-qa-evidence/main/2026-03-02/1772377398-photo_2026-03-02_00-02-44-1cc18eae-521a-4917-84a6-b83d67491be3.png)

PlasticDigits commented

2026-03-07 01:20:06 +00:00

(Migrated from gitlab.com)

@brouie This issue is a transfer mismatch not a display mismatch

`@brouie` This issue is a transfer mismatch not a display mismatch

PlasticDigits commented

2026-03-09 03:13:00 +00:00

(Migrated from gitlab.com)

@brouie It should be resolved but please verify

`@brouie` It should be resolved but please verify

PlasticDigits commented

2026-03-09 05:36:56 +00:00

(Migrated from gitlab.com)

Fix pushed — `b4f8247` on `main`

Root cause: parseTerraLockReceipt was using the amount from the last wasm event it encountered. For CW20 deposits, a fee transfer event (with amount = the 0.3% fee) appears after the bridge deposit event (with amount = net), overwriting the correct value. This caused the first withdrawal attempt to submit the fee as the transfer amount, which reverted on-chain.

Fix: The parser now tracks which event contains the nonce (the bridge deposit event) and prefers its amount over amounts from other events. Priority: lock_amount > deposit event amount > generic amount.

Tests added:

CW20 deposit where fee transfer event overwrites generic amount (reproduces #9/#29)
Edge case where fee transfer event appears before deposit event

This also resolves #29 — the "HASH NOT FOUND ON DESTINATION" error was caused by the same first-attempt revert.
@brouie Please verify on v0.1.35+ — the first withdrawal attempt should now use the correct amount without needing a retry.

### Fix pushed — `b4f8247` on `main` **Root cause:** `parseTerraLockReceipt` was using the `amount` from the last wasm event it encountered. For CW20 deposits, a fee transfer event (with `amount` = the 0.3% fee) appears after the bridge deposit event (with `amount` = net), overwriting the correct value. This caused the first withdrawal attempt to submit the fee as the transfer amount, which reverted on-chain. **Fix:** The parser now tracks which event contains the `nonce` (the bridge deposit event) and prefers its `amount` over amounts from other events. Priority: `lock_amount` > deposit event amount > generic amount. **Tests added:** - CW20 deposit where fee transfer event overwrites generic amount (reproduces #9/#29) - Edge case where fee transfer event appears before deposit event This also resolves #29 — the "HASH NOT FOUND ON DESTINATION" error was caused by the same first-attempt revert. ` @brouie` Please verify on **v0.1.35+** — the first withdrawal attempt should now use the correct amount without needing a retry.

PlasticDigits referenced this issue

2026-09-12 13:07:44 +00:00

security(evm): reject fee-on-transfer ERC20 deposits that deliver less than recorded #189

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

code/cl8y-bridge-monorepo#9

No description provided.

Rows
Columns

bug: transfer amount mismatch - wallet debits 10 TESTA but bridge processes ~0.03 TESTA #9

Frontend Bug Report

Issue Title

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Severity

Evidence (screenshots / recordings)

Console Errors (if available)

Transaction Hash (if applicable)

Source

Auto-uploaded Evidence

Fix pushed — b4f8247 on main

Fix pushed — `b4f8247` on `main`