code/cl8y-dex-terraclassic

Fork 0

Ladder escrow amount produces oversized Uint128 — `increase_allowance` fails with "number too large to fit in target type" #233

New issue

Closed

opened 2026-05-29 15:06:55 +00:00 by totdking · 7 comments

totdking commented

2026-05-29 15:06:55 +00:00

(Migrated from gitlab.com)

No description provided.

totdking commented

2026-05-29 15:08:47 +00:00

(Migrated from gitlab.com)

Issue Summary

When placing a ladder order, the CW20 increase_allowance call is sent with an escrow amount value that is too large to fit in a Uint128. The error string (02000000020000000200000002000000020000000) is 41 digits long — far exceeding the Uint128 maximum of 39 digits (340282366920938463463374607431768211455). The value appears to be the per-rung escrow amounts (20000000 each) concatenated as strings rather than summed as integers, producing a nonsensical composite number.

Reproduction Steps

Complete full local setup (LocalTerra running, contracts deployed, indexer running, frontend running)
Connect a Keplr wallet with sufficient LUNC and CORAL balance
Navigate to /trade, select EMBER/CORAL, and click the LADDER tab
Set: Start price 0.95, End price 1.05, Rung count 5, Total escrow 100 CORAL
Confirm the Advanced preview shows 5 rungs each with 20000000 raw escrow
Click Place 5-rung ladder and approve the transaction in Keplr
Observe: transaction fails — wallet or broadcast layer rejects the malformed amount

Expected Behavior

The increase_allowance amount should equal the total raw escrow across all rungs summed as an integer — for 5 rungs of 20000000 each, the correct value is 100000000. The value should be a valid Uint128 integer string.

Actual Behavior

The amount sent in increase_allowance is 02000000020000000200000002000000020000000 — 41 characters, consistent with the 5 per-rung amounts (20000000) concatenated as strings rather than added as integers. The transaction is rejected with:

Transaction failed: failed to execute message; message index: 0:
Error parsing into type cw20_mintable::msg::ExecuteMsg:
invalid Uint128 '02000000020000000200000002000000020000000'
- number too large to fit in target type: execute wasm contract failed

Console Logs

error: Error: Transaction failed: failed to execute message; message index: 0:
Error parsing into type cw20_mintable::msg::ExecuteMsg:
invalid Uint128 '02000000020000000200000002000000020000000'
- number too large to fit in target type: execute wasm contract failed
    at broadcastTerraExecuteContracts (terraBroadcast.ts:117:13)
    at async executeCw20AllowanceThen (transactions.ts:129:3)

Root Cause (suspected)

The rung escrow amounts are being aggregated using string concatenation (e.g. Array.join('') or += on a string variable) rather than numeric addition (reduce((sum, n) => sum + n, BigInt(0))). The leading 0 prefix and the 5 repetitions of 20000000 in the resulting string match this pattern exactly. The fix is to ensure the total allowance amount is computed as a numeric sum before serialisation to a Uint128 string.

Likely location: ladder escrow aggregation in LimitOrderLadderPanel.tsx or the batch placement utility in pair.ts.

Environment Details

Field	Value
OS	macOS (Apple M1 Pro, 14-inch)
Browser	Google Chrome (desktop)
Viewport	~1440px desktop
Network	`localterra` (local Docker)
Frontend	`VITE_NETWORK=local npm run dev`
Indexer	Running (`make indexer-dev`)
Contracts	Deployed via `make deploy-local`

Wallet / Device Details

Wallet: Keplr browser extension
Network configured in Keplr: localterra — RPC http://localhost:26657
Pair tested: EMBER / CORAL
Ladder config: 5 rungs, 0.95–1.05, 100 CORAL total escrow (20000000 raw per rung)

Severity / Impact

High — blocks all ladder placements independently of issue https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/232 . Even if the place_limit_order_batch variant were supported by the contract, the malformed Uint128 in increase_allowance causes the sequence to fail before the batch message is ever reached. Both bugs combine to make the ladder feature entirely non-functional. The fix is low-effort: change the allowance amount aggregation from string concatenation to integer summation. Was discovered during verification of https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/231 .

cc: @PlasticDigits

