Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

There is no contract implementation present for the interfaces `IJBFeeGauge`, `IJBSplitAllocator`, `IJBFundingCycleDataSource`, `IJBPayDelegate` and `IJBRedemptionDelegate` in the codebase. The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Unknown implementation of interfaces

The function `distributePayoutsOf()` distribute the ETHs paid by normal users among the splits and transfer the `_leftoverDistributionAmount` ETHs directly to the project owner's address. These addresses are all EOAs(Externally Owned Account) set by project owner or `RECONFIGURE` operators. 

Additionally, by calling the function `useAllowanceOf()`, the project owner and `USE_ALLOWANCE` operators can send the rest ETHs (overflow) to an arbitrary address `_beneficiary`, which is an EOA as well.

As a result, any compromise to the EOAs may allow the malicious owner to steal the ETHs.

User funds could be arbitrarily transfer out

In the contract `JBETHPaymentTerminal`, the role `owner` has the authority over the following function:

- function `setFee()`: change the fee percentage and contractually capped at 5%,
- function `setFeeGauge()`: change the `feeGauge` address to affect the fee discount amount. 

Also, the role project owner has the authority over the following function:

- function `useAllowanceOf()`: send ETH to arbitrary `_beneficiary` address with the `overflowAllowanceOf` as the limit,
- function `redeemTokensOf()`: claim the project's overflowed ETH,
- function `migrate()`: migrate project funds and operations to a new terminal,
- function `processFees()`: process the held fees.

Among the previous mentioned functions which can be called by the project owner, the specific operator roles have the authority over the following function:
- The operator with the `USE_ALLOWANCE` permission can call the function `useAllowanceOf()`.
- The operator with the `REDEEM` permission can call the function `redeemTokensOf()`.
- The operator with the `MIGRATE_TERMINAL` permission can call the function `migrate()`.
- The operator with the `PROCESS_FEES` permission can call the function `processFees()`.

The contract deployer has the authority over the following function:

- function `constructor()`: transfer the `owner` role to an arbitrary address, initialize important contract addresses to any contract addresses implementing the corresponding interfaces, for example: `operatorStore`, `projects`, `directory`, `splitsStore`.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBETHPaymentTerminal.sol

Only when there exist `overflow` ETHs could investors redeem their funds, nevertheless, under the number of `distributionLimitOf()` and `overflowAllowanceOf()`, the project owner and corresponding operators could always revoke `distributePayoutsOf()` and `useAllowanceOf()` to take funds away. Besides, the ETHs redeemed by the investors would further shrink in terms of the `_redemptionRate` and the `reservedRate`, as a result, only a few ETHs or even none will be left when investors want to redeem their funds.

Potential redeem issue for investors

In the contract `JBETHPaymentTerminalStore`, the role `terminal` has the authority over the following function:

- function `recordPaymentFrom()`: record user payment data and mint project token to the user,
- function `recordDistributionFor()`: calculate and record the distribution amount,
- function `recordUsedAllowanceOf()`: calculate and record the withdrawnAmount amount,
- function `recordRedemptionFor()`: burn user's project token, calculate and record the redeem amount and transfer the corresponding amount of ETH to the user,
- function `recordAddedBalanceFor()`: add the ETH balance of a given project,
- function `recordMigration()`: set the current project ETH balance to 0 and return the original balance.

The contract deployer has the authority over the following function:

- function `constructor()`: initialize important contract addresses to any contract addresses implementing the corresponding interfaces, for example: `prices`, `projects`, `directory`, `fundingCycleStore` and `tokenStore`.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBETHPaymentTerminalStore.sol

In the contract `JBController`, the role project owner has the authority over the following function:

- function `launchFundingCycleFor()`: initialize the funding cycle configurations for a given project,
- function `reconfigureFundingCyclesOf()`: change the funding cycle configurations for a given project,
- function `issueTokenFor()`: create a new ERC20 token and associated with a given project ,
- function `changeTokenOf()`: change the associated token of a give project,
- function `mintTokensOf()`: mint new tokens for a give project,
- function `burnTokensOf()`: burn tokens for a give project,
- function `migrate()`: move the project to another controller.

