Three trends have characterized these past 30 days:

• Several projects were spun up on Juicebox, entrusting the protocol to manage their money, and the JuiceboxDAO staff to help execute their treasury decisions. Several more reached out with plans to launch soon.
• People came together to help crowdfund JuiceboxDAO alongside the fees paid by the first batch of projects. They all took on the laid-out risks and lent us their trust.
• Some very talented, caring, insightful, passionate people showed the fuck up and want to build.

It may ultimately be too early to tell, but it seems we might have not only found product market fit, we've found it across several different treasury use cases: DAOs that ship products (JuiceboxDAO, TileDAO), DAOs that collect NFTs (SharkDAO), boutique service shops (WAGMI Studios, CanuDAO), NFT galleries, and group bidding. There are still several improvements to make for each of these treasury use cases while maintaining a cohesive experience, and I see clear potential for even more diversity of ideas.

We are a little over 30 days in, this is just the beginning. I'm confident the Juicebox protocol can stretch much, much further.

---

Focus​

As a DAO, we should consider focusing on the following areas:

• Risk mitigation | make sure things don't go to zero. current lead: jango, exekias

• **UX improvements **| improve and make templates for project onboarding and the project dashboard. current lead: peripheralist

• Project support, education, & docs | make sure JB projects have the resources they need to get started and thrive. current lead: jango, natimuril, WAGMI Studios, CanuDAO

• Analytics | give projects rich insights into their community treasury. current lead: peripheralist (, Buradorii?)

• **Liquidity pools **| add support for JB treasury tokens in secondary markets. current lead: exekias

• Marketplace | give JB projects a place to sell digital goods (and physical?) which pipe percentages of revenue to any number of addresses and juicebox treasuries. current lead: jango, nicholas, peripheralist

• Governance | plan out how we will make decisions together. current lead: zheug (, unicornio?)

My proposal for FC#3:​

Duration: 14 days (no change) I think we can find a nice pace with 14 day funding cycles. Let's stick with this.

Ballot: 7 day buffer (no change) A reconfiguration proposal must be submitted 7 days before the end of the current funding cycle. I think we can get the hang of having the opportunity to vote on proposals every other week, with decisions made one week prior to them taking effect.  This time frame is only possible thanks to CanuDAO, who's staff is managing our communications and operations. They've done a marvelous job getting things organized and keeping everyone on the same page.

Discount rate: 10% (-6%) The discount rate should be further reduced by 6%. This is arbitrary, but it continues to give those who commit funds during FC#3 a good discounted rate to adjust for the risk of being early while continuing the process of tapering the rate off.

The goal is to reduce the rate over time as risk subsides (code risk, infrastructure risk, usability risk, organization risk, governance risk).

It pays to be early and to take the risk sooner rather than later.

Bonding curve: 60% (+-0%) No need to change this. Still arbitrary, but there's no demand to redeem right now, so might as well keep it this tight as we adjust the discount rate.

**Payouts: **$71k total (including $40k bug bounty that could be returned if unused)

I propose we raise the target to properly hire the people and projects who are already showing up and making things flow and grow, and experiment with payouts to a few up-and-coming contributors.

This also allows core contributors to embed themselves in the communities of emerging projects built with Juicebox and have cash-on-hand to support those they believe in. Actively supporting these communities is everything.

Core contributors

• **jango **| dev: $10k Lead.
• **peripheralist **| dev : $10k Peripheralist has not only built the Juicebox website and been improving it since launch, he also successfully launched TileDAO around a gorgeous art project he wrote. He's got first hand experience leading a community and business around a Juicebox treasury. There's no better dev to have on board.
• **CanuDAO **|comms:$2.5k Since CanuDAO's staff, zeugh and mvh3030, joined our community and gotten to work, everything seems to be running smoother. They keep our Discord organized, help with community onboarding, make sure everyone is heard and treated with respect, and makes sure the rest of the contributors can continue working towards what's ahead.

This payout is an investment in CanuDAO, we'll get their juicebox project's treasury tokens in return.

• **WAGMI Studios **| art, animations, and educational content: $2.5k WAGMI Studios is working towards putting out art, animations, and visual assets that strengthen and add color and character to the concepts that we're working on. This will increasingly important going forward as we reach beyond a crypto-native audience.

