Skip to main content

9 posts tagged with "protocol"

View All Tags

· 3 min read
Jango

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:

Features​

  • 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
Jango

Communities using Juicebox can leverage their reserved rate decisively when they want to make it more difficult for new members to join. Funds can still be received, but more of the newly minted tokens will be owned by the project itself. The current project members can use this to decide how they will manage their subsequent growth on a per-funding cycle basis.

When the project wishes to make membership more accessible again, members can do so by lowering the reserved rate.

There's currently a discussion happening in JuiceboxDAO deliberating if it might be wise to move its reserved rate from 35% to 50%.

The reserved rate can also be useful for other purposes, this is just one possible metaphor that can be used to guide decision making.

· One min read
Jango

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
Jango

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
Jango

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
Jango

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
)
external
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.

Inputs:

  • _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.

Outputs:

  • 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
)
external
returns (
uint256 amount,
string calldata memo,
IRedeemDelegate delegate
);

Inputs:

  • _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.

Outputs:

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

Conclusion​

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.

LFG.

· 7 min read
Jango

I discovered a low severity bug in the Juicebox protocol last night that affects projects that have received payments while configured with a reserved rate of 0% who later reconfigure the reserved rate to anything greater than 0%.

A temporary work around has been identified, and a game plan for removing the bug from the system is in the works.

To mitigate potential exploits before a patch is issued, an exploit breakout team decided to mint 0.5% of total SHARK supply (1,889,066.675747 SHARK) into the multi-sig wallet. This course of action was chosen to prevent further issues. These tokens can be burned if desired.

What follows is how I discovered the bug, the technical details about it, and what our next steps will be.

TLDR:**Until further notice, projects are not advised to set their reserved rate to 0% if they intend to raise their reserved rate in the near future.**


Context​

To give them time to plan for for what's next, SharkDAO needed a way to pause payments and new members coming in through Juicebox. Juicebox doesn't support a pause function in its TerminalV1 contract, so Peripheralist and I had to improvise alongside the SharkDAO community. First step was to remove the payment form from the UI. This keeps most people from sending in contributions, but someone dedicated to sending a payment would eventually find that the Juicebox contract could still be interacted with directly through other interfaces like Etherscan.

To even the playing field, I had the idea to raise SharkDAO's reserved rate to 100%, meaning all payments coming in through the contract would allocate 100% of minted SHARK tokens to preprogrammed addresses instead of to the paying address. With no SHARK incentive for contributing payments, the community would be disincentivized to pay through back-door means, effectively creating the desired pause functionality. If anyone did send payments, we could easily refund them the money.

After running this plan by SharkDAO at a Sharktank town hall meeting, we decided to move forward with it. We would allocate any SHARK minted during this paused period to the multi-sig, which could later be burned if needed.

A few details to note:

  • SharkDAO's reserved rate has been set to 0% since its start.
  • SharkDAO does not use funding cycles with preset durations, meaning changes can be executed on-demand.
  • SharkDAO's Juicebox project is owned by a Gnosis multi-sig requiring 3/5 signatures. I'm one of the signatories.

Right after the call, I got together with multi-sig holders to execute the plan. After one transaction to TerminalV1's configure function, the reserved rate was successfully updated. I immediately checked the UI to see if things were in order – thats when I noticed that after having set the reserved rate to 100%, it was now possible to mint and distribute 100% of the current token supply to the preconfigured destination (the multi-sig). Since this distribute transaction is public, anyone who triggered this would effectively double the SHARK supply, and would leave us with unnecessary work after the fact to burn this unintended supply from the multi-sig and communicate the issue to the community.

I immediately instructed the multi-sig panel to send another configure transaction to TerminalV1 to change the reserved rate back to 0%, and explained that I had to double check something before we could move forward with the plan. This reverted us to the previous state, where payments made to the contract directly would bypass the intended pause that was being communicated in the UI.

Technical details​

