Problem
data/txApi.js:695 (in sendOsmosisIbcTokenToMantle):
```js
const amountInDenom = toChainDenom(amount);
```
Every other tx builder in this file passes the chain explicitly — for example data/txApi.js:53:
```js
const amountInDenom = toChainDenom(amount, chainName, chainDenom);
```
The osmosis-IBC variant falls through to the defaults (defaultChainName = "assetmantle", defaultChainDenom = "umntl"). It works today by coincidence — IBC-MNTL on Osmosis (`ibc/CBA34207...FDDE623813FFC`) and native umntl both have exponent 6, so BigNumber(amount).shiftedBy(6) returns the right number either way.
But if:
- the IBC denom on Osmosis is ever re-issued under a different exponent, or
defaultChainDenom exponent changes (chain registry update), or- this builder is reused for a different token,
the builder would silently send the wrong amount. Bridge tx amount errors are not recoverable — funds may end up at a non-existent denom or be trapped on the destination chain.
Proposed fix
Pass the actual osmosis chain context, the same way the sendIbcTokenToMantle and sendGravityIbcTokenToMantle builders do:
```js
const amountInDenom = toChainDenom(amount, osmosisChainName, osmosisIBCToken);
```
Add a unit test that calls the builder with amount = "1.5" and asserts amountInDenom === "1500000" so any future denom/exponent drift fails loud.
Where to look
data/txApi.js:678-720 — sendOsmosisIbcTokenToMantle- Compare to
data/txApi.js:608-660 — sendGravityIbcTokenToMantle (gets the args right)
Why now
Behaviorally fine today; latent footgun. Two-line fix + a test. Ships safely on its own; doesn't need a major dep upgrade or UI work.
Acceptance
Background: surfaced during the self-audit pass behind #198.
Problem
data/txApi.js:695(insendOsmosisIbcTokenToMantle):```js
const amountInDenom = toChainDenom(amount);
```
Every other tx builder in this file passes the chain explicitly — for example
data/txApi.js:53:```js
const amountInDenom = toChainDenom(amount, chainName, chainDenom);
```
The osmosis-IBC variant falls through to the defaults (
defaultChainName = "assetmantle",defaultChainDenom = "umntl"). It works today by coincidence — IBC-MNTL on Osmosis (`ibc/CBA34207...FDDE623813FFC`) and native umntl both have exponent 6, soBigNumber(amount).shiftedBy(6)returns the right number either way.But if:
defaultChainDenomexponent changes (chain registry update), orthe builder would silently send the wrong amount. Bridge tx amount errors are not recoverable — funds may end up at a non-existent denom or be trapped on the destination chain.
Proposed fix
Pass the actual osmosis chain context, the same way the
sendIbcTokenToMantleandsendGravityIbcTokenToMantlebuilders do:```js
const amountInDenom = toChainDenom(amount, osmosisChainName, osmosisIBCToken);
```
Add a unit test that calls the builder with
amount = "1.5"and assertsamountInDenom === "1500000"so any future denom/exponent drift fails loud.Where to look
data/txApi.js:678-720—sendOsmosisIbcTokenToMantledata/txApi.js:608-660—sendGravityIbcTokenToMantle(gets the args right)Why now
Behaviorally fine today; latent footgun. Two-line fix + a test. Ships safely on its own; doesn't need a major dep upgrade or UI work.
Acceptance
toChainDenom(amount, osmosisChainName, osmosisIBCToken)insendOsmosisIbcTokenToMantledata/__tests__/txApi.test.jsverifying the conversionBackground: surfaced during the self-audit pass behind #198.