This payout is an investment in WAGMI Studios, we'll get their juicebox project's treasury tokens in return.

Experimental contributors

• **exekias **| dev : $3k Since Juicebox's launch, exekias has helped write infrastructure contracts for piping marketplace royalties back to Juicebox treasuries, helped with dev ops, and helped tease out complex ideas out with the rest of the team. More importantly, he launched WikiTokenDAO – he has first hand experience with dev onboarding onto Juicebox, getting a Juicebox treasury funded, and building a community around it. We want him on our team.
• nicholas | dev: $1.5k We need someone who can help us create a generalized NFT marketplace template that pipes a project's sales into Juicebox treasuries. This has emerged as a need for several projects in the ecosystem. Nicholas has been working on a product called NFTstory for the past several months and is intimately familiar with the ERC-721 standard and how it can be improved and extended. He's expressed interest in working with me to take this project on, he just might be the perfect dev for it. Let's see how things go.
• **natimuril **| project support: $500 Projects that are building on Juicebox tend to need someone to be available for questions, ideation, and support. Natimuril will start helping us out with need, and eventually take on the responsibility fully herself. If all goes well, her idea is to operationalize her process and grow a collective around this community service effort.
• Buradorii | analytics: $500 We need someone who can help form and execute queries on the treasury data that Juicebox projects are putting out, turn these into visual dashboards, and help to tell stories from the data. Buradorii has begun experimenting with running Dune analytics queries over the past week, and seems to be getting the hang of it.

Allocations

• Bug Bounty | $40k A total of $20k to pay out to whitehat hackers who report vulnerabilities. Payouts will be according to bug severity. Moe info coming soon. This payout will be returned to the treasury if unused.
• Figma, Infura, Gitbook, Mee6 & Fleek subscriptions | $500

Reserved rate: 35% (+ 10%) The reserve rate should increase by 10%. We should continue to allocate 25% to core contributors, and we should add an additional 10% for ETH/JBX liquidity provider incentives.

Reserved token distribution:

• **jango: **35%
• peripheralist: 35%
• CanuDAO: 10%
• WAGMI Studios: 10%
• exekias: 7.5%
• misc: 2.5% - for on-demand incentives paid out by the multisig wallet.

---

There are still no guarantees for future payouts to anyone mentioned here, including myself. We'll have to come together over time to reassess allocations based on how things go, including pay increases and reserved JBX to experimental contributors who prove to be invaluable to the community over time.

JuiceboxDAO's second funding cycle will have the following goals:

• Continue working with projects that have expressed interest in launching using the Juicebox protocol as its treasury. There's at least one project slated to deploy over the next few weeks.
• Get the community organized: Discord, voting, roles, etc. We will organize and execute a community vote to determine the configuration of FC#3.
• Build UIs for projects to access back office stuff like creating direct payment addresses, transfer project ownership, and allow operators to access UI components currently only accessible to owners.
• Get the hang of writing Dune analytics queries to start visualizing Juicebox protocol data. The goal is to provide this data to projects using Juicebox.
• Continue outreach efforts to broader Ethereum communities on Twitter and Discord.

---

I propose the following reconfiguration:

Duration: 14 days Let's experiment with a shorter cycle to see what happens. It gives us scope for one solid sprint with the goal of involving more of the community in the next reconfiguration decision.

As the project matures, I expect more planned out, longer cycles instead of these shorter ones.

Ballot: 3 day buffer A reconfiguration proposal must be submitted 3 days before the end of the funding cycle.

Discount rate: 16% (-4%) The discount rate should be reduced by 4%. This continues to give those who commit funds during FC#2 a good discounted rate to adjust for the risk of being early, but begins the process of tapering the rate off.

The goal is to reduce the rate over time to make a contribution during FC#1 valued around 2X the same contribution made 6 months later.

It pays to be early and to take the risk sooner rather than later.

Bonding curve: 60% (no change) There's relatively little overflow, and the JBX distribution is still narrow. No need to change this.

**Payouts: **$10,750 total

