I’m refactoring the redemptions contract at the moment and have run into a bit of a trilemma. I’ve been using [Influence’s Math64x61 library](https://github.com/influenceth/cairo-math-64x61/blob/master/contracts/Math64x61.cairo) for floating point stuff. I initially started using it because I wanted to use their exponential and log functions, but we then decided to drop those from the design. It’s become a bit of a nightmare to work with because so many conversions must be done between uint256, 18/6 decimal felts (representing token balances), and 64.61 fixed point numbers. In an effort to simplify, I think it makes sense for us to create our own fixed-point math library with both 18 and 6 decimal precision. The question is then what to use as the “base”/primitive for this library: 1. uint256 2. int125 (e.g. https://github.com/bellissimogiorno/cairo-integer-types#the-cairo-smart-test-suite) 3. raw felts uint256 is nice because it’s by-default more compatible with existing standards. Also no need for any conversions for the most part. However, operations are significantly more expensive than with felts. int125 is nice because its functions tell you if an overflow occured, and because the the type is very easy to reason about: exactly 125 bits and behaves just like normal numbers. But operations also seem significantly more expensive than felt operations (haven’t checked by how much). Int125 is currently being used in the MRAC implementation. It also uses custom hints which have to be whitelisted. I’m not sure how to check if they’re already whitelisted or not. Raw felts are nice because they’re syntactically the cleanest and simplest to use, but they’re more difficult to reason about. For example, what are the maximum values that can be used in a function like `unsigned_div_rem(value, div)`? The answer for `div` is `0 < div <= PRIME // 2**128`, but the maximum possible value of `value` depends on the value of `div`: `value/div < rc_bound`. See the [code](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/cairo/common/math.cairo) for more details. I’m leaning towards raw felts but wanted to get everyone’s inputs, especially because the entire codebase should be using the same library for fixed-point operations. I’m not entirely sure how to weigh the tradeoffs here. Our fixed point lib should look something like this https://github.com/aave/aave-protocol/blob/master/contracts/libraries/WadRayMath.sol Additional: https://github.com/OpenZeppelin/cairo-contracts/discussions/34#discussioncomment-1655945