The protocol is made up of 7 core contracts and 3 surface contracts.
- Core contracts store all the independent components that make the protocol work.
- Surface contracts glue core contracts together and manage funds. Anyone can write new surface contracts for projects to use.
The first two core contracts are self explanatory. They store the core opinionated components of the protocol.
JBTokenStoremanages token minting and burning for all projects.
JBFundingCycleStoremanages funding cycle configurations and scheduling. Funding cycles are represented as a
The next few are a little more generic. They don't know anything specific to the ecosystem, and are open for use by other protocols or future extensions.
JBProjectsmanages and tracks ownership over projects, which are represented as ERC-721 tokens.
The protocol uses this to enforce permissions needed to access several project-oriented transactions.
The surface contracts currently use these to split up payout distributions and reserved token distributions.
JBPricesmanages and normalizes price feeds of various currencies.
The protocol uses this to allow projects to do their accounting in any number of currencies, but manage all funds in ETH or other assets regardless of accounting denomination.
JBOperatorStorestores operator permissions for all addresses. Addresses can give permissions to any other address to take specific indexed actions on their behalf, while confining the permissions to an arbitrary number of domain namespaces.
The protocol uses this to allow project owners and token holders to give other EOAs or contracts permission to take certain administrative actions on their behalf. This is useful for encouraging a composable ecosystem where proxy contracts can perform actions on an address's behalf as a lego block.
JBDirectorykeeps a reference of which terminal contracts each project is currently accepting funds through, and which controller contract is managing each project's tokens and funding cycles.
There are currently 3 surface contracts that manage how projects manage funds and define how all core contracts should be used together. Anyone can write new surface contracts for projects to use.
JBController3_1stitches together funding cycles and project tokens, allowing for restricted control, accounting, and token management.
JBPayoutRedemptionPaymentTerminal3_1_1manages all inflows (
addToBalanceOf) and outflows (
redeemTokensOf) of funds. This is an abstract implementation that can be used by any number of payment terminals, such as
JBSingleTokenPaymentTerminalStore3_1_1manages accounting data on behalf of payment terminals that manage balances of only one token type.
JBPayoutRedemptionPaymentTerminal3_1_1 implements the
IJBPaymentTerminal interface to provide outflow mechanics, and
JBERC20PaymentTerminal3_1_1 in-turn extend the
JBPayoutRedemptionPaymentTerminal3_1_1 to provide scoped inflow/outflow environments for specific tokens. Projects are welcome to roll their own
IJBPaymentTerminal implementations to accept funds through. This can be useful to accept other tokens as payment, bypass protocol fees, or attempt some other funky design. A project can add/remove terminals from the core
JBDirectory contract using
JBDirectory.setTerminalsOf(...) if its current funding cycle is configured to allow doing so.
Likewise, a project can bring its own contract to serve as its controller. A project's controller is the only contract that has direct access to manipulate its tokens and funding cycles. A project can set its controller from the core
JBDirectory contract using
JBDirectory.setControllerOf(...) if its current funding cycle is configured to allow doing so.
Bonus utility contracts
JBETHERC20ProjectPayerprovides utilities to pay a project. Inheriting this contract is useful for contracts that wish to route funds to a treasury while specifying the token beneficiary, memo, and other contextual information alongside. Instances of this contract can also be deployed as stand-alone addresses that will forward funds received directly to a project's treasury.
JBETHERC20ProjectPayerDeployerprovides a function to deploy new stand-alone
JBETHERC20SplitsPayerprovides utilities to pay a group of splits. Inheriting this contract is useful for contracts that wish to route funds to a group of splits while specifying contextual information alongside. Instances of this contract can also be deployed as stand-alone addresses that will forward funds received directly to a group of splits.
JBETHERC20SplitsPayerDeployerprovides a function to deploy new stand-alone
JBProjectHandleslets project owners attach an ENS name as a project handle. Front ends can use a project's handle in place of its project ID, and indexers can use events to make the Juicebox project directory searchable and filterable.