Skip to main content

9 posts tagged with "protocol"

View All Tags

· 5 min read

New website just dropped for the Juicebox Protocol

After countless workshops, discussions, and pull requests, the website for is now live featuring the new homepage, About page, and Success Stories, as well as some exciting new features like improved search and project tags. The new website was made possible by PeelDAO, the front end team building and maintaining, and WAGMI Studios, whose juicy artwork is featured throughout.

You can follow along in the video below or in this article.

The Homepage

Let’s get started with the homepage. At the top we’ve got a call-to-action: create a project and Fund your thing. And right below you can see a few trending projects built on Juicebox, so you can browse what creators are building and find some projects that align with your values and interests.

Fund your thing hero section on

Hero: Fund your thing, trending projects

You’ll also notice some categories at the top like DAO, NFT, and Fundraising. Those are a new feature: Project Tags! So for example, if you click on DAO you’ll be able to find projects that have added that tag. You can also use tags to filter your searches. Keep in mind that this is a new feature and not too many projects have added tags yet. Give it a try next time you’re browsing projects.

Explore Projects

Once you’re on the Explore page, you’ll also notice that search has been completely revamped so it’s now way easier to find specific projects or browse to find new ones. Looking for projects by Krause House? Try searching terms like “NBA”. If you’re feeling nounish you can search “nouns” and find projects in the Nouns ecosystem like SharkDAO.

Project tags on the Explore page

Explore page

Mental Models for Juicebox

So going back to the homepage, you’ll see a few examples of the different types of projects that you can build with Juicebox. Whether you’re starting a DAO, crowdfunding for a cause, launching an NFT project, or building something else, you can manage the funds transparently with your community.

Mental models for Juicecbox

Mental models for Juicebox

Introducing Success Stories

If you’d like to know more about past projects that have been successful, we’ve created a new Success Stories section which tells the story behind projects like ConstitutionDAO, MoonDAO, SharkDAO, and StudioDAO. Each case study will tell you how the project got started, how they set-up their project on Juicebox, and how they found success.

new success stories on Juicebox

Success Stories

How, What, and Why you should Juicebox

Back to the homepage, next we have a quick summary of how Juicebox works, including setting up your project with rules to build trust, managing your treasury onchain, and building your community with token and NFT issuance. You can also find a link to the docs if you want to learn more. Next we have a section highlighting some of Juicebox’s core strengths. Juicebox is:

  • Community owned
  • Reliable and transparent
  • Trust minimized
  • Flexible
  • Extensible

Section highlighting why you should use Juicebox

What is Juicy Picks?

After that we have the Juicy Picks section, which is a new section of curated projects on Juicebox that really stand out from the crowd. These projects will rotate on a monthly basis and will be chosen by the Juicebox community. Below this section you’ll find a number of categories you choose to find a project that’s right for you.

New Juicy Picks section

Juicy Picks for May 2023


If you still have some questions, make sure to check out the FAQ section near the bottom of the homepage.

Updated FAQ section on Juiebox website

How to get in touch

Last but not least, you’ll see a button at the bottom to contact onboarding. So if you’d like more personalized assistance while setting up your project, reach out via the contact form or join the Discord.

Shoutout to Sage Kellyn from WAGMI Studios for the amazing art and illustrations throughout the website. Juicebox really wouldn’t be the same without it.

New hero illustration for Juicebox website by Sage Kellyn

New hero illustration for by Sage Kellyn

Banny, along with a fruity assortment of new characters have been reimagined to embrace Juicebox’s new brand identity. Paired with a slick sans serif Agrandir, a font that “celebrates the beauty of being imperfect,” the Juicebox brand update keeps the protocol fresh while acknowledging its punk origins.

New About Page

Under Resources in the top navigation bar you’ll find a new About page for Juicebox. Here you can read about our mission statement, goals, learn about about the protocol and Juicebox DAO, the contributors at Juicebox, as well as our values.

New About page on Juicebox

Sections of the new About page on

