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.

Only a few minor changes are needed for Funding Cycle #4. All of the focus areas remain the same, with the addition of one new area for "Protocol upgrades". Updates to each are outlined below.

Focus​

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

Risk mitigation​

Goal: Make sure things don't go to zero.

Current team: jango (lead), exekias

Updates:

• One low severity bug was discovered, an explanation of what happened can be found here, and a postmortem is available here.
• We're underway with a baseline audit being performed by DeFiYield.
• We still need to outline a bug bounty program with associated rewards for discovered vulnerabilities of varying severities.

UX improvements​

Goal: Improve and make templates for project onboarding and the project dashboard.

Current team: peri (lead), jango, exekias

Updates:

• Added Web3 connect support for various other wallets using blocknative. See this PR.
• Updated the "Projects" page of the site to be sortable by "Total earned".
• Added a data feed to each project feed to view total amount of ETH contributed by each address.
• Several bug fixes.

Project support, education, & docs​

Goal: Make sure JB projects have the resources they need to get started and thrive.

Current team: jango (lead), natimuril, WAGMI Studios, CanuDAO

Updates:

• Helped SharkDAO launch an AMM pool for their treasury token.
• Several conversations with projects that are interested in building their treasury using Juicebox. Actively workshopping solutions for ScribeDAO and Phlote, with FingerprintsDAO, $Loot, and a project by NiftyTable also on the radar.
• No significant updates on tech or process documentation. We need to make progress here as we continue to understand the materials that projects and contributors need to be successful.

Analytics​

Goal: Give projects rich insights into their community treasury.

Current team: peri (lead), buradorii

Updates:

• A new data feed that shows how much each address has contributed to each project has been added to each project page on juicebox.money.
• Progress has been made on charts that show a project's P&L using Flipside analytics tool.
• We have yet to deliver a data dashboard to projects. We're still working towards this end.

Liquidity pools​

Goal: Add support for JB treasury tokens in secondary markets.

Current team: exekias (lead), jango

Updates:

• SharkDAO's SHARK token has been pooled with ETH on Sushiswap, you can see the analytics here. SharkDAO's Juicebox page was closed during this transition, with plans to reopen in the coming days.
• Research is underway to provide a staking contract to projects where LP rewards can be distributed.

Marketplace​

Goal: 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 team: nicholas (lead), jango, peri*

Updates:

• Researched how other protocols are doing split payments.
• Finalized the user journeys that we're trying to solve.
• Begun workshopping how the contracts should be architected.
• Begun ideating on what the UX should be.

Governance​

Goal: Plan out how we will make decisions together.

Current team: zheug (lead), unicornio

Updates:

• Created a process schema to follow when making proposals, voting on them, and conveying the decision on-chain.
• Created a Coordinape page where we can experiment with reputation assignment.
• Governance meetings are beginning to happen regularly on Tuesdays.

Protocol upgrades  ​

Goal: Evolve the protocol to be more useful and remove friction from the treasury management process.

Current team: jango (lead), exekias, peri, nicholas

Updates:

• A TerminalV2 contract is well underway. This update will allow projects to customize their treasury strategy entirely. Details tbd, implementation and ongoing tests can be found here.
• TerminalV2 will patches an edge case bug found, mentioned earlier under  "Risk mitigation"

My proposal for FC4:​

Duration: 14 days (no change)

Ballot: 3 day delay (changed from 7 day) A reconfiguration proposal must be submitted 3 days before the end of the current funding cycle. Reconfiguration decisions are feelings a little rushed. Changing the ballot delay from 7-days to 3-days gives us a bit more time than what we currently have for evaluating proposals and conveying changes on-chain.

Discount rate: 10% The discount rate should continue to compound at 10% to reward contributors who continue to fund the JuiceboxDAO treasury at this risky stage.

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: $33.5k total

I propose we pay exekias, nicholas, nati, and buradorii slightly more.

Core contributors

• jango | dev: $10k (no change)
• peripheralist | dev : $10k (no change)
• CanuDAO |comms:$2.5k (no change)
• WAGMI Studios | art, animations, and educational content: $2.5k (no change)
• exekias | dev: $4k (+ $1k) Exekias has bee hands on with all aspects of the code. Increasingly becoming an integral part of the core dev staff.

Experimental contributors

• nicholas | dev: $2k (+ $500) Nicholas has begun writing code, he's been an active voice in our community, and he's helping to progress pivotal discussions forward.
• nati | community relations: $1k (+$500) Nati has begun onboarding DAOs onto Juicebox and is also helping progress pivotal discussions forward.
• Buradorii | analytics: $1k (+$500) Buradorii has begun publishing Flipside data dashboards. We've yet to aggregate charts and deliver them to projects.

Allocations

• Figma, Infura, Gitbook, Mee6 & Fleek subscriptions | $500

Reserved rate: 35% (No change) We should continue to allocate 25% to core contributors, and reserve 10% for ETH/JBX liquidity provider incentives (soon).

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.

SharkDAO, the project using the Juicebox protocol that is moving quickest and most likely to break things, has quickly proven the need for pooling its Juicebox treasury tokens into AMMs to provide organic price discovery for its token holders. Most Juicebox projects who reach scale will likely also come across this need.

The value of SHARK is derived not only from its ETH stored in the Juicebox contracts, but also from the NFTs the DAO has deployed treasury funds to acquire, from the JBX that the DAO has begun accumulating by paying platform fees, and perhaps most importantly from the productive community forming within the project that gives it boundless potential moving forward. The prospective value of each of these assets is dynamic and subject to each individuals' confidence and risk appetite. This calls for a more fluid market making and order filling strategy than what the Juicebox protocol has provided until now.