### Issue Summary When placing a ladder order, the CW20 `increase_allowance` call is sent with an escrow `amount` value that is too large to fit in a Uint128. The error string (`02000000020000000200000002000000020000000`) is 41 digits long — far exceeding the Uint128 maximum of 39 digits (340282366920938463463374607431768211455). The value appears to be the per-rung escrow amounts (`20000000` each) concatenated as strings rather than summed as integers, producing a nonsensical composite number. --- ### Reproduction Steps 1. Complete full local setup (LocalTerra running, contracts deployed, indexer running, frontend running) 2. Connect a Keplr wallet with sufficient LUNC and CORAL balance 3. Navigate to `/trade`, select EMBER/CORAL, and click the **LADDER** tab 4. Set: Start price `0.95`, End price `1.05`, Rung count `5`, Total escrow `100` CORAL 5. Confirm the Advanced preview shows 5 rungs each with `20000000` raw escrow 6. Click **Place 5-rung ladder** and approve the transaction in Keplr 7. Observe: transaction fails — wallet or broadcast layer rejects the malformed amount --- ### Expected Behavior The `increase_allowance` amount should equal the total raw escrow across all rungs summed as an integer — for 5 rungs of `20000000` each, the correct value is `100000000`. The value should be a valid Uint128 integer string. --- ### Actual Behavior The amount sent in `increase_allowance` is `02000000020000000200000002000000020000000` — 41 characters, consistent with the 5 per-rung amounts (`20000000`) concatenated as strings rather than added as integers. The transaction is rejected with: ``` Transaction failed: failed to execute message; message index: 0: Error parsing into type cw20_mintable::msg::ExecuteMsg: invalid Uint128 '02000000020000000200000002000000020000000' - number too large to fit in target type: execute wasm contract failed ``` --- ### Console Logs ``` error: Error: Transaction failed: failed to execute message; message index: 0: Error parsing into type cw20_mintable::msg::ExecuteMsg: invalid Uint128 '02000000020000000200000002000000020000000' - number too large to fit in target type: execute wasm contract failed at broadcastTerraExecuteContracts (terraBroadcast.ts:117:13) at async executeCw20AllowanceThen (transactions.ts:129:3) ``` --- ### Root Cause (suspected) The rung escrow amounts are being aggregated using string concatenation (e.g. `Array.join('')` or `+=` on a string variable) rather than numeric addition (`reduce((sum, n) => sum + n, BigInt(0))`). The leading `0` prefix and the 5 repetitions of `20000000` in the resulting string match this pattern exactly. The fix is to ensure the total allowance amount is computed as a numeric sum before serialisation to a Uint128 string. Likely location: ladder escrow aggregation in `LimitOrderLadderPanel.tsx` or the batch placement utility in `pair.ts`. --- ### Environment Details | Field | Value | |-------|-------| | OS | macOS (Apple M1 Pro, 14-inch) | | Browser | Google Chrome (desktop) | | Viewport | \~1440px desktop | | Network | `localterra` (local Docker) | | Frontend | `VITE_NETWORK=local npm run dev` | | Indexer | Running (`make indexer-dev`) | | Contracts | Deployed via `make deploy-local` | --- ### Wallet / Device Details - **Wallet:** Keplr browser extension - **Network configured in Keplr:** localterra — RPC `http://localhost:26657` - **Pair tested:** EMBER / CORAL - **Ladder config:** 5 rungs, 0.95–1.05, 100 CORAL total escrow (20000000 raw per rung) --- ### Severity / Impact **High — blocks all ladder placements independently of issue** https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/232 **.** Even if the `place_limit_order_batch` variant were supported by the contract, the malformed Uint128 in `increase_allowance` causes the sequence to fail before the batch message is ever reached. Both bugs combine to make the ladder feature entirely non-functional. The fix is low-effort: change the allowance amount aggregation from string concatenation to integer summation. Was discovered during verification of https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/231 . cc: @PlasticDigits

PlasticDigits commented

2026-05-29 15:22:17 +00:00

(Migrated from gitlab.com)

mentioned in commit 9f46fec22c

mentioned in commit 9f46fec22c6b046a0285e4c389e970d9efd7303a

PlasticDigits commented

2026-05-29 15:23:08 +00:00

(Migrated from gitlab.com)