• jango: $4k Project lead.
• peripheralist: $2.5k Front end lead.
• zeugh: $1K Organize and lead community.
• WAGMI Studios: $1.25k Educational content and art.
• Figma, Infura, Gitbook, & Fleek subscriptions cost around $500 monthly.
• **exekias: **$750 Dev contributor.
• **galbi: **$500 Dev contributor.
• **nervetrip: **$250 Dev contributor.

Reserved rate: 25% (+15%) The reserve rate should be increased 15%. This gives me and my fellow founding contributors room to add a slight incentive bump for ourselves (we've been busier than we imagined right out of the gate), and to allocate new distributions. It also puts slightly more tokens in the hands of core contributors to help guide the project in the early stages, while still giving the bulk of tokens to external supporters to diversify our token holders.

Reserved token distribution:

• **jango: **35%
• peripheralist: 35%
• WAGMI Studios: 10%
• zeugh: 10%
• exekias: 7.5%
• misc: 2.5% - used for on-demand incentives by the multisig.

Juicebox was deployed 19 days ago.

Here are the things that have become clearer to me by being a part of JuiceboxDAO, TileDAO, and helping a number of founding contributors of other projects design Juicebox configurations for deployments of their own:

• **Juicebox is flexible. ** The protocol has the capacity to power several project operation styles. This is great, but can also be overwhelming to project owners exploring their options. It's very helpful for founders and communities to have a Juicebox "expert" that can help them translate their needs into a Juicebox config, along with a catalogue showcasing several examples of how their project might behave given certain choices.
• Juicebox projects can be very much "alive". Instead of baking in a token distribution schedule ahead of time, communities using Juicebox are given the freedom to experiment and refine their strategy together over time (they could also lock it in forever from the start if they want). With this power comes great responsibility, however. Communities need great data and community analytics to make decisions with confidence.
• **A funding cycle's duration matters. ** Quicker cycles give a community more opportunities to make experimental decisions together, more frequent group calls-to-action, and more chances to debate and reassess their commitments. This creates a greater sense of communal experience over the same amount of time – a project matures more in a month using 7 day funding cycles than 30 day cycles.

The tradeoff is the more immediate need for structure, organization, and formalities. There is hardly time to observe and think on a thesis before taking it to a vote. The constant attention on governance and decision making can also get exhausting and distract from medium/longer term initiatives.

A project might want to tune its pacing over time to play with these dynamics.

• **Discount rate is the most consequential configurable parameter. ** Once a discount rate is set and tokens begin being distributed, its effects, however subtle, are felt long into the future. This is by design, but it can be easy for a project to let several funding cycles pass forgetting that they had previously set a discount rate.
• Tuning the reserved rate comes with a time-dependent tradeoff. A community is composed of core contributors, users, and casual contributors – all play an important role in a community's growth.

Core contributors are paying the most attention, doing the most work, and contributing the most upfront money. They tend to know of the tokens issued by the Juicebox protocol and their value before contributing, and thus have a conscious incentive to grow the network *now *according to the reserved rate.

Users tend to get involved mostly for the product or ideas being advertised. They only realize later that inso doing they've been given tokens by the Juicebox protocol that allow them to benefit from their community's growth over time.

Casual contributors of a community emerge from users who realize they can participate in giving the tokens they've been receiving more value by paying incrementally more attention and doing incrementally more work.

The reserved rate can thus be tuned to either boost the incentives of core contributors now at the expense of the incentives of emerging contributors later on, or vice versa.

This dynamic can of course be tuned over time.

• Juicebox works really well for communities who build products. There is no better way to fund a treasury than by piping in revenue from direct sales made off-site. Tiles are a great example: sales made on tiles.art go directly to TileDAO's treasury without the purchaser concerning themselves with the money pool ahead of time. Sure, the value of owning a Tile may in large part come from the community aspect of the DAO and the shared governance of its money, but having a brilliant, intriguing product that people want to buy is what makes the treasury worth governing in the first place.

From my point of view, JuiceboxDAO has only a handful of big-picture initiatives to focus our efforts on over the next while:

• Be available to help founders and communities get started with the Juicebox protocol with confidence. This includes creating more education materials and improving technical documentation.
• Build community analytics dashboards so communities can see how funding cycle reconfigurations have impacted their treasury over time, and so they can make better decisions into the future. This will also be useful so communities can cross reference decisions previously made by other Juicebox projects before making a similar decision themselves.
• Build L2 payment terminals so projects can receive funds on various Ethereum L2s (Optimism, Arbitrum, ZKSync, etc). I've designed the general structure of this mechanism, but it needs to be implemented.
• As more projects choose to manage their treasury using the Juicebox protocol, the protocol's TerminalV1 contract will become responsible for securing an increasing amount of ETH. It will be possible for JuiceboxDAO to write and publish a TerminalV2 contract for projects to migrate onto that sends idle overflowed ETH to a yield earning vault. This will introduce a new risk vector, so this effort can wait until the protocol has matured and the expected return is favorable.
• Organize the JuiceboxDAO's Discord and the DAO's voting mechanics on Snapshot, and continue providing structure and financial support to incoming contributors.
• Decentralize power over the JuiceboxDAO's governance over time by installing funding cycle ballots that rely on a more trustless execution of the outcome. Aragon Govern could help here.

Each of these deserves a more detailed post of its own.

If you want to help, join the JuiceboxDAO on Discord and speak up. We are looking to fund people to both lead these efforts and/or contribute to them.

The Juicebox protocol was launched with a governance contract controlled by a multisig wallet. There are 4 EOAs on the multisig, and 2 of the 4 must approve a transaction for it to be submitted to the Ethereum blockchain. I am a signer, along with @peripheralist, @nervetrip, and @NMieos.

This multisig wallet has the power to propose reconfigurations to the JuiceboxDAO's Juicebox project.

The multisig vows to make decisions honoring the community's intent, but it is still ambiguous how the community's intent will be captured going forward. For the next few weeks, expect reconfigurations discussions to be lead by the founding contributors and take community discussion into account.

Decisions made by this multisig wallet can only affect the JuiceboxDAO's treasury, not of projects built using the Juicebox protocol.

To be clear, I absolutely do not want to be a multisig signer long into the future – I feel I have already been entrusted with too much influence over the project's direction as a protocol developer and active community member. I also recognize and am OK with the fact that I am among the best people right now to approve of decisions that impact the treasury, and so I will carry on multisig duties as long as the community needs me to. After all, the project is still new to the party and finding its groove.

My main job right now is to help the project find its groove. This means helping out core contributors of other projects who have expressed interest using the Juicebox protocol, being a supporting community member of projects who have already integrated the Juicebox protocol, and identifying yet-to-be-built services that each community who uses the Juicebox protocol could benefit from while proposing ways for JuiceboxDAO to use our resources to address these needs.

The first JuiceboxDAO funding cycle configuration includes a ballot that binds reconfiguration approvals to a contract. The contract specifies that the reconfiguration must be made at least 7 days before it can take effect.

Under this contract, if the reconfiguration were to be proposed within 7 days of the current (1st) funding cycle ending, we'd have to wait until the 3rd funding cycle to have it take effect.

Anyone can write new ballots by deploying a contract that implements this interface. Once deployed, a proposed reconfiguration can then include the new ballot to use for future reconfigurations.  

We deployed a simple 7 day buffer ballot for simplicity's sake, and to provide some guardrails to protect the community from rug pulls. The goal over time is to design better and safer ballots for all Juicebox projects to use.

The first JuiceboxDAO configuration includes a bonding curve rate of 60%.

The Juicebox Protocol's bonding curve implementation can be seen in code here, and interactively here. In the interactive model, 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.

A 60% curve thus means that one JBX can be redeemed (burned) for a little over 0.6 times its proportional value of JuiceboxDAO's overflow. For example, If you owned 1% of all JBX and there was 100 ETH of overflow, redeeming all of your JBX would earn you about 0.6 ETH.

In effect, a bonding curve creates an incentive to hodl tokens longer than others. The lower the bonding curve, the more this effect becomes exaggerated. The curve does nothing if there is no overflow.

The rate of 60% that we deployed with is somewhat arbitrary – we had no expectations for overflow anyways. Expect a better hypothesis for future funding cycle reconfigurations after we've had a chance to study its effects in practice.

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.