Juicebox provides SHARK holders an effective way to fundraise and expand, but it doesn't yet provide a way for holders to coordinate a value for what they already own – this is the strength of AMMs. SharkDAO needs both of these features well into the future. If Juicebox wishes to be the go-to treasury protocol for startup projects who scale, it needs to understand how the current mechanic behaves alongside a treasury token liquidity pool, and which protocol adjustments are needed to smooth out any identified market inefficiencies over time.

Current limitations​

Currently, Juicebox treasuries have no configurable max-supply of tokens. The protocol always offers people an opportunity to pitch in ETH and receive treasury tokens in return according to the current funding cycle's weight, which is determined by the compounding effects of discount rates alongside the currently configured reserve rate.

As a reminder, the discount rate decreases the amount of tokens minted per ETH contributed as funding cycle's roll over – a discount rate of 10% to the current funding cycle means that a contribution of X ETH to the next funding cycle will only yield 90% of the tokens that the same contribution of X ETH made during the current funding cycle would yield. The reserve rate determines how many of these tokens will be reserved to be distributed to preprogrammed addresses instead of to the payer.

The protocol is thus always quoting a value for a project's treasury tokens, and inso doing always offering to inflate the supply of tokens to meet this demand in exchange for crowdfunding more ETH. It is thus unrealistic to expect the market price of treasury tokens on an AMM to ever exceed the price quoted by the protocol – the protocol will always provide a price ceiling. If the secondary market is over, there is an obvious arbitrage opportunity to pull the price back down.

There may, however, be people who received treasury tokens at a discount in the past who are now willing to sell them for profit at a better price than what the protocol is offering. This supply-side pressure happens organically as funding cycles unfold and discount rates compound. On the buy-side, it's logical for someone to seek a better deal for treasury tokens from this secondary market than get them from the protocol. If the majority of activity is happening on secondaries beneath the protocol price, the token supply and fundraising efforts will tapper off at this equilibrium.

The big question thus becomes how a project chooses to pursue this equilibrium. Does it tune its discount rate and reserve rate over time with its own fairness principles in mind, using secondary markets as a convenience for buyers and sellers but limiting the market's potential to naturally discover its price's upper bound? Or does it use the secondary market as a primary indicator of fairness, using the discount rate and reserved rate only to conveniently satisfy its fundraising needs over time? The answer depends on a community’s values. Does it wish to be liberally open, inclusive, and predictable while prioritizing cashflow? Or instead more-strictly protective of the value current members have accrued and took risks for, with strategic fundraising/expansion campaigns down the road that are scoped for value-adding initiatives? Maybe a balance between the two, with principles in place to guide decisions?

The Juicebox toolset has proven to work well for projects who are willing to expand supply to accommodate new funds and new community members. For projects that want to protect the value they have built and conduct more strategic and scoped fundraising campaigns over time, the compounding discount rate and reserved rate mechanisms might not work well within the current protocol's constraints.

Solutions​

The solution might be simple.

For the Juicebox protocol to be able to accommodate market driven projects, it must allow them to:

• specify a supply cap for their treasury token, and
• allow them to customize the quantity of treasury tokens that are distributed per ETH received.

Under these conditions, if payments are received into the treasury after the token supply cap is exceeded, no tokens will be minted in return. Otherwise, if the project has set a customized treasury token price point, tokens will be minted according to this rate overriding the current funding cycle's weight derived by the compounding discount rates of previous cycles.

These tools allow a project to essentially "pause" new treasury tokens from being issued, and at any point open up a fixed supply of new tokens to distribute at a specified price point. The reserved rate as it currently exists can work within this pattern to route newly issued tokens to time-bounded distribution mechanisms, incentivized staking pools, the project's own multi-sig wallet, etc.

Adding these parameters does put more power into the hands of the project owner, which is a tradeoff worth noting. People who contributed funds earlier in a project's lifetime will no longer have guarantees that their tokens were issued at a discount compared to the future cycles, and protocol rates are subject to change as dramatically as the project owner desires. Communities must make extra sure that the ownership of their project (represented by an ERC-721 contract) is in the hands of a trustworthy wallet willing to execute decisions collectively agreed upon. I'm not too worried about this tradeoff because it is already true to large extent in the current implementation.

Another tradeoff of a token supply cap is that it risks the consistency of DAO-to-DAO and Anon-to-DAO collaboration. For example, imagine someone stands up an NFT marketplace that automatically routes percentages of artwork sales to preconfigured destinations, like to SharkDAO's treasury. If SharkDAO has a token supply cap in place and has reached this limit, the sale of the artwork would still send the ETH to the treasury, but the artist would not receive any SHARK in return. I'm also not too worried about this tradeoff because the same effect is possible with the current mechanism if a project tunes its reserved rate to 100%. Each project/artist composing with Juicebox treasuries should always understand the variability of doing so – rates are subject to change, and so its important to prioritize building relationships with trustworthy projects who make decisions in the open with proper planning and community engagement.

Another detail to note: the configuration of both new parameters will be scoped to funding cycle configurations – a project running on timed cycles must await a new cycle for changes to the max-supply and weight override parameters to take effect. Projects with longer funding cycle durations and more rigid reconfiguration ballots will thus continue to operate with more predictability, checks, and balances. Another effect of this is that the actual token supply might be greater than the configured max supply if the project ends up minting more tokens during a current, boundless cycle before a queued one with a max-supply becomes active.

A proposal is taking shape to implement these two new properties into a TerminalV2 contract within the Juicebox ecosystem. Projects currently running on TerminalV1 will have the option to migrate over once the contract has been deployed and approved.

Join the JuiceboxDAO Discord to add to this discussion and provide alternate ideas and points of view before we move forward with rolling out these additions to the protocol.

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.