The first JuiceboxDAO configuration includes a discount rate of 20%.

This means that a contribution made to the JuiceboxDAO project during this funding cycle will mint you 20% more tokens than a contribution of the same value made during next funding cycle.

The Juicebox protocol supports discount rates from 0%-20%. The rates are compounded over time, meaning a constant rate of 10% over two funding cycles would make the relative discount between contributions on either end 81% (10% of 100 is 90. 10% of 90 is 9. 100 - 10 - 9 = 81).

The discount rate is mega powerful and has lasting effects. It should not be used arbitrarily.

Our reasoning for going with the max of 20% is that there's inherently much more risk to funding the project at its onset – the protocol is raw and untested in the wild, there are no trends to latch on to for financial speculation, and there are lots of unanswered questions still floating around. Any contributions made during this funding cycle are risky. We wanted to reward them as much as possible.

We plan on proposing a reduction of this rate to 10% for the next funding cycle, 5% for the following cycle, and settle on a constant rate of 0.5-3% from then on to keep a slight constant pressure to fund the project sooner rather than later. Expect this schedule to be reevaluated over time, but the philosophy behind its purpose as a risk offset to hold true.

Notice: Each project built using the Juicebox protocol as its treasury pays a standard 5% fee from its payouts to the JuiceboxDAO. This fee is treated like every other payment made, so each project receives JBX tokens in return. The discount rate thus also gives projects an incentive to compose with Juicebox sooner rather than later.

A question was posed in the Juicebox Discord server earlier today from @jessewldn:

I’m curious if you’ve thought about if/how Juicebox projects might intersect with VC financing where there’s a large amount of “permanent” runway parked in one go that can’t be recalled. Do you think that’s just overflow, or is there a way to fine tune things to accommodate a project that wants to raise from a fluid/liquid community and from longer term investors simultaneously?

TLDR answer: just stick money in the protocol for the specific project. The system works the same for everyone.

This question deserves a more colorful answer though.*

• Everything that follows is theory. I'd love to experiment with these ideas in practice, tuning parameters over time until we strike the right balance for both the big fish involved, the apes, the punks, the creators, the devs, and every other Etherean.

Also must note that Juicebox is experimental software. I did everything I could to thoroughly blast the protocol with tests, including regular, edge case, and randomized conditions. Formally however, it's still unaudited. Put money in the contracts at your own risk.

Primer​

The Juicebox protocol is meant to support small projects with big ambitions, alongside large projects that want to involve their day-to-day users/community in its growth efforts and outcomes. Meanwhile, it's meant to give patrons and investors of various risk profiles confidence over their spending and their financial positions.

A project is able to evolve by tuning its funding cycle configurations over time to calibrate incentives and investments. Specifically, a project has a funding target, funding cycle duration, a reserved rate, a bonding curve rate, and a discount rate at its disposal. Changes to these are made over time with the approval of a ballot contract that can be implemented with whatever governance/representation structure a project and its community want.

The funding target determines how much money a project can withdraw during each funding cycle, the length of which is determined by its funding cycle duration.

Each payment made to a project mints and distributes the project's tokens for the payer, and allocates a reserved percentage (reserved rate) of tokens for a set of addresses preprogrammed by the project owner. The total amount of tokens that get minted as a result of a payment is influenced by its configured discount rates over time, which incentivizes earlier contributors who naturally are assuming more a bit more risk. All funds that are received by a project that exceed its funding target are considered overflow. This overflow serves both as the project's runway and its community's treasury. Each token holder has an option over this overflow that they can exercise by redeeming (burning) their tokens.

The project can configure a bonding curve rate that affects how much overflow each token can claim – a rate of 100% allows X% of tokens to be redeemable for X% of overflow, whereas one of 50% allows X% of tokens to be redeemable for about (0.5 * X)%, leaving the rest to share between their token hodlers.

Lastly, a project can mint a supply of premined tokens if it hasn't yet configured a funding cycle or received a payment.

