| Project | Each Juicebox project is represented as an NFT (ERC-721), managed in the JBProjects contract. The owner of this NFT is specified when the project is being created. Ownership over this NFT is used to enforce permissions needed to access several project-oriented transactions. Like any other NFT, ownership can be transferred from the original owner to any other address, such as a multi-sig wallet, voting contract, or burn address. Learn more |
| Funding cycle | A project is expressed in terms of funding cycles. A funding cycle outlines the time-locked rules according to which a project wishes to operate. It is represented as a JBFundingCycle data structure, and managed by the JBFundingCycleStore contract. Learn more |
| Tokens | The Juicebox protocol keeps track of tokens for each project. When a payment is made to a project, the protocol mints tokens for a specified beneficiary according to the rules of the project's current funding cycle. Tokens are managed in the JBTokenStore contract. Projects can optionally call its issueFor(...) transaction to issue an ERC-20 to represent their token. Once issued, anyone with a project's tokens can claim them from the protocol's internal accounting mechanism into their wallet to use around Web3. Projects can also bring their own token, so long as it adheres to the IJBToken interface and uses 18 decimal fixed point accounting. Learn more |
| Overflow | The JBFundAccessConstraintsStore contract has a distributionLimitOf(...) property which denotes how much funds a project can pull from its treasury to distribute to its preprogrammed payout splits during each funding cycle. Any funds in the treasury in excess of the current distribution limit is considered overflow. A project's overflow can be reclaimed by its community by redeeming tokens. A project can specify treasury funds or assets held outside of Juicebox contracts by attaching a IJBFundingCycleDataSource to its funding cycles. Learn more |
| Discount rate | JBFundingCycle data structures have a weight property that is automatically derived from multiplying the weight of the previous funding cycle by the discountRate of the previous cycle. The weight property can then be used to determine how many project tokens are distributed per unit of payment received during the funding cycle, or for any other functionality implement through a funding cycle's data source and delegates. A project can also customize its funding cycle's weight manually.
Learn more |
| Redemption rate | JBFundingCycle data structures configured through the JBController3_1 contract have a redemptionRate metadata property that can be used to determine how much overflowed funds can be reclaimed by redeeming project tokens, or for any other functionality implemented in a funding cycle's data source and delegates.
Learn more |
| Reserved tokens | JBFundingCycle data structures configured through the JBController3_1 contract have a reservedRate metadata property which specifies the percentage of tokens minted as a result of newly received payments that should be reserved for distribution to preprogrammed reserved token splits.
Learn more |
| Splits | A Split is used to send a percent of a total amount to a preprogrammed address, Juicebox project, contract that inherits from IJBSplitAllocator, or sender of the transaction causing the distribution to splits. Splits are represented with JBSplit data structures, and managed by the JBSplitsStore. A split does not hold information about what is being split, it's simply a structure organizable into groups that maps a receiver to a percentage. Learn more |
| Split allocator | A project can preconfigure splits to be directed to any contract that adheres to IJBSplitAllocator whose allocate(...) transaction will be called when tokens are distributed. Learn more |
| Ballot | JBFundingCycle data structures have a ballot property which is the address of a contract that adheres to the IJBFundingCycleBallot interface. This contract specifies the conditions that must be met for any proposed funding cycle reconfiguration to take effect.
A ballot contract can be written to incorporate strict community voting requirements in order to make funding cycle changes, or to simply add a required buffer period between when a change is proposed and when it can take effect. Learn more |
| Payment terminal | A project can be configured to use any contract that adheres to IJBPaymentTerminal to manage its inflows and outflows of token funds. It can set its terminals using JBDirectory.setTerminalsOf(...), and if it uses multiple tokens to manage funds for the same token, it can set the primary one where other Web3 contracts should send funds to using JBDirectory.setPrimaryTerminalOf(...). Learn more |
| Data source | JBFundingCycle data structures configured through the JBController3_1 contract have a dataSource metadata property which is the address of a contract that adheres to the IJBFundingCycleDataSource3_1_1 interface.
Including a data source allows projects to customize what happens when a payment is attempted to the project during a funding cycle, and what happens when a token is attempted to be redeemed during a funding cycle. Learn more |
| Delegate | When a project receives a payment, its funding cycle's data source can specify the address of a contract that adheres to the IJBPayDelegate3_1_1 whose didPay(...) transaction will be called once JBPayoutRedemptionPaymentTerminal3_1_1.pay(...) has been executed. Similarly, when a project's tokens are being redeemed, its funding cycle's data source can specify the address of a contract that adheres to the IJBRedemptionDelegate3_1_1 whose didRedeem(...) transaction will be called once JBPayoutRedemptionPaymentTerminal3_1_1.redeemTokensOf(...) has been executed. These can be used by projects to customize what happens when it receives payments and when someone redeems its tokens. Learn more |
| NFT Rewards | A project can use the NFT Rewards delegate if it wishes to distribute NFTs of any number of tiers to addresses who contribute during a particular set of funding cycles. These NFTs can then be used for redemptions instead of the standard project tokens if the project chooses to. Learn more |
| Token Store | The JBTokenStore contract manages project token balances, minting, and burning for all projects on a version of the protocol. It must adhere to the IJBTokenStore interface, and its address can be found by reading a project's JBController3_1.tokenStore. Learn more |
| Operator | Addresses can give permissions to any other address to take specific actions throughout the Juicebox ecosystem on their behalf. These addresses are called Operators, and are managed through the JBOperatorStore contract. Learn more |