When (int256(_locked.amount) * iMULTIPLIER) < iMAXTIME and ((int256(_locked.amount) * iMULTIPLIER) < iMAXTIME, it results in zero. So for the locked amounts which is small enough when multiplied by iMULTIPLIER=2 end up being lower than iMAXTIME, will not be counted in bias and slope calculation. At that point in time, there slope and bias will be zero.
Paste following foundry code in src/test/FluxToken.t.sol
Run using FOUNDRY_PROFILE=default forge test --fork-url $FORK_URL --fork-block-number 17133822 --match-contract FluxTokenTest --match-test testPrecisionLoss -vv
functiontestPrecisionLoss() external {uint256 tokenId =4;address ownerOfPatronNFT =IAlEthNFT(patronNFT).ownerOf(tokenId);// address ownerOfAlchemechNFT = IAlchemechNFT(alchemechNFT).ownerOf(tokenId);assertEq(flux.balanceOf(ownerOfPatronNFT),0,"owner should have no flux");// assertEq(flux.balanceOf(ownerOfAlchemechNFT), 0, "owner should have no flux");uint256 tokenData1 =IAlEthNFT(patronNFT).tokenData(tokenId);uint256 patronTotal = flux.getClaimableFlux(tokenData1, patronNFT);// console.log("patronTotal:", patronTotal);uint256 _bpt = flux.calculateBPT(tokenData1);uint256 veMul =200000;//IVotingEscrow(veALCX).MULTIPLIER();uint256 veMax =IVotingEscrow(veALCX).MAXTIME();uint256 fluxPerVe =IVotingEscrow(veALCX).fluxPerVeALCX();uint256 fluxMul =IVotingEscrow(veALCX).fluxMultiplier();// Amount of flux earned in 1 yr from _amount assuming it was deposited for maxtimeuint claimableFlux = (((_bpt * veMul) / veMax) * veMax * (fluxPerVe + BPS)) / BPS / fluxMul; console.log("patronTotal :", patronTotal); console.log("claimableFlux:", claimableFlux);}
As we can see, by increasing MULTIPLIER, precision has increased. We have used 200000 as MULTIPLIER here to show precision issue as it was set 2 initially.