Skip to main content

Versioning History

v1​

Juicebox was first deployed to Ethereum mainnet on July 15, 2021. We now refer to this version of the protocol as "Juicebox v1" – you can find an archive of its original documentation here, and recent v1 API documentation here. Its source code is available on GitHub. The v1 contracts were published alongside the article: Juicebox has been deployed.

v1.1​

TerminalV1_1, called Juicebox v1.1, introduced:

  • payIsPaused, a funding cycle metadata flag which allows project creators to pause payments to their project when deploying configureing a project.
  • ticketPrintingIsAllowed, a funding cycle metadata flag which allows project creators to mint arbitrary amounts of their project token on-demand. In v1, this behavior was only possible before a project had received its first payment.
  • The ability to redeem a project's token when no funds were available to reclaim, thus burning them, was added.
  • The treasuryExtension option was added to funding cycle metadata. This allowed project owners to designate an ITreasuryExtension contract to tell the protocol how much ETH the project is storing outside of the protocol, and to take this ETH into account when calculating token redemptions.
  • Protocol fees were capped at 5%.
  • A bug which caused extra reserved issuance when changing the reserved rate from 0% to another number was fixed.
  • A bug which caused issues with overflow calculation when a new cycle had begun and newly availble funds still had not been paid out was fixed.
  • In v1, the Governance contract provisioned terminal migrations, price feed updates, and fee changes. In v1.1, this functionality was handled directly within the TerminalV1_1 contract.

JBP-71 - Juicebox V1.1 deploy was approved on January 7th, 2022, and Juicebox v1.1 was deployed to Ethereum mainnet on January 10th, 2022. Its API documentation is available here, and its source code is available on GitHub. For more information, see the Juicebox V1.1 Change log.

TerminalV1Rescue​

TerminalV1Rescue allowed allow-listed projects with one-time funding cycles to rescue stuck ETH. A proposal to deploy it was approved on February 4th, 2022, and the terminal was deployed to Ethereum mainnet on February 16th, 2022. Its API documentation is available here, and its source code is available on GitHub.

v2​

Juicebox v2 was a complete re-write of the protocol – its architecture and functionality significantly differ from v1.

Key functionality changes:

  • v2 introduced the ability for one project to use multiple payment terminals. This opens the door to projects accepting multiple currencies, and to projects using custom terminals which function as vaults, perform swaps, or interact with other contracts in unique ways.
  • v2 enabled new types of protocol extensions: data sources and delegates. A data source allows a project to provide custom data to a payment terminal's pay/redeem functions. Data sources can revert under custom circumstances, which can be used to create a gated treasury, a maximum token supply, a minimum contribution amount, or something else. Delegates are contracts which can define custom functions which are executed after payment or redemption logic has been completed, but before funds and tokens are transferred.
  • v2 introduced the operator system which allows addresses to grant other addresses permission to take specific Juicebox-related actions on their behalf. For a full list of operator permission types, see Namespaces & Indices.

JBP-152: Deploy v2 was approved on April 29, 2022, and Juicebox v2 was first deployed to Ethereum mainnet on May 7th, 2022. Its API documentation is available here, and its source code is available on GitHub. A medium severity bug was identified on May 24th, 2022, and several v2 contracts were fixed and re-deployed on May 25th, 2022.

v3​

Juicebox v2 was audited by PeckShield and Certik before being deployed, and was audited by a Code4rena contest after it was deployed. This audit identified several bugs and inefficiencies, which were addressed in Juicebox v3 – a re-deploy of several (but not all) protocol contracts. Juicebox v3 was deployed to Ethereum mainnet on September 20th, 2022. Its API documentation is available here, and its source code is available on GitHub.

v3.1​

A high severity bug was identified when deploying the v3 JBX migration contracts. The bug was mitigated for JuiceboxDAO's project by adopting JBController3_0_1, which was followed up by a more robust fix to address other risks and inefficiencies: JBETHPaymentTerminal3_1 and JBController3_1.

JBP-341 - Finish versioning migration was approved by the DAO on February 17, 2023, and Juicebox v3.1 was deployed to Ethereum mainnet on February 21st, 2023.

v3.1.1​

JBETHPaymentTerminal3_1_1 was deployed on June 30th, 2023 in this PR.

As described on jango.eth.limo, the 3.1.1 terminal:

  1. Is fully backward compatible with the 3.1 terminal interface.
  2. Uses a new 3.1.1 Payment Terminal Store, whose views are fully backward compatible with the 3.1 Store interface.
  3. Enforces the JBX membership fee when funds leave a treasury through redemptions while the project’s redemption rate or ballot redemption rate is less than 100%. This is currently a 2.5% membership fee, changeable by JBX holders up to 5%.
  4. Adds the ability for data sources to pass arbitrary bytes to the delegates it specifies.
  5. Fixes a low severity bug - there was still one case where a project’s payouts could be reverted if sent when a recipient project didn’t have a terminal installed.
  6. Optimizes gas further - the fee property was being loaded from storage often, and is now cached better.
  7. Improves all contracts’ natspec documentation.
  8. Specifies all imports explicitly in the files from which they’re used.
  9. Removes the leading underscore from function argument names in interfaces.

v3.1.2​

JBETHPaymentTerminal3_1_2 was deployed on August 15th, 2023 in this PR, in which Jango contextualizes its changes:

@filipviz and I discovered a bug July 24, 2023 while helping project #548 raise funds for an auction.

The project had heldFees on. After failing to win the auction and upon returned the funds, the project was not made whole.

The bug is that the protocol expected a deposit equivalent to the amount paid out. In other words, if 10 ETH was paid out (before the fee), the protocol was expected a deposit of 10 ETH to return the full fee amount. The problem is the recipient doesn't have the full 10 ETH, they only have the amount after the fee. The protocol should only expect the a deposit of the amount paid out after fees... the amount the recipient actually has.

This PR introduces JBPayoutRedemptionTerminal3_1_2 that fixes this issue.

It also

  • moved fee calculations into a JBFees library
  • removes the isTerminalOf check from pay and addToBalance to reduce contract size to be deployable. In pay these checks are already made when minting tokens. Clients are now responsible for making sure this check is correct, otherwise the project can access the funds from the terminal by setting distribution limits in a subsequent cycle.