Skip to main content


What everyone needs to know

  • A project can set distribution limits from its treasury on a per funding cycle basis using JBController.launchProjectFor(...) and JBController.reconfigureFundingCyclesOf(...). These limits are stored in JBController.distributionLimitOf(...). Any funds that are in the project's Juicebox treasury that it hasn't specified as distributable are considered overflow.
  • Overflow serves as a project's runway since future funding cycles can tap into it within the bounds of the preconfigured distribution limits. Overflow can also serve as a refund or rebate mechanism, where everyone's net contribution price is pushed towards zero as volume outpaces what the project needs.
  • By default, overflow also serves a means for allowing community members to exit with a portion of the treasury's funds in hand. Any funds in overflow are reclaimable by the project's community by redeeming community tokens along a bonding curve defined by the project's current redemption rate. Projects can override or extend this functionality using a custom data source.
  • Projects can manage how much money is in overflow (and therefore how much each member can exit with) either by adjusting its distribution limits or by using a custom redemption extension.
  • A project can set overflow allowances from its treasury on a per-funding-cycle-configuration basis within the JBController.launchProjectFor(...) and JBController.reconfigureFundingCyclesOf(...) transactions. These allowances are stored in JBController.overflowAllowancesOf(...). A project's owner can distribute the project's funds from its overflow on-demand up until the preconfigured allowance. Overflow allowances do not reset each funding cycle, they last until a new funding cycle reconfiguration takes effect.