The Juicebox protocol has grown a lot since its launch in July 2021. From contract versioning and audits to feature developments like tiered NFTs, to metaverse concerts at the Juice Lounge, countless members of Juicebox DAO have shaped what it is today through its active governance. Juicebox doesn’t drink from the kool-aid, it leverages the power of collective action through its community to help passionate creators and builders successfully launch and scale projects, openly on the Ethereum blockchain.

Screenshot of old create flow on

Screenshot of old version of

What are you waiting for, anon? Come explore the world of community-owned DAOs, fundraisers, non-profits, and other projects running on Juicebox today.

🐦 Follow Juicebox on Twitter: @JuiceboxETH

💬 Join the Juicebox Discord

🚀 Trending projects on Juicebox

📚 Project Creator Docs

📹 YouTube Tutorials

· 3 min read

JBX V3 migration guide

Got JBX? This guide is for you!

Juicebox V3.1 contracts are now live and the V3 JBX token has been deployed to mainnet. If you hold V1 JBX or have unclaimed tokens from the Juicebox V2 project, you can now migrate to the V3 JBX token.

V1 JBX token address: 0x3abf2a4f8452ccc2cf7b4c1e4663147600646f66

V3 JBX token address: 0x4554CC10898f92D45378b98D6D6c2dD54c687Fb2

Before you start

Here are a couple things to keep in mind before starting:

  • The migration process will ask you to submit 3 or 4 transactions
  • This process can take 15 minutes or longer
  • You can migrate your tokens over time

The following guide assumes the following:

  • you have V1 JBX and/or unclaimed Juicebox V2 tokens
  • you use Metamask as your browser wallet

Your steps may vary depending on your situation. If you have questions, please visit the Support channel in Juicebox Discord.

Step 1: Navigate to the JuiceboxDAO project

Connect your wallet and navigate to the JuiceboxDAO project:

Step 2: Tokens tab

Select the Tokens tab and refer to the Legacy tokens section. If you have JBX from JuiceboxDAO's V1 or V2 project, you should have legacy tokens. Click Migrate tokens.

Tokens section

Step 3: Grant permission for V1 tokens

Click Grant permission for your V1 JBX and confirm the transaction in your browser wallet.

This transaction grants the V3 JBX contract permission to transfer your JBX on your behalf. If you have V1 JBX, this step is required for migration.

Grant V1 permission

Step 4: Grant permission for V2 tokens

Click Grant permission for your V2 JBX and confirm the transaction in your browser wallet.

This transaction grants the V3 JBX contract permission to transfer your Juicebox V2 tokens on your behalf. If you have Juicebox V2 tokens, this step is required for migration.

Grant V2 permission

Step 5: Approve migration and set spending cap

This transaction approves the V3 JBX contract to spend your V1 JBX on your behalf. If you have V1 JBX, this step is required for migration.

Approve token spend

Click Approve and in Metamask select Use Default. This will approve the spend of your total claimed V1 JBX balance.

Metamask set spending cap part 1

Click Next to proceed and then Approve to confirm the transaction.

Metamask set spending cap part 2

Step 6: Migrate all approved tokens

Click Migrate all approved tokens and confirm the transaction in your browser wallet.

This transaction migrates all approved V1 JBX and unclaimed Juicebox V2 tokens to JBX V3.

Migration final step

Step 7: Success!

Refresh the page and revisit the Tokens tab. Be sure to verify the following:

  • Your balance: should be greater than zero
  • Legacy balance: should be zero

That's it! If you have questions, please visit the Support channel in Juicebox Discord.

· 3 min read

JuiceboxDAO is running final tests on an updated/forked version of its Terminal contract. Once deployed and approved by JuiceboxDAO, projects will be able to voluntarily migrate their funds and accounting parameters from the V1 terminal that is currently being used to this new V1.1 Terminal with just one transaction.

There are many broader changes being developed in a V2 release scheduled for the coming months. V1.1 is a simpler change that still manages to provide crucial utilities and fixes for projects operating on the protocol.

Here's why a project might want to migrate to V1.1:


  • Pause - Projects will be able to pause contributions to their treasury as well as subsequent token issuance on a per-funding cycle basis. Any new transactions – or pending low-gas transactions in flight – that settle after a paused funding cycle has started will fail.
  • Mint - Projects will be able to allow itself to mint more of its own tokens on a per-funding cycle basis. During a funding cycle where minting new tokens is allowed, the project owner can submit a transaction to increase the token supply and send this new supply to a beneficiary of its choice.