Also, the operator with the `RECONFIGURE` permission has the authority over the following function:

- function `launchFundingCycleFor()` : initialize the funding cycle configurations for a given project,
- function `reconfigureFundingCyclesOf()`: change the funding cycle configurations for a given project.

The operator with the `ISSUE` permission has the authority over the following function: 

- function `issueTokenFor()`: create a new ERC20 token associated with a given project.

The operator with the `CHANGE_TOKEN` permission has the authority over the following function:

- function `changeTokenOf()`: change the associated token of a given project.

The operator with the `MINT` permission has the authority over the following function:

- function `mintTokensOf()`: mint new tokens for a give project.

The operator with the `BURN` permission has the authority over the following function:

- function `burnTokensOf()`: burn tokens for a give project.

The operator with the `MIGRATE_CONTROLLER` permission has the authority over the following function:

- function `migrate()`: move the project to another controller.

The contract deployer has the authority over the following function:

- function `constructor()`: initialize important contract addresses to any contract addresses implementing the corresponding interfaces, for example: `operatorStore`, `projects`, `directory`, `fundingCycleStore`, `tokenStore` and `splitsStore`.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBController.sol

In the function `mintTokensOf()`, the `_reservedRate` is a passed-in variable set by the caller. We understand the contract `JBETHPaymentTerminalStore` will call this function and pass the correct value `fundingCycle.reservedRate()`, however, the project owner and other `MINT` operators can also call this function externally with an arbitrary `_reservedRate` value.

Risk on the passed-in variable `_reservedRate`

In the function `migrate()`, the old controller will call the function `prepForMigrationOf()` in the target controller to transfer the token total supply. The `_projectId` used in these two functions are the same, indicating that the two controllers will use the same `_projectId`. However, there may be already a created project in the position of `_projectId`. Thus, without proper management, the migration may override the currently active project in the target controller.

Logic issue on migration

The state variable **_processedTokenTrackerOf[_projectId]** is used to track the reserved tokens for a given project. When new tokens are minted, part of the tokens will be recorded with this variable instead of directly minting. 

However, in the function `mintTokensOf()`, the variable **_processedTokenTrackerOf[_projectId]** is only updated when the passed-in `_reservedRate` equals to `MAX_RESERVED_RATE` or 0. When the value of `_reservedRate` is between `MAX_RESERVED_RATE` and 0, the function mints part of the tokens but does not record the other part in the variable **_processedTokenTrackerOf[_projectId]**. 

Since the `beneficiaryTokenCount` is the actual minted token amount, the other portion is the reserved token amount which is `_tokenCount - beneficiaryTokenCount`. The new **_processedTokenTrackerOf[_projectId]** should be:


****
_processedTokenTrackerOf[_projectId] = _processedTokenTrackerOf[_projectId] +

beneficiaryTokenCount - (_tokenCount - beneficiaryTokenCount)
= _processedTokenTrackerOf[_projectId] + 2 * beneficiaryTokenCount - _tokenCount
****
(The formula only shows the algebra calculation logic and does not consider the variable type.)

Logic issue about `_processedTokenTrackerOf[_projectId]`

The return value of the function `_reservedTokenAmountFrom()` may be incorrect. 

According to the code, the `_processedTokenTracker` is 
***
the minted token amount(total supply) - _unprocessedTokenBalanceOf
***
Thus, L874 will calculate the `_unprocessedTokenBalanceOf` correctly by the result of "total supply - _processedTokenTracker". As we mentioned in the issue `JCK-03`, the reserved token amount is the un-minted token recorded with `_processedTokenTracker`. So the `_unprocessedTokenBalanceOf` calculated in L874 is exactly the reserved token amount and the `return` statement (L884-L889) in the function `_reservedTokenAmountFrom()` can just return the value of `_unprocessedTokenBalanceOf`. 

Logic issue in `_reservedTokenAmountFrom()`

The function `launchProjectFor()` in the contract `JBController` does not have a permission restriction, so anyone can call this function to create a project. This may allow the malicious users to take advantage of this. For example:

