Glossary

Term	Preview
Project	TLDR: A Juicebox project is an NFT (ERC-721) representing ownership and permissions for managing project-specific transactions. Each Juicebox project's 721 is 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
Ruleset	TLDR: A set of configurable, time-locked rules that define how a Juicebox project operates. A project is expressed in terms of rulesets. A ruleset outlines the time-locked rules according to which a project wishes to operate. It is represented as a JBRuleset data structure, and managed by the JBRulesets contract. Learn more
Tokens	TLDR: Tokens minted for a project based on its ruleset, optionally issued as ERC-20 tokens or integrated with a custom token. 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 ruleset. Tokens are managed in the JBTokens contract through its controller. Projects can optionally call their controller's deployERC20For(...) 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
Surplus	TLDR: Funds exceeding a project's payout limit, reclaimable by its community through token cash-outs. The JBFundAccessLimits contract has a payoutLimitOf(...) property which denotes how much funds a project can distribute to its preprogrammed payout splits during each ruleset. Any funds in the project in excess of the current distribution limit is considered surplus. A project's surplus can be reclaimed by its community by cashing out tokens. A project can specify funds or assets held outside of Juicebox contracts as surplus by attaching a IJBRulesetDataHook to its rulesets. Learn more
Weight cut percent	TLDR: Defines how a project's token distribution changes over time by reducing its weight in each ruleset cycle. JBRuleset data structures have a weight property that is automatically derived from multiplying the weight of the previous ruleset by the weightCutPercent of the previous cycle. The weight property is then be used to determine how many project tokens are distributed per unit of payment received during the ruleset, or for any other functionality implemented through a ruleset's data hook and pay hook. A project can also customize its ruleset's weight manually. Learn more
Cash out tax rate	TLDR: A project's configurable tax rate on surplus funds when tokens are cashed out. JBRuleset data structures configured through the JBController contract have a cashOutTaxRate metadata property that can be used to determine how much surplus funds can be reclaimed by cashing out project tokens, or for any other functionality implemented in a ruleset's data hook and cash out hook. Learn more
Reserved tokens	TLDR: A percentage of newly minted tokens reserved for specific addresses or allocations. JBRuleset data structures configured through the JBController contract have a cashOutTaxRate 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	TLDR: Preprogrammed distributions of funds or tokens to addresses, contracts, or Juicebox projects. A Split is used to send a percent of a total amount to a preprogrammed address, Juicebox project, contract that inherits from IJBSplitHook, or sender of the transaction causing the distribution to splits. Splits are represented with JBSplit data structures, and managed by the JBSplits contract. 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 hook	TLDR: A contract that processes specific actions when splits are distributed. A project can preconfigure splits to be directed to any contract that adheres to IJBSplitHook whose processSplitWith(...) transaction will be called when tokens are distributed. Learn more
Ruleset approval hook	TLDR: A contract specifying conditions for approving or reconfiguring a project's ruleset. JBRuleset data structures have an an approval hook property which is the address of a contract that adheres to the IJBRulesetApprovalHook interface. This contract specifies the conditions that must be met for any proposed ruleset to take effect. An approval hook contract can be written to incorporate strict community review times or voting requirements in order to make ruleset changes, or to simply add a required wait period between when a change is proposed and when it can take effect. Learn more
Terminal	TLDR: A contract managing a project's incoming and outgoing funds, with support for multiple terminals and primary terminal settings. A project can be configured to use any contract that adheres to IJBTerminal to manage its inflows and outflows of funds. It can set its terminals using JBDirectory.setTerminalsOf(...), and if uses many terminals it can set the primary one where other contracts should send funds to projects using JBDirectory.setPrimaryTerminalOf(...). Learn more
Data hook	TLDR: Custom logic executed during payments or cash-outs, defined in a project's ruleset. JBRuleset data structures configured through the JBController contract have a dataHook metadata property which is the address of a contract that adheres to the IJBRulesetDataHook interface. Including a data hook allows projects to customize what happens when a payment is attempted to the project during a ruleset, and what happens when a token is attempted to be cashed out during a ruleset. Learn more
Pay hook	TLDR: A contract triggered after payments are processed for additional project-defined logic. When a project receives a payment, its ruleset's data hook can specify the address of a contract that adheres to the IJBPayHook whose afterPayRecordedWith(...) transaction will be called once JBMultiTerminal.pay(...) has been executed. Learn more
Cash out hook	TLDR: A contract triggered when project tokens are cashed out, enabling custom redemption behavior. When a project's tokens are being cashed out, its ruleset's data hook can specify the address of a contract that adheres to the IJBCashOutHook whose afterCashOutRecordedWith(...) transaction will be called once JBMultiTerminal.cashOutTokensOf(...) 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
ERC721 reward tiers	TLDR: Allows projects to distribute tiered NFTs to contributors, optionally usable for token cash-outs. A project can use the tiered ERC721 hook if it wishes to distribute NFTs from any number of tiers to addresses who contribute during a particular set of rulesets. These 721s can optionally then be used for cash outs instead of the standard project tokens. Learn more
Operator	TLDR: Delegated addresses with specific permissions to act on behalf of another address in the Juicebox ecosystem. 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 JBPermissions contract. Learn more