Fix landed on `main` (`9f46fec`)

Root cause: sumLadderAmountsRaw in limitOrderLadder.ts used reduce with a string accumulator ('0'), so each step did string concatenation instead of BigInt addition. Five rungs of 20000000 became 02000000020000000200000002000000020000000, which fails CW20 increase_allowance Uint128 parsing.

Code fix: Already on main in 515fba3 — accumulator is now 0n and the reduce adds BigInt values; final .toString() once at the end.

This follow-up commit (9f46fec): Regression test (5 × 20000000 → 100000000, explicit anti-concat assertion), JSDoc on sumLadderAmountsRaw, and docs/skill crosslinks (#233).

Automated verification (agent)

npm test -- limitOrderLadder (includes #233 regression case)
Playwright place 5-rung ladder in one tx (batch hook) — allowance + ladder tx succeeds; LCD shows place_limit_order_batch / place_limit_order wasm actions

Manual verification checklist (@totdking)

Please confirm on localterra with indexer + contracts deployed:

/limits → select pair (e.g. EMBER/CORAL) → Ladder tab (wallet connected)
Start 0.95, End 1.05, rungs 5, total escrow 100 CORAL — preview shows five rows with 20000000 raw each
Place ladder — first tx (increase_allowance) amount is 100000000 (not a 41-digit concat string)
Second tx succeeds; indexer shows 5 new resting limits
No invalid Uint128 / number too large to fit in target type in wallet or broadcast error

Docs: docs/limit-orders.md (ladder escrow aggregation invariant), skills/AGENTS_LIMIT_ORDER_BATCH_LADDER.md invariant §3.

Leaving issue open for your sign-off.

/cc @totdking

## Fix landed on `main` (9f46fec) **Root cause:** `sumLadderAmountsRaw` in [`limitOrderLadder.ts`](frontend-dapp/src/utils/limitOrderLadder.ts) used `reduce` with a string accumulator (`'0'`), so each step did string concatenation instead of `BigInt` addition. Five rungs of `20000000` became `02000000020000000200000002000000020000000`, which fails CW20 `increase_allowance` Uint128 parsing. **Code fix:** Already on `main` in `515fba3` — accumulator is now `0n` and the reduce adds `BigInt` values; final `.toString()` once at the end. **This follow-up commit (`9f46fec`):** Regression test (5 × `20000000` → `100000000`, explicit anti-concat assertion), JSDoc on `sumLadderAmountsRaw`, and docs/skill crosslinks ([#233](https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/issues/233)). ### Automated verification (agent) - [x] `npm test -- limitOrderLadder` (includes #233 regression case) - [x] Playwright `place 5-rung ladder in one tx (batch hook)` — allowance + ladder tx succeeds; LCD shows `place_limit_order_batch` / `place_limit_order` wasm actions ### Manual verification checklist (@totdking) Please confirm on **localterra** with indexer + contracts deployed: - [ ] `/limits` → select pair (e.g. EMBER/CORAL) → **Ladder** tab (wallet connected) - [ ] Start `0.95`, End `1.05`, rungs `5`, total escrow `100` CORAL — preview shows **five** rows with `20000000` raw each - [ ] Place ladder — **first** tx (`increase_allowance`) amount is **`100000000`** (not a 41-digit concat string) - [ ] Second tx succeeds; indexer shows **5** new resting limits - [ ] No `invalid Uint128` / `number too large to fit in target type` in wallet or broadcast error **Docs:** [`docs/limit-orders.md`](docs/limit-orders.md) (ladder escrow aggregation invariant), [`skills/AGENTS_LIMIT_ORDER_BATCH_LADDER.md`](skills/AGENTS_LIMIT_ORDER_BATCH_LADDER.md) invariant §3. Leaving issue **open** for your sign-off. /cc @totdking

PlasticDigits commented

2026-05-30 09:14:32 +00:00

(Migrated from gitlab.com)

Manual qa not requried, agent can conduct all 5 verifications

PlasticDigits commented

2026-05-30 12:38:01 +00:00

(Migrated from gitlab.com)

Verification complete (agent, worktree `verify/issue-233`)

Verified fix commits 515fba3 (BigInt sum) and 9f46fec (regression test + docs/skill crosslinks) on localterra with indexer + deployed contracts. No code changes required — fix already on main.

Automated checks

npm test -- limitOrderLadder — 2/2 pass, including GitLab #233 regression (5 × 20000000 → 100000000, anti-concat assertion)
Playwright place 5-rung ladder in one tx (batch hook) (e2e/limit-orders-tx.spec.ts, e2e-tx project) — passed (~28s)

On-chain / indexer checks (issue checklist)

Ladder preview math: expandLimitLadder with start 0.95, end 1.05, 5 rungs, total 100000000 raw → five rows of 20000000 each (Vitest + E2E fill 100 human @ 6 decimals)
increase_allowance amount = 100000000 — LCD (docker exec fallback) shows most recent ladder allowance tx from dev wallet with amount 100000000, not the 41-digit concat string
Ladder send tx amount = 100000000; wasm actions include place_limit_order_batch and place_limit_order (E2E LCD poll)
Indexer /api/v1/pairs/{pair}/limit-placements — 5 new active bid limits (orders 5–9, prices 0.95–1.05) from tx 7F2BC8… at block 10763
No invalid Uint128 / number too large to fit in target type errors

Docs / invariants (already on main)

docs/limit-orders.md — ladder escrow aggregation invariant (#233)
skills/AGENTS_LIMIT_ORDER_BATCH_LADDER.md — invariant §3 + regression test command

Manual re-check (optional)

/limits → dual-CW20 pair → Ladder tab
Start 0.95, End 1.05, rungs 5, total escrow 100 (6-decimal token)
Preview: 5 rows × 20000000 raw
Place ladder → allowance tx amount 100000000, placement tx succeeds
Indexer shows 5 new resting limits

Closing — all issue criteria and comment checklist items pass.

## Verification complete (agent, worktree `verify/issue-233`) Verified fix commits `515fba3` (BigInt sum) and `9f46fec` (regression test + docs/skill crosslinks) on **localterra** with indexer + deployed contracts. No code changes required — fix already on `main`. ### Automated checks - [x] `npm test -- limitOrderLadder` — 2/2 pass, including **GitLab #233** regression (`5 × 20000000` → `100000000`, anti-concat assertion) - [x] Playwright `place 5-rung ladder in one tx (batch hook)` (`e2e/limit-orders-tx.spec.ts`, `e2e-tx` project) — **passed** (~28s) ### On-chain / indexer checks (issue checklist) - [x] Ladder preview math: `expandLimitLadder` with start `0.95`, end `1.05`, 5 rungs, total `100000000` raw → five rows of `20000000` each (Vitest + E2E fill `100` human @ 6 decimals) - [x] **`increase_allowance` amount = `100000000`** — LCD (docker exec fallback) shows most recent ladder allowance tx from dev wallet with amount `100000000`, **not** the 41-digit concat string - [x] Ladder **send** tx amount = `100000000`; wasm actions include `place_limit_order_batch` and `place_limit_order` (E2E LCD poll) - [x] Indexer `/api/v1/pairs/{pair}/limit-placements` — **5** new active bid limits (orders 5–9, prices `0.95`–`1.05`) from tx `7F2BC8…` at block 10763 - [x] No `invalid Uint128` / `number too large to fit in target type` errors ### Docs / invariants (already on main) - [`docs/limit-orders.md`](docs/limit-orders.md) — ladder escrow aggregation invariant ([#233](https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/issues/233)) - [`skills/AGENTS_LIMIT_ORDER_BATCH_LADDER.md`](skills/AGENTS_LIMIT_ORDER_BATCH_LADDER.md) — invariant §3 + regression test command ### Manual re-check (optional) 1. `/limits` → dual-CW20 pair → **Ladder** tab 2. Start `0.95`, End `1.05`, rungs `5`, total escrow `100` (6-decimal token) 3. Preview: 5 rows × `20000000` raw 4. Place ladder → allowance tx amount `100000000`, placement tx succeeds 5. Indexer shows 5 new resting limits Closing — all issue criteria and comment checklist items pass.

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-05-30 12:38:04 +00:00

PlasticDigits commented

2026-06-01 04:19:02 +00:00

(Migrated from gitlab.com)

mentioned in issue #268