Skip to content

[V123-specific] Respect pool decimals for affiliate fees and streaming swaps

Multipartite requested to merge Multi/floorL1Decimals into develop

[V123-specific]

Intended to close #1502
'Pools with fewer-than-8 Decimals have balance_asset amounts not matching that restriction'.
(In effect, decimals-unrespecting BalanceAsset gets out of sync with decimals-respecting vault balances.)

!2978 (merged) having been merged, this is intended to implement a rewrite of !2776 (closed)'s
!2776 (fdaa92e5)
!2776 (2672ace3)
!2776 (7027f6b7)
commits by itself.

An Asset's pool represents the amount of the Asset in the vault, which can only follow the Asset's decimal precision.

For an affiliate fee split (separate swap inputs for main and affiliate) in which one swap succeeds and one is refunded
(or a streaming swap partial success and partial refund)
a decimals-unrespecting portion of the total swap input enters the pool
and a decimals-respecting portion is refunded from the vaults without entering the pool.

This can currently leave an amount in the pool not matching the vault sum or the Asset's decimals precision,
avoidable if the splitting process (affiliate fee split or streaming swap upon NextSize call) respects the pool decimals
and so does not swap fractions of the Asset's smallest possible amount(/precision).


(I note that I initially planned to do the streaming swap decimals-respecting within NextSize so that the TradeTarget would match more closely,
but observed an import cycle not allowed error upon trying to let NextSize in the types package use a keeper to check the Asset's pool.)

Edited by Multipartite

Merge request reports