The root of the problem was fairly obvious to me once I noticed the distributable supply in the UI. Once we were back at a safer state, I began work to confirm my assumptions and test a workaround.

Many parts of the Juicebox mechanism's design are gas optimized, meaning the transactions that are most frequently called are responsible for fewer state changes than those that are infrequently called. The pay transaction is by far the most frequently called, so very few state changes take place within this function: the payment is received, and the resulting amount of treasury tokens are minted to the payer in a staked format.

Importantly, the reserved token amount is not minted during a payment. Instead, this amount is calculated later when the printReservedTickets transaction is called. It does so by taking the current token total supply and minting an appropriate amount of new tokens to the preconfigured reserved addresses such that the reserved rate is respected. Most importantly, the mechanism then keeps track of the fact that it has minted reserved tokens for the current token supply so that it doesn't create extra reserved tokens later. Given perfect information, it is in the economic best interest of the project to wait to call printReservedTickets if the reserved rate is going to increase, and in the community's interest to call it before an increase. The opposite is also true. This dynamic allows the protocol to offload a high-gas storage operation from a frequently called pay function onto less frequently called operations.

Unfortunately, when the reserved rate is 0%, the printReservedTickets call assumes there's no work to do, and returns before it has had a chance to update the tracker. This prevents anyone from locking in the rate before it is increased. In the TerminalV1 file, the solution is literally just putting line 968 below line 977:

Current TerminalV1 implementation of printReservedTickets

Execution​

I immediately proposed two workarounds to the SharkDAO admins:

  • Keep the contract open.
  • Set the reserved rate to the minimum possible value (0.5%), distribute the allocated reserved tokens to the multi-sig, then move the reserved rate to 100% as intended.

We decided to go with the second option since we needed to set a fair playing field to community members looking to pay, and we could later burn the relatively small amount of SHARK minted to the multi-sig.

I then spent a few hours recreating the the original bug in our integration test suite, and wrote an integration test for the proposed solution to confirm it would work as expected (I was making extra sure of everything at this point in the evening.) Once everything was confirmed on my end, I got together with the multi-sig holders to execute the three transactions:

  1. Change the reserved rate to 0.5%.
  2. Distribute reserved treasury tokens to the multi-sig. (Anyone can trigger this, so Xaix did it from his personal wallet.)
  3. Change the reserved rate to 100%.

The side effect is that 1,889,066.675747 SHARK were minted to the multi-sig. Here's a screenshot of what the UI looked like after step 1:

And here's what it looks like now: We got all of this done in about 2.5 hours.

Takeaway​

Despite having written extensive unit, integration, and load tests, this condition fell through the cracks. I will keep stressing to the community that Juicebox is still experimental software with high risks. I'm confident in the way it's built and am committed to its improvement, but I'm not going to pretend that it is perfect.

The good news is that TerminalV1 has a built in mechanism to allow projects to choose to migrate to new terminal contracts that have been approved by JuiceboxDAO's governance, so bugs like this can be fixed.

We are now working around the clock to get a TerminalV1_1 safely set up for migration, and extensively tested.

In the meantime, projects are not advised to set their reserved rate to 0% if they intend to raise their reserved rate in the near future.

Next steps:

  • Deploy TerminalV1_1 that patches this bug.
  • Consider building a version of the Juicebox Terminal contract that supports pausing payments.
  • Seek more code reviews and audits, while offering bug bounties to hackers who want to help.

· One min read
Jango

The Juicebox contracts were deployed to Ethereum two days ago. Yesterday, @peripheralist, who built the juicebox.money website, launched a generative art project called Tiles using the Juicebox protocol as its treasury, http://tiles.art. He started a DAO around it, https://discord.gg/bgGwmjWJ85.

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
Jango

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 juicebox.money. You can begin using Juicebox as your project's payment terminal with one gas-efficient transaction. A project running on Juicebox.

Motivation​

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 juicebox.money, 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 juicebox.money.Or, 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.