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 |
| Rulesets | TLDR: A sequence of configurable, time-locked rules that define how a Juicebox project operates over time. 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 |
| 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 project's current ruleset. Tokens are managed in the Projects can also bring their own token, so long as it adheres to the |
| Surplus | TLDR: Funds exceeding a project's payout limit, reclaimable by its community through token cash-outs. The |
| Weight cut percent | TLDR: Defines how a project's token distribution changes over time by reducing its weight in each ruleset cycle.
|
| Cash out tax rate | TLDR: A project's configurable tax rate on surplus funds when tokens are cashed out.
|
| Controller | TLDR: The contract responsible for managing a Juicebox project's core operations, including ruleset configuration, token minting, and splits. The Controller is a central contract in the Juicebox protocol that allows project owners to configure and update their project's rulesets, manage token issuance, and control how splits are set. It interacts with other core contracts such as |
| 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 reservedPercent 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.
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.
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.
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(...).
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.
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 | | Permissions |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.
TLDR: A project can recieve funds and issue its tokens from any number of blockchains it chooses from the set of eligible ones, currently Ethreum mainnet, Optimism, Arbitrum, and Base.
Under the hood, a juicebox project is deployed independently on each chain. They can have matching rulesets and payouts, or be totally different. The juicebox projects on the various chains are connected in only one way: token holders on one chain can bridge over to any other chain where the project exists.
Learn more | | Suckers |TLDR: A sucker is the component projects use to connect multiple instances of Juiceboxes across chains.
A sucker is kind of like a bridge, with some special properties that make omnichain Juiceboxes work well together.
Learn more | | Hold fees |TLDR: The hold fees option allows a project to raise funds, attempt to use the funds, and return the funds if the attempt fails.
The choice of holding fees is set on a per-ruleset basis. All held fees can be processed after 28 days without paying back withdrawn funds.
Learn more | | Relayr |TLDR: A tool for web clients to use when coordinating a project's ops across blockchains while simplifying wallet signatures and transactions.
Relayr can be seen on juicebox.money and app.revnet.eth.sucks when getting a deploy quote and paying for it.
Learn more |