Normalize slippage units at each API boundary

A value of 0.5 is ambiguous without a unit. It can mean half a percent, fifty percent or half a basis point depending on the interface. Store the application's slippage setting with an explicit unit and convert it at the provider boundary.

One tolerance, three representations

The PancakeSwap Unified Swap request uses a fraction. Its nested pcsx payload can also carry a percent string for the underlying engine. The two units coexist in one response, making an untyped global slippage variable particularly risky.

Validate after conversion

Check the endpoint's accepted range and precision. A number that is valid in the UI may be invalid after conversion or rounding. Reject a tolerance outside the supported range instead of clipping it silently, because clipping changes the user's execution constraint.

For an exact-input trade, minimum received generally limits output deterioration. Exact-output execution can instead constrain maximum input. Use the provider's documented trade direction and payload rather than applying one formula indiscriminately.

A hypothetical amount of 1,000 output units with a 50-basis-point reduction gives 995 units before integer rounding considerations. That example is useful for a unit test but does not prove that every provider calculates its signed bound from the same displayed quote field.

Fixtures should compare equivalent inputs across adapters, inspect the resulting request values and include zero, excessive precision and the documented boundary limits. A round-trip display check should show the original percentage rather than a hundredfold change.