Currently projects can only mint new tokens before receiving a first contribution.

  • Burn - Anyone will be able to burn their tokens by redeeming them, even when there is no overflow.

Currently tokens are only burnable when there is some amount of overflow that is being reclaimed through the redemption.

  • Off-protocol redemption value - Projects will be able to supply a contract to their funding cycles that tell the protocol how much value it is holding off-protocol, like in a multisig wallet or yielding vault. Projects can use oracles in this contract to convert the value of any other asset it owns into ETH for the protocol to use when calculating redemption values.

Currently redemption values are calculated only with the ETH the project has locked in the Juicebox Terminal contract.

  • Fee cap - The protocol fee is capped at 5%. JuiceboxDAO can adjust the JBX fee from 0% - 5%.

Currently there is no fee cap.

Bug fixes

  • Fixed bug that prevents a project from updating its reserved token tracker when the reserved rate is set to 0%. This bug prevented the project from reconfiguring from a 0% reserved rate to any other value without inadvertently creating an extra reserved token supply inso-doing. See this postmortem.
  • Fixed bug that prevented overflow from being viewed correctly when a funding cycle rolls over before it has had its newly available funds distributed.

Other adjustments

  • The contract is now directly Ownable instead of using an ownable Governance contract proxy. The JuiceboxDAO will own the contract, which allows it to set the fee, and allow other forked Terminal contracts for projects to migrate onto.

· One min read

Before you start a project on Juicebox V1 or contribute funds to one, understand the following inefficiencies. These are shortcoming of V1 that have imperfect work arounds for now.

  1. There is no pause button. The best you can do is configure the reserves rate to 100% if you do not want to give new contributors any tokens. You can set an address responsible for burning tokens as the reserved token recipient.

  2. When a project's reserved rate starts at 0% and is then reconfigured to be higher than 0%, a new token supply will become available to distribute to the preconfigured reserved token recipients according to the rate chosen. For example, if moved to 100%, the total supply will double. Again, you can set an address responsible for burning tokens as the reserved token recipient. This inefficiency was discovered on August 18th. Here's more.

  3. There is no direct burn transaction, but tokens will be burnt when redeemed. Therefor in order to burn, reconfigure your target such that there is overflow, then redeem tokens and then inject the overflow back into the treasury.

· 2 min read

From the original post:

The simplest option would be to just deploy the same Juicebox protocol in each EVM compatible L2 environment. This forces projects to choose which they would like to operate on, or manage their own complexity if they would like to operate across many. I'm guessing most projects would prefer to operate everywhere, if only it were easy to do so.

What if the simplest option was the best option?

Although deploying the same Juicebox protocol in each EVM compatible L2 environment forces projects to choose which they would like to operate on, it might be most reasonable to pass along this choice and complexity to each project while suggesting thorough operational strategies to weave these isolated environments together at the DAO/social/governance layer.

Here are some potential operational guidelines, using JuiceboxDAO as an example:

  • Juicebox protocol is deployed identically on several L2s and side chains. JuiceboxDAO creates a project on each one where fees will be collected and contributions accepted.
  • JuiceboxDAO will have different tokens on each chain. JuiceboxDAO membership is composed of a strategy that take each of these tokens into account. Members are responsible for managing the entirety of the DAO's treasury across all chains.
  • JuiceboxDAO submits treasury reconfigurations to each chain independently. Each chain can have funding cycles that operate on different schedules, have different token issuance rates, and different ETH distributions. This flexibility can be used to orchestrate arbitrary multi-chain treasury designs, although also introducing management overhead. Extend to new environments responsibly.
  • JuiceboxDAO can move its ETH/tokens between environments adhering to the constraints of each chain, leaning on existing and upcoming generalized bridging infrastructure.
  • It can deploy converter contracts if it wishes to support conversions between each of its membership tokens.

