Original Report from Certik

PRE-Juicebox-Contracts-V2__preliminary-20220303T115300Z.pdf

Response from JuiceboxDAO

Summary

The report calls attention to several important risks that projects and communities inherit and must be aware of as they make use of the Juicebox protocol, all of which are by design as tradeoff to the ecosystem being extensible, forkable, and interoperable, and with each project being reconfigurable over time by the address who owns its JBProjects NFT.

Projects with sturdier community-directed governance mechanisms — on-chain or through a distributed and trusted multisig — reduce risk of the misuse of power to reconfigure the treasury and alter its extensions.

It’s also great to call attention to the few powers JuiceboxDAO members have. These are responsibilities that should be well known.

Only one item (JCK-04) was actionable and addressed in a PR. It was a good suggestion of how to change a particular function definition to reduce the likelihood of a user input error. Shout out to Certik for catching this.

Findings

Global-01

The purpose of leaving these interfaces unimplemented is to allow arbitrary functionality to be provided down the road. The contracts are designed to either limit the scope of what implementations can do, or allow projects to bring their own functionality and their own risk and gas alongside.

More specifically:

IJBFeeGauge returns a percentage to be discounted from the default protocol fee that can be a function of the project paying the fee. The fact that this is a discount means the fee can only be lowered, which removes the risk of poor implementations creating abusing fees.

The fee gauge is only settable by the owner of the JuiceboxDAO project.

IJBSplitAllocator is implementable by anyone, but must be explicitly attached to as a destination of a project’s preprogrammed payouts by the project owner. This allows projects to roll out automated cascading functionality that’ll automatically be triggered when payouts are distributed.

By attaching an implementation of the split allocator to a funding cycle, a project is assuming its own risk. This is by design.

IJBFundingCycleDataSource is implementable by anyone, but must be explicitly attached to a project’s funding cycle configuration by the project owner. This allows projects to request custom data and add custom revert criteria as it receives payments and as its tokens are redeemed.