You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fee code is unnecessarily complex, involving arcane concepts like "fee units" and "reference transactions", some of which are adjustable and some of which are not. These values are represented as integers of various widths and a lot of effort is expended to keep all that straight and to help developers avoid doing the wrong thing.
Since the fee units are hard-coded to 10 and the "reference transaction" fee is also 10 and dividing the two gives the identity, there's an opportunity to simply, quickly and easily remove all that complexity, eliminate the whole concept of "fee units" and move to something sane: XRPAmount for all fees.
All scaling/adjusting of fees would operate directly on XRPAmount objects (which are scalars) instead.
The text was updated successfully, but these errors were encountered:
The fee code is unnecessarily complex, involving arcane concepts like "fee units" and "reference transactions", some of which are adjustable and some of which are not. These values are represented as integers of various widths and a lot of effort is expended to keep all that straight and to help developers avoid doing the wrong thing.
Since the fee units are hard-coded to 10 and the "reference transaction" fee is also 10 and dividing the two gives the identity, there's an opportunity to simply, quickly and easily remove all that complexity, eliminate the whole concept of "fee units" and move to something sane:
XRPAmount
for all fees.All scaling/adjusting of fees would operate directly on
XRPAmount
objects (which are scalars) instead.The text was updated successfully, but these errors were encountered: