[Lines of code](https://github.com/jbx-protocol/juice-contracts-v2-code4rena/blob/828bf2f3e719873daa08081cfa0d0a6deaa5ace5/contracts/JBController.sol#L740-L743) # Vulnerability details > Reserved tokens do not get minted automatically when a new payment is received. Instead, they must be explicitly distributed during the funding cycle which contains the reserved rate and splits that should be applied. If a funding cycle's reserved rate or splits change before the allocation is distributed, the new values will apply. File: contracts/JBController.sol 59 /** 60 @notice 61 The difference between the processed token tracker of a project and the project's token's total supply is the amount of tokens that still need to have reserves minted against them. 62 63 _projectId The ID of the project to get the tracker of. 64 */ 65 mapping(uint256 => int256) internal _processedTokenTrackerOf; ## Impact All of the above means that _processedTokenTrackerOf includes the project's token balance, as well as the reserve amount that will later be distributed to the split recipients. If _processedTokenTrackerOf no longer tracks the correct balance of the project's token, accounting for the contract will be broken for later operations. Depending on the direction of the tracking error, distribution recipients will get more than they deserve and other operations will revert, or the the distribution recipients will get less than they deserve. The cases described below fall into the former category. ## Proof of Concept In JBController.burnTokensOf(), if _tokenCount is greater than type(int256).max, the cast down from uint256 to int256 will wrap, causing int256(_tokenCount) to be a negative number, which will cause _processedTokenTrackerOf to _increase_ rather than decrease: File: contracts/JBController.sol #1 740 // Update the token tracker so that reserved tokens will still be correctly mintable. 741 _processedTokenTrackerOf[_projectId] = 742 _processedTokenTrackerOf[_projectId] - 743 int256(_tokenCount); The incorrect value is later used during distribution, and will lead to the wrong amount being distributed: File: contracts/JBController.sol 841 function _distributeReservedTokensOf(uint256 _projectId, string memory _memo) 842 internal 843 returns (uint256 tokenCount) 844 { 845 // Get the current funding cycle to read the reserved rate from. 846 JBFundingCycle memory _fundingCycle = fundingCycleStore.currentOf(_projectId); 847 848 // Get a reference to new total supply of tokens before minting reserved tokens. 849 uint256 _totalTokens = tokenStore.totalSupplyOf(_projectId); 850 851 // Get a reference to the number of tokens that need to be minted. 852 tokenCount = _reservedTokenAmountFrom( 853 _processedTokenTrackerOf[_projectId], 854 _fundingCycle.reservedRate(), 855 _totalTokens 856 ); The other places where _processedTokenTrackerOf is updated have similar issues. JBController.prepForMigrationOf(): File: contracts/JBController.sol #2 785 _processedTokenTrackerOf[_projectId] = int256(tokenStore.totalSupplyOf(_projectId)); JBController.mintTokensOf(): File: contracts/JBController.sol #3 679 _processedTokenTrackerOf[_projectId] = 680 _processedTokenTrackerOf[_projectId] + 681 int256(beneficiaryTokenCount); later in JBController._distributeReservedTokensOf(): File: contracts/JBController.sol #4 859 _processedTokenTrackerOf[_projectId] = int256(_totalTokens + tokenCount); ## Tools Used Code inspection ## Recommended Mitigation Steps Use OpenZeppelin's [SafeCast.toInt256()]() --- The text was updated successfully, but these errors were encountered: All reactions

The reserves accounting breaks when total balances surpas type(int256).max