Problem
Locale separators, floating-point conversion, and excessive precision can cause users to submit an amount different from what they intended.
Objective
Deliver a production-quality improvement to amount inputs, balances, fees, and share displays that creates measurable value for correctness, security, reliability, performance, or maintainability.
Implementation scope
- Parse input using explicit locale rules and canonical decimal strings rather than binary floating point.
- Show supported precision, minimum units, rounding, and insufficient-balance errors before signing.
- Keep display formatting separate from transaction serialization.
Acceptance criteria
- The serialized amount is deterministic across supported locales.
- Invalid, negative, excessive-precision, and boundary values are rejected clearly.
- Displayed values reconcile with the submitted canonical value.
Required validation
- Locale matrix tests, property tests for round trips, and boundary validation tests.
- Existing tests and CI remain passing.
- Add regression coverage for the original failure mode.
- Do not weaken, delete, or skip unrelated tests to obtain a green build.
PR quality bar
- Keep the PR focused on this issue and explain design tradeoffs.
- Include test evidence, compatibility impact, and migration or rollout notes where relevant.
- Avoid typo-only, documentation-only, cosmetic-only, or unrelated refactor submissions.
Out of scope
- Broad rewrites not required by the acceptance criteria.
- Changes to unrelated services, contracts, or user flows.
Problem
Locale separators, floating-point conversion, and excessive precision can cause users to submit an amount different from what they intended.
Objective
Deliver a production-quality improvement to amount inputs, balances, fees, and share displays that creates measurable value for correctness, security, reliability, performance, or maintainability.
Implementation scope
Acceptance criteria
Required validation
PR quality bar
Out of scope