- Front-running: since project 1 is the platform project which receives the charged fees, the hackers can create a project right after the contract deployment so that the hacker's project will be the platform project.
- The malicious user can call the function constantly to create many meaningless projects to contaminate the project pool.

Lack of restriction on function `launchProjectFor()`

In the contract `JBDirectory`, the role `owner` has the authority over the following function:

- function `addToSetControllerAllowlist()/removeFromSetControllerAllowlist()`: add/remove a controller to/from the trusted controller list to allow the controller to set the controller of the current directory to be another controller in the trusted list including itself.

Also, the role project owner has the authority over the following function:

- function `setControllerOf()`: update the controller that manages how terminals interact with the ecosystem,
- function `addTerminalsOf()`: add terminals to the terminal list of a specific project.

Among the previous mentioned functions which can be called by the project owner, the specific operator roles have the authority over the following function:
- The operator with the `SET_CONTROLLER` permission and the controller in the trusted list can call the function `setControllerOf()` to update the controller that manages how terminals interact with the ecosystem. 
- The operator with the `addTerminalsOf` permission can call the function `addTerminalsOf()` to add terminals to the project's list of terminals.

The contract deployer has the authority over the following function:

- function `constructor()`: initialize important contract addresses to any contract addresses implementing the corresponding interfaces, for example: `operatorStore`, `projects`.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBDirectory.sol

In the contract `JBFundingCycleStore`, the role `directory.controllerOf(_projectId)` has the authority over the following function:

- function `configureFor()`: configures the next eligible funding cycle for a specified project.

The contract deployer has the authority over the following function:

- function `constructor()`: initialize the contract address `directory` to any arbitrary address.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBFundingCycleStore.sol

In the contract `JBPrices`, the role `owner` has the authority over the following function:

- function `addFeedFor()`: add a price feed for a currency in terms of the provided base currency.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBPrices.sol

The contract is serving as the underlying entity to interact with third-party AggregatorV3Interface. The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Third party dependencies of `AggregatorV3Interface`

In the contract `JBProjects`, the role `owner` has the authority over the following function:

- function `setTokenUriResolver()`: change the funding cycle configurations for a given project.

Also, the project owner and the operator with the `SET_METADATA` permission have the authority over the following function:

- function `setMetadataOf()`: initialize the funding cycle configurations for a given project.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBProjects.sol

In the contract `JBSplitsStore`, the role project owner has the authority over the following function:

- function `set()`: to add a project's splits to the original ones.

Also, the operator with the `SET_SPLITS` permission has the authority over the following function: 

- function `set()` to add a project's splits to the original ones.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBSplitsStore.sol

In the contract `JBToken`, the role `owner` has the authority over the following function:

- function `mint()`: to mint arbitrary amount of new tokens,
- function `burn()`: to burn some tokens,
- function `transferOwnership()`: to transfer the `owner` privilege to the new owner.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBToken.sol

In the contract `JBTokenStore`, the role project owner (Of `_projectId`) has the authority over the following function:

- function `shouldRequireClaimingFor()`: to allow a project to force all future mints to be claimed into the holder's wallet.

The role `holder` has the authority over the following function:

- function `transferTo()`: to transfer unclaimed tokens to another account.

Also, the operator with the `REQUIRE_CLAIM` permission has the authority over the following function:

- function `shouldRequireClaimingFor()`: to allow a project to force all future mints to be claimed into the holder's wallet.

The operator with the `TRANSFER` permission has the authority over the following function:

- function `transferTo()`: to transfer unclaimed tokens to another account.

The role `Controller` has the authority over the following function:

- function `burnFrom()`: to burn tokens.
- function `mintFor()`: to mint new tokens.
- function `changeFor()`: to swap the current project's token that is minted and burned for another, and transfer ownership of the current token to another address if needed.
- function `issueFor()`:to issues a ERC-20 token.

Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in JBTokenStore.sol

The protocol provides a platform where everyone can create a project and become the owner of this project. The contracts composed of a given complete project can be initialized in the constructors via passing the contract addresses as parameters, however, they can be initialized
to malicious contracts that implement the protocol-defined interfaces,
or modified by the project owner and corresponding operators after the launch. 