Any other project could choose to operate on one or many environments where the Juicebox protocol has been deployed. If they choose to operate on many, they would have to manage the complexity of doing so. Once projects have begun experimenting and settling on effective patterns, I'd hope a playbook would emerge as a reference for future projects.

Leaving multi-layer coordination for the social layer introduces some operational overhead and risk, but also keeps the protocol layer flexible and simple.

· 2 min read

Projects building on Juicebox need payment terminals that cost its contributors less gas to pay and redeem.

To do so, projects need to be able to accept funds across many different L2s alongside mainnet.

The simplest option would be to just deploy the same Juicebox protocol in each EVM compatible L2 environment. This forces projects to choose which they would like to operate on, or manage their own complexity if they would like to operate across many. I'm guessing most projects would prefer to operate everywhere, if only it were easy to do so.

JuiceboxDAO runs on the juicebox protocol itself, if we do nothing at the protocol layer and go with this simple option we will come across the same dilemma. If instead we preemptively consider how we can adjust the Juicebox V2 protocol to make cross layer operation simple for us, we'll likely also be making it simple for all projects who choose to build around juicebox treasuries.

An effective solution will take into consideration that:

  • projects do not want to fragment its community and governance across chains. All members should be cheering for funds to come in from wherever people care to contribute from, and the project's distributed tokens in turn should provide the opportunity to govern its cumulative funds regardless of what chain they're on.
  • the issuance rate of the project's tokens should be synchronizable across all available environments over time. As funding cycles roll over, it's often the case that the weight of token distribution changes. Unless it is by design, there shouldn't be arbitrage opportunities across chains.
  • funding cycle reconfigurations should either be approved or fail across all environments. If a project proposes to reconfigure its funding parameters in one environment but the ballot to do so ends up failing, the change should also fail to take effect in all other environments. On the flip side, successful funding cycle reconfigurations should be reflected across chains.

Stay tuned for specific proposals from me of how this might be achieve across rollup L2s, and please contribute to the conversation with your own ideas so we can arrive at the best possible set of solutions together.

· 11 min read

Current state of things

First thing's first: a huge thank you to everyone who has played with the first version of the Juicebox protocol over the past month. You've taken a leap of faith on a very experimental and untested set of contracts and user experiences with the hopes that it would help you smoothly realize your vision. The protocol has helped a number of projects bootstrap their treasury and community, and these communities have in turn helped Juicebox root into the fertile soil that is the Ethereum social layer.

I've been observing how each project has been interacting with the protocol. I've been a part of exciting discussions where JB was a total enabler of ideas and creativity, and also ones where I've unfortunately had to be the bearer of bad news that the protocol doesn't support the wild thought being proposed. I've seen people spin up projects and raise hundreds of ETH in hours, and seen people give up on the first screen because the "button" they were trying to click wasn't actually a button. After only a few weeks of action I have a sense of what's working, and I've got a laundry list of what could be better.

The goal is to steadily improve things over time. At the base contract layer however, progress must made in big leaps initially with the goal of eventually reaching a steady state as innovation moves to subsequent application layers. JuiceboxV2 is the first big leap. Its goal is simple: to enable more creativity, and remove all points of friction.

JuiceboxV1 was designed with the assumption that communities and project owners have adverse incentives. By using Juicebox, a project owner was committing to particular constraints so that their community could confidently embrace the finances of the game being proposed. Project owners could not mint or burn tokens at will, project owners could not dictate how many tokens were minted per ETH contributed, project owners could not limit who participated in a crowdfund, and project owners did not have a pause button.

Turns out this was a bad assumption to roll with at the base protocol layer. If a community and its owners are one and the same, flexibility is a requirement for total creative expression. It turns out that communities almost always crave a custom treasury strategy that fits their ethos and proposes a game that differentiates them from others.

Projects don't usually have the engineering resources to build, test, and verify such solutions though. This has been a core value Juicebox has provided for people, along with a simple and powerful UI for community members to join in through and follow along with. So far, the frictions that Juicebox removes has justified the treasury strategy constraints that it introduces.

Let's see if we can now do even better.

Proposed changes

Bring your own mint/burn strategy

You'll now be able to bring your own contracts that outline the game you want to propose to your community. You'll be able to plug and play with already-written strategies, or write your own custom one that fulfills your wildest ideas.

