Architecture

info

See JuiceboxDAO's Protocol Evolution: Navigating Updates and Enhancements.

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.

Core contracts

The first two core contracts are self explanatory. They store the core opinionated components of the protocol.

• JBTokenStore manages token minting and burning for all projects.
• JBFundingCycleStore manages funding cycle configurations and scheduling. Funding cycles are represented as a JBFundingCycle data structure.

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.

• JBProjects manages 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.

• JBSplitsStore stores information about how arbitrary distributions should be split. The information is represented as a JBSplit data structure.

  The surface contracts currently use these to split up payout distributions and reserved token distributions.

• JBPrices manages 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.

• JBOperatorStore stores 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.

• JBDirectory keeps 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.

Surface contracts

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_1 stitches together funding cycles and project tokens, allowing for restricted control, accounting, and token management.
• JBPayoutRedemptionPaymentTerminal3_1_1 manages all inflows (pay, addToBalanceOf) and outflows (distributePayoutsOf, useAllowanceOf, redeemTokensOf) of funds. This is an abstract implementation that can be used by any number of payment terminals, such as JBETHPaymentTerminal3_1_1's and JBERC20PaymentTerminal3_1_1's.
• JBSingleTokenPaymentTerminalStore3_1_1 manages accounting data on behalf of payment terminals that manage balances of only one token type.

The abstract JBPayoutRedemptionPaymentTerminal3_1_1 implements the IJBPaymentTerminal interface to provide outflow mechanics, and JBETHPaymentTerminal3_1_1 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

• JBETHERC20ProjectPayer provides 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.
• JBETHERC20ProjectPayerDeployer provides a function to deploy new stand-alone JBETHERC20ProjectPayers.
• JBETHERC20SplitsPayer provides 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.
• JBETHERC20SplitsPayerDeployer provides a function to deploy new stand-alone JBETHERC20SplitsPayers.
• [JBProjectHandles]((/docs/dev/v2/contracts/or-utilities/jbprojecthandles/README.md) lets 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.