For example,

- JBController.constructor(), to set the `IJBOperatorStore`, `IJBProjects`, `IJBDirectory`, `IJBFundingCycleStore`, `IJBTokenStore` and `IJBSplitsStore` address
- JBDirectory.constructor(), to set the `IJBProjects` address
- JBDirectory.setControllerOf(), to modify the `IJBController` address
- JBDirectory.addTerminalsOf()/removeTerminalOf(), to modify the `IJBTerminal` addresses

Although this provides great extensibility to each project, the protocol will have no control over the created projects, and the project users' assets may suffer loss.

Even when the project owner adopts the default implementation of the project contracts, the project owner has the privilege to set all the parameters of a funding cycle, terminals, tokens, splits, and beneficiaries without any limitations. As a result, the project users may not get as many ETHs as expected when redeeming, or even worse, may not be able to redeem any ETHs. The project owner, splits and beneficiaries are able to get ETHs by the functions `distributePayoutsOf()` and `useAllowanceOf()`.

For example, if the `_percentTotal` values of all the splits are set quite low, the rest `_leftoverDistributionAmount` ETHs in the function `distributePayoutsOf()` will be transferred directly to the project owner's address, which may cause a huge loss of the project users.

Project contract implementations and parameter settings can be arbitrarily set and modified

In the contract `JBETHPaymentTerminal` and `JBETHPaymentTerminalStore`, neither do the investors get an equivalent amount of minted project token when depositing ETHs and nor do they get an equivalent amount of ETHs when burning the project token.

The investors deposit ETH and get the minted project token by calling the function `pay()`. The mint amount is the deposited ETH amount multiplied by the weight set in the funding cycle configurations. However, the function `mintTokensOf()` in the contract `JBController` only mint a portion of the mint amount. The other portion is distributed to the reserved token `splits` by the function `distributeReservedTokensOf()` and the leftover amount (`_leftoverTokenCount`) of the tokens are minted directly to the project owner. 

***
      beneficiaryTokenCount = PRBMath.mulDiv(
        _tokenCount,
        JBConstants.MAX_RESERVED_RATE - _reservedRate,
        JBConstants.MAX_RESERVED_RATE
      );

      // Mint the tokens.
      tokenStore.mintFor(_beneficiary, _projectId, beneficiaryTokenCount, _preferClaimedTokens);
***

Also, in the function `redeemTokensOf()`, the investors only can get a portion of the overflow ETHs after the project owner distributes the ETHs to the `splits` by the function `distributePayoutsOf()`. However, the function `recordRedemptionFor()` still burns out all the `_tokenCount`. 

***
uint256 _base = PRBMath.mulDiv(_currentOverflow, _tokenCount, _totalSupply);
***
***
    return
      PRBMath.mulDiv(
        _base,
        _redemptionRate +
          PRBMath.mulDiv(
            _tokenCount,
            JBConstants.MAX_REDEMPTION_RATE - _redemptionRate,
            _totalSupply
          ),
        JBConstants.MAX_REDEMPTION_RATE
      );
***
***
directory.controllerOf(_projectId).burnTokensOf(_holder, _projectId, _tokenCount, '', false);
***

Investor assets are diluted by the reserved token

The divisors used in the below calculations are confusing. 
***
      PRBMath.mulDiv(
        _unprocessedTokenBalanceOf,
        JBConstants.MAX_RESERVED_RATE,
        JBConstants.MAX_RESERVED_RATE - _reservedRate
      ) - _unprocessedTokenBalanceOf;
***
***
    feeAmount =
      _amount -
      PRBMath.mulDiv(_amount, JBConstants.MAX_FEE, _discountedFee + JBConstants.MAX_FEE);
***

Normally the below formula would be used:
- _unprocessedTokenBalanceOf * _reservedRate / JBConstants.MAX_RESERVED_RATE,
- _amount * (1 - _discountedFee / JBConstants.MAX_FEE).

Juicebox DAO

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

22

0

21

0

1