Look through juicebox.money, visual technical docs, and other blog posts for a more in depth primer of these controls 🎛.

Scenarios​

Back to the original question: how might big money involve themselves in Juicebox projects?

The answer is to just stick money in the protocol for the specific project. The system works the same for everyone.

Let's play out an example to see what might happen if someone wanted to dump an investment into the JuiceboxDAO. JuiceboxDAO from Jango's perspective at the time of this writing Let's say someone parks $1 million here. My screen would then look more like this. JuiceboxDAO from Jango's perspective after a $1 million (~434 ETH) payment. Here's what changed:

1. There is more overflow.
2. More tokens got minted, 10% of which were allocated for distribution to the reserved token recipients.
3. The newly minted tokens were added to the total supply, which decreased my JBX ownership percent from 42% to 5.9%. Not pictured: the payer now owns 71% of JBX supply.
4. The payment would feature on the activity feed.

Facts about this new state we would find ourselves in:

• The project's treasury now has more money to work with, which can represent a longer runway (more time) or an opportunity for larger and more diverse payouts/investments (more impact).
• With a bonding curve of 60%, the payer could redeem their 71% of tickets right away for about $644,000 (280 ETH). This amount would increase as payments are made to the project at different discount rates over time, or if other holders decide to redeem their tickets ahead of the payer. However, this amount will decrease if the project burns through funding cycles at a faster rate than overflow grows. Heres a tool to model the Juicebox bonding curve. o is the current amount of overflow, s is the currently total supply of tokens, and r is the bonding curve. The x-axis is the amount of tokens being redeemed, and the y-axis is the amount of overflow that can be claimed by redeeming the x-axis amount.
• The payer has an outsized majority of tokens (71%). If JuiceboxDAO uses a funding cycle ballot that is decided with a simple majority and relies only on JBX ownership for representation, the decision will hinge on the point-of-view of the payer. Ballots can be designed to avoid this, but it also kind of makes sense that any revised configurations that might allocate the $1 million would have to be approved by the person who contributed the $1 million.

Strategy​

If you're a whale, I think you want to bet on the Juicebox ecosystem as a whole more-so than any one particular project. Everything will have more value if several promising ideas are turning into funded project's playing within the Juicebox configuration design space to grow their communities.

A project can configure Juicebox is many ways. A project with a 0% discount rate, 10% bonding curve, a 10% reserved rate, and a 50 ETH funding target proposes a very different game from a project with a 20% discount rate, 100% bonding curve, 50% reserved rate, and 10 ETH funding target. Lots of interesting configurations are possible within these gradients, and there's no way for a project to know what the best one will be ahead of time. There's hardly any precedent or data to make decisions from yet, so each project/community gets to experiment and find something that is efficient for its needs.

As an investor, this is grounds for high risk experimentation. If you think a project is promising and want to give it $1 million, you should probably:

• be aware of its configured reserved rate.
• get a feel for the project's discount rate and how it has changed since the project's launch. This will help inform you of how your token balance will compare to the total token supply.
• understand the project's bonding curve rate to get a feel for how liquid your position will be.
• know how the project has configured its funding cycle ballot, which determines who holds the power to enact new funding cycle configurations (rug pulls totally possible).

All of this is also true for apes 🦧, but they probably put money in before reading this.

Punks 👾 get to build culture and communities on top of a transparent web of interdependent people and projects getting paid what they are able to ask for.

Creators 🎨 and devs ⌨️ get to work on the projects they like, or instead launch their own. They get paid what they are able to ask for from their communities.

Every Etherean 🇪🇹 essentially gets paid as they transact through web3 protocols and (unintentionally) contribute to the growth of that protocol's project's community's treasury at that particular point in time.

Closing thoughts​

