Overflow

What everyone needs to know

• A project can set distribution limits from its treasury on a per funding cycle basis using JBController3_1.launchProjectFor(...) and JBController3_1.reconfigureFundingCyclesOf(...). These limits are stored in JBFundAccessConstraintsStore.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 JBController3_1.launchProjectFor(...) and JBController3_1.reconfigureFundingCyclesOf(...) transactions. These allowances are stored in JBFundAccessConstraintsStore.overflowAllowanceOf(...). 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.