The amount nobody could send
4 November 2026
A payment request names what must arrive. The payer’s side is solved backwards from that — target divided by rate — and the answer went straight onto the screen:
Please send 1635.7348668259483 USDT TRC-20Tether on Tron has six decimal places. That figure has thirteen. It is not a precise amount, it is an impossible one.
Why it is worse than untidy
No wallet will send it. So the payer sends something close, and the deposit no longer matches the order the provider is waiting for — which is the one thing a deposit has to do. A figure that cannot be entered is not a rounding problem, it is an instruction nobody can follow.
The same arithmetic was producing 0.0031296759715077086 on the Bitcoin side, and the identical fault was in the code that divides a transfer into several legs: a seventh of 1,000 USDT came out as 142.85714286.
Up, never to nearest
The rounding direction is the part worth thinking about. This figure answers “what must you send for X to arrive”. A place lost downwards is a payout that lands short — and a provider settles that by paying less, not by asking.
Rounding up overshoots by at most one unit in the last place, a fraction of a cent, and it lands in the recipient’s favour. Rounding to nearest is tidier and wrong half the time in the direction that costs somebody money.
Rounded before the check, not after
The solver quotes, corrects, and confirms. Rounding after the confirming quote would report a drift measured against an amount nobody is going to deposit, so the figure is brought onto the grid first and the confirmation is asked about the number that will actually be sent.
Eight decimals is the cap regardless of what a chain allows. Ether has eighteen and Monero twelve; nobody types either, every wallet rounds them, and a deposit instruction is read by a person.
Every figure above can be checked against the providers yourself — no account, no sign-up, and nothing is held for you at any point.