If someone contributed a fat stash into the JuiceboxDAO treasury right now and we were to expand the monthly target to accommodate more spending, I can think of many many things for us to allocate funds toward. For one, we could pay someone to help us write searchable, understandable, and inviting technical docs. We could also pay someone to help us write docs. I think we should even consider paying someone a respectable payout to come onboard to write docs.

The first JuiceboxDAO configuration includes a preprogrammed reserved JBX rate of 10%, with distributions to predetermined recipients.

A new supply of JBX is minted each time the project receives a contribution. This JBX goes to a beneficiary address specified by the contributor (usually themselves), with the exception of the reserved tokens. A 10% reserved rate means 10% of these newly minted tokens will be distributable to preprogrammed recipients.

As a result, the configured recipients "vest" their JBX at the rate of the project's growth instead of a cliff/lock schedule. Screenshot from https://juicebox.money/#/p/juicebox

Investors​

• Jango gets 40% of reserved tokens for architecting the mechanism, writing the contracts, thoroughly testing the ecosystem, leading design and development efforts post-launch, and leading project relations.
• Peripheralist gets 40% for architecting the front-end repo, publishing juicebox.money, and leading front-end dev work post-launch.
• AtomicMieos gets 10% for experimenting with content, and helping shape ideas pre-launch and post-launch.
• Sage gets 10% for design and illustration work pre-launch and post-launch.

These numbers are all a bit arbitrary. We decided to start off fairly small and fairly even – it was unclear how the risk profile of pre-launch dev work would compare to post-launch growth and refinement work, and how the Juicebox incentives mechanisms would play out in the wild. As the first funding cycle unfolds, expect a proposed reevaluation of these numbers to better account for risk dynamics and incentives.

The first Juicebox configuration for the JuiceboxDAO lasts 30 days, and includes preprogrammed payouts. They are as follows:

Staff​

• Jango gets $5k for managing contracts and leading dev and design efforts.
• Peripheralist gets $5k for leading front-end dev work and evolving Juicebox to suit needs being uncovered at TileDAO.
• AtomicMieos gets $1k for experimenting with content, and helping shape ideas.
• Sage gets $1k for design and illustration work.

Ops​

(These funds all get paid-out to the JuiceboxDAO governance to be allocated)

• $6.8K to pay back Jango for pre-purchasing juicebox.eth, jbx.eth, and jbox.eth. These ENS names will be transferred to JuiceboxDAOs governance.
• $1k will be allocated for content / art supplies, managed by Futurenate and Sage.
• Figma costs $75 monthly.
• Infura costs $50 monthly.
• Gitbook costs $32 monthly.
• Fleek costs $10 monthly.

The total is $19,967.

The staff payout sums are small compared to market rates for these skills. We decided to start off with a small budget during the first funding cycle to encourage a longer runway, and to be able to re-evaluate needs as the first funding cycle plays out.

Stay tuned for a report on the first funding cycle's spending, and a proposal for the next funding cycle's payouts.

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.

The founding contributors pre mined JBX tokens to backpay the contributions made. The valuation of each token was the same as it is now during the first funding cycle.

• Jango got $125k for developing and testing the smart contracts.
• Peripheralist got $125k for writing juicebox.money.
• AtomicMieos got $10k for always being around to help shape ideas.
• Sage got $7k for design and illustration commissions.
• Nervetrip got $3k for helping to write an early prototype and do code reviews.
• Austin Griffith got $3k as a thank you for his work on Scaffold ETH, which Juicebox is built using.
• Paul Razvan Berg got $3k as a thank you for writing and testing solidity helper libraries that I used extensively. Especially for math operations on e18 numbers.
• Teddy Wilson got $1k for submitting a very useful PR that automates test routines.
• Apoorv Lathey got $200 for a small PR he made to the repo when the code was just getting started.

The numbers are a bit arbitrary, but hopefully enough of you think its a fair start. If not, theres no shame is speaking up. We can always make changes to our reserved token allocation in upcoming funding cycles to rebalance pre mine compensation.

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.