The AmountInput component in components/atoms/amount-input/index.tsx uses parseInt which truncates decimals:
const handleChange = (event) => {
setAmount(parseInt(event.target.value))
setInput(event.target.value)
}A user entering 10.5 XLM gets amount = 10. But this is part of a larger precision problem through the entire amount pipeline:
-
parseInt truncates at input. The displayed value shows 10.5 but the state used for transactions is 10. Users silently lose fractional amounts on every deposit.
-
There is no stroops conversion anywhere in the frontend. Stellar amounts are in stroops (1 XLM = 10,000,000 stroops). The amount enters as a float, gets truncated to an integer by parseInt, and is sent to the backend as-is. The backend passes it to the Stellar SDK which may interpret it as stroops or as XLM depending on the function, producing either 10 stroops (essentially zero) or 10 XLM.
-
There is no minimum amount validation. A user can enter 0 or negative values. The input has no min attribute and the handleChange has no bounds check.
-
There is no maximum amount validation against the user's wallet balance. The user can attempt to deposit more than they have, which fails on-chain but only after the transaction is built and submitted.
-
The amount type flows as number through the entire frontend. JavaScript floating point means 0.1 + 0.2 !== 0.3. For financial calculations, amounts should be handled as BigInt stroops or as string-formatted decimals, never as floating point numbers.
This is critical for a financial application. The fix requires: using parseFloat (or better, string-based decimal parsing) at input, converting to stroops (BigInt) immediately after parsing, validating minimum and maximum amounts, passing stroops through the entire pipeline, and only converting back to display format at render time.
This touches components/atoms/amount-input/index.tsx, the escrow flow that consumes the amount, and any component that displays amounts.
Before submitting your PR, make sure all checks pass locally and the build succeeds. Each issue will be thoroughly reviewed and only merged if it fully meets the requirements. In your PR, specify the issue number and title. You can optionally provide a screenshot showing the fix working. On the issue, comment tagging the author to let them know you're working on it. On the PR, tag the maintainer to notify that review is ready.
The AmountInput component in components/atoms/amount-input/index.tsx uses parseInt which truncates decimals:
A user entering 10.5 XLM gets amount = 10. But this is part of a larger precision problem through the entire amount pipeline:
parseInt truncates at input. The displayed value shows 10.5 but the state used for transactions is 10. Users silently lose fractional amounts on every deposit.
There is no stroops conversion anywhere in the frontend. Stellar amounts are in stroops (1 XLM = 10,000,000 stroops). The amount enters as a float, gets truncated to an integer by parseInt, and is sent to the backend as-is. The backend passes it to the Stellar SDK which may interpret it as stroops or as XLM depending on the function, producing either 10 stroops (essentially zero) or 10 XLM.
There is no minimum amount validation. A user can enter 0 or negative values. The input has no min attribute and the handleChange has no bounds check.
There is no maximum amount validation against the user's wallet balance. The user can attempt to deposit more than they have, which fails on-chain but only after the transaction is built and submitted.
The amount type flows as number through the entire frontend. JavaScript floating point means 0.1 + 0.2 !== 0.3. For financial calculations, amounts should be handled as BigInt stroops or as string-formatted decimals, never as floating point numbers.
This is critical for a financial application. The fix requires: using parseFloat (or better, string-based decimal parsing) at input, converting to stroops (BigInt) immediately after parsing, validating minimum and maximum amounts, passing stroops through the entire pipeline, and only converting back to display format at render time.
This touches components/atoms/amount-input/index.tsx, the escrow flow that consumes the amount, and any component that displays amounts.
Before submitting your PR, make sure all checks pass locally and the build succeeds. Each issue will be thoroughly reviewed and only merged if it fully meets the requirements. In your PR, specify the issue number and title. You can optionally provide a screenshot showing the fix working. On the issue, comment tagging the author to let them know you're working on it. On the PR, tag the maintainer to notify that review is ready.