Writing a strategy can be simple, or as complex as you want. All that is required is providing a contract that adheres to the IFundingCycleDataSource interface. You'll be able to provide a strategy that decides what happens when someone makes a payment to your project, as well as one for when someone redeems their treasury tokens.

Here's how writing a strategy around a payment works:

You can add a data source contract as a parameter to a funding cycle. Your data source must provide a function that implements the following function specification.

function payData(
address _payer,
uint256 _amount,
uint256 _baseWeight,
uint256 _reservedRate,
address _beneficiary,
string calldata _memo
returns (
uint256 weight,
string calldata memo,
IPayDelegate delegate

The function receives a handful of parameters from the Juicebox protocol, and is expected to return a handful of parameters back.


  • _payer is the address that issued the ETH payment.
  • _amount is the amount of the ETH payment received.
  • _baseWeight is the weight of the funding cycle during which the payment is being made. This weight is determined by multiplying the previous cycle's weight by the previous cycle's discount rate. Each project's first funding cycle's weight is 10^24.
  • _reservedRate is the reserved rate of the funding cycle during which the payment is being made. This percent is out of 200.
  • _beneficiary is the address that the payer has specified to receive the resulting treasury tokens.
  • _memo is the note that the payer has included in the payment.


  • weight is the weight that the Juicebox protocol should use when minting treasury tokens. The total tokens minted will be amount * weight, where both variables are assumed to have 18 decimal places. Out of these minted tokens, some will be allocated to the _beneficiary, and the rest will be reserved to be distributed to the reserved token recipients according to the _reservedRate.

  • memo is the memo to include with the protocol event that will be emitted as a result of the payment.

  • delegate is the address of a contract that adheres to the IPaymentDelegate interface. If a delegate is provided, it will receive a callback from the Juicebox protocol once it has fully processed the payment. You can return the zero address if you don't need this functionality. The callback your delegate contract should implement is as follows:

    function didPay( address _payer, uint256 _amount, uint256 _weight, uint256 _count, address _beneficiary, string calldata memo ) external;

  • _payer is the same as the one passed in to your data source.

  • _amount is the same as the one passed in to your data source.

  • _weight is the same as the one returned from your data source.

  • _count is the number of tokens that were minted for the _beneficiary.

  • _beneficiary is the same as the one passed in to your data source.

  • _memo is the same as the one returned from your data source.

The recordPayment function where all of these pieces come together can be found here.

A data source and delegate can similarly be provided to your funding cycle that'll shape the recordRedemption function:

function redeemData(
address _holder,
uint256 _count,
uint256 _redemptionRate,
uint256 _ballotRedemptionRate,
address _beneficiary,
string calldata _memo
returns (
uint256 amount,
string calldata memo,
IRedeemDelegate delegate


  • _holder is the token holder that is redeeming.
  • _count is the number of tokens being redeemed.
  • _redemptionRate is the redemption rate of the funding cycle during which the redemption is being made.
  • _ballotRedemptionRate is the redemption rate that should be used if the project currently has an active funding cycle reconfiguration ballot.
  • _beneficiary is the address that the redeemer has specified to claim the treasury ETH as a result of redeeming tokens.
  • _memo is the note that the redeemer has included in the redemption.


  • amount is the amount of ETH that should be sent from your treasury to the _beneficiary as a result of redeeming/burning _count tokens.

  • memo is the memo to include with the protocol event that will be emitted as a result of the redemption.

  • delegate is the address of a contract that adheres to the IRedemptionDelegate interface. If a delegate is provided, it will receive a callback from the Juicebox protocol once it has fully processed the redemption, but before the amount is dispersed to the _beneficiary. You can return the zero address if you don't want this functionality.  The callback your delegate contract should implement is as follows:

    function didRedeem( address _holder, uint256 _count, uint256 _amount, address _beneficiary, string calldata memo ) external

  • _holder is the same as the one passed in to your data source.

  • _count is the same as the one passed in to your data source.

  • _amount is the same as the one returned from your data source.

  • _beneficiary is the same as the one passed in to your data source.

  • _memo is the same as the one returned from your data source.

The recordRedemption function where all of these pieces come together can be found here.

With these new tools projects can roll out all kinds of treasury strategies, such as:

  • restricting payments to only certain addresses.
  • restricting payments to only addresses that hold certain other assets.
  • offering different levels of  community membership depending on the state of the blockchain.
  • restricting payments to be within min/max payment amounts.
  • creating time weighted rewards.
  • restricting the max supply of community tokens.
  • customizing the amount of treasury tokens distributed per ETH received.
  • minting NFTs for new members.

...or any combination of any of these, alongside any other rule you can express contractually.

Overflow allowance

Previously, a project could only access funds within its specified funding cycle target. All overflowed treasury funds over this target was only accessibly by treasury token holders.

Now, alongside specifying your funding cycle's target, you can specify an amount that you can use from your project's overflow on demand.

This is useful for allocating treasury funds for on-off use cases like bug-bounties, one-time contributions, audits, NFT bids, etc.

Open mint/burn

Previously, you could only mint tokens before receiving your first payment, and burning was only done through the redemption mechanism. All other tickets were distributed purely through the payment process according to funding cycle weights that decreased according to your configured discount rates over time.

You can now mint and allocate new treasury tokens at will. All token holders also now have the option to burn their tokens, for whatever reason.

This gives projects more flexibility to design their tokenomics the way they want, while also having an auto-distribution mechanism through Juicebox's flexible built-in payment mechanism alongside.

Reserved token distribution endpoints

Previously, payout splits could be directed at Ethereum addresses, other Juicebox projects, and arbitrary contracts that inherit from a common interface. Reserved tokens could only go to Ethereum addresses.

Now, reserved token distributions can also be pointed at Ethereum addresses, the owner of other Juicebox projects, and arbitrary contracts that inherit from this common interface.

This is useful to allow for more composable token distributions.

Pay, withdraw, and redeem can all be paused.

Previously, projects had not quick way to pause community interactions with its treasury.

Now, projects are able to individually pause function calls to pay, withdraw funds, and redeem tokens. These controls are configured into each funding cycle.

This gives projects quick levers to use to achieve certain treasury effects.

Adjustable fee

Previously, all projects paid a 5% fee from payouts.

Now, projects will pay at maximum a 5% fee that is adjustable by the JuiceboxDAO. There is also a ceiling fee price that is adjustable by the JuiceboxDAO.

This helps the JuiceboxDAO accommodate more projects and experiments into its ecosystem.


JuiceboxV2 introduces a suite of tools that allow for wild new treasury strategies. What remains constant from V1 is the fact that configurations are locked into funding cycles – if a project runs on 30 day funding cycles, they can specify creative dynamics into the funding cycle, but once the cycle begins changes can't be made until the following one. Also like V1, projects that opt for no duration are choosing the flexibility to make any change on demand.

The implementation of the new contracts is done, we've just now got to document, test, and audit everything. All code is public, as will be all documentation and conversation around this upgrade.

We need eyes and scrutiny. Please don't hesitate to take a look and help pick things apart. If you plan on spending time on this, please reach out to the DAO in our discord and introduce yourself so we can make sure you're rightly compensated for your work.

All projects currently running on Juicebox will be able to seamlessly migrate their treasury to V2.


· One min read

The Juicebox contracts were deployed to Ethereum two days ago. Yesterday, @peripheralist, who built the website, launched a generative art project called Tiles using the Juicebox protocol as its treasury, He started a DAO around it,

With Juicebox, we had built a business-model protocol. With Tiles, he built a beautiful, expressive, and flexible collection of generative art to rally a community around. Neither of us had much of an idea what would or should happen next, but I was excited to take a step back and find out.

My conclusion: From a growth perspective, we can either go out and look for more entrepreneurs and artists that could benefit from using Juicebox, or we can lean into TileDAO since it's the one project that currently uses Juicebox. Since building stuff > shilling stuff is an invariant for me, I think the best thing I can do right now as a $JBX token holder is to participate in TileDAO and help grow it. As other projects start considering building on Juicebox, our job will be to become supporting cast member of their community also.

· 5 min read

The first of a series of blog posts explaining the Juicebox protocol, and the game plan for the first several months.

TLDR: The Juicebox protocol's contracts have been deployed to Ethereum's mainnet, and @peripheralist has published a very slick site to interact with them.

Juicebox is a business-model-as-a-service and programmable treasury for community-owned Ethereum projects.

Go check it out at You can begin using Juicebox as your project's payment terminal with one gas-efficient transaction. A project running on Juicebox.


Long story short: indie artists and devs, DAOs, and public goods more generally, need a groovy way to capture the value they create, make reliable cashflow money out of it, and then share it back into the world.

The Juicebox protocol does this by allowing projects to make commitments about how its cashflow will be distributed before ever receiving payments, signaling to users how their money will be spent ahead of time. It works really well as a payment terminal and programmable treasury for projects that have mostly predictable costs (like staff payouts, service subscriptions, donations, budgeted initiatives, etc.), and who want to automatically reward their community as they become successful.

How it works

With just one gas-efficient transaction, you can start funding and growing a Juicebox project, and configuring its treasury's payouts.

Once deployed, anyone can fund your project either as a patron by making a payment directly through, or by using other contracts that take fees composably into the Juicebox protocol. Either way, they'll receive your project's community tokens in return. People can pay you directly via an interface like, inherit from JuiceboxProject.sol and use _takeFee to get paid contractually. As the project owner, you can set a funding target that specifies how much it'll cost to create and operate your project for a set amount of time. You do this before anyone sends you money. If your project earns more than its funding target in a set period of time, the overflow can be redeemed by your supporters alongside you in exchange for burning tokens. This effectively pushes everyone's price to pay for your project towards zero as usage grows.

If left unclaimed, overflow serves as a runway for projects.

A project's team and its community are thus incentivized to work together to make sure overflow growth outpaces spending. Funding cycles roll over automatically, allowing people and contracts to affordably fund projects that are important to them on an ongoing basis.

You can configure a discount rate to incentivize earlier adopters, a bonding curve rate to incentive commitment from community members, and a reserved rate to receive some of your own tokens each time someone pays you and receives tokens themselves. Project owners can re-asses their funding needs and cycle configuration over time, and can choose to take their token holders' perspectives into account while publishing these sorts of changes to Juicebox.

There are several ways to configure your Juicebox projects. Here are few cool things you can do:

  1. You can route your income stream through the Juicebox contracts. For example, you can make a version of Uniswap that explicitly only needs $X per month to be sustainably run (labor, ops), where each swap transaction incurs a fee ($Y) that goes towards sustaining the service. If there are enough swaps that month (N) such that N * $Y > $X, then for each subsequent swap, all accounts that have swapped (and therefor paid fees) receive a dividend from the overflowed revenue that is proportional to the amount they've contributed to the project's sustainability thus far. So if N * $Y grows unjustifiably faster than $X — which is the underlying market rent-seeking inefficiency that Juicebox projects try to out-compete — then instead of compounded shareholder wealth aggregation, everyone's price tends towards zero. Meaning people get a nearly-free, community-driven product with no ads, guaranteed data integrity, full business operation accountability, and an open source code base that runs reliably. All built by motivated punks that are getting paid what they ask for and are rewarded alongside the community as overflow grows.
  2. It's easy to program financial dependencies, so your Juicebox project's funding target can be contractually hooked up to those of people and projects it depends on.
  3. You can run a recurring/one-time fundraising campaign and return extra funds to your community, or to other causes.
  4. As the project owner, you can earn some of your own tokens with every payment you receives. You'll "unlock" these tokens at the rate with which your overflow grows, not according to some arbitrary multi-year vesting schedule. These reserved tokens can then be contractually distributed to staff, or to other causes.

There's nothing more exciting than working on/with/for the Ethereum ecosystem these days – new artful minds are being welcomed into cryptowallet-life everyday, and brilliant experiments are being crafted on the regular. It's a creator's dream – there's no need to manage infrastructure,  growth is driven by your community, and financial expectations can be anchored down by code. The Juicebox protocol was created as a means to further this end.

If you have questions or want to contribute, don't hesitate to hop into the Discord.