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

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

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

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

An effective solution will take into consideration that:

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

---

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

thoughts in progress. feedback always welcome. plz add to the conversation and let me know if i'm missing some context, it can be hard to keep up with it all.

ConstitutionDAO has reached some sort of a coordination moment. There are decisions to be made both technically and socially, and the PEOPLE will have their first opportunity to really use their voice.

Meanwhile us builders have another opportunity to evaluate and extend our current tooling to best support moments like this for people into the future.

Things we care about when considering refund design: speed, safety, cost, flexibility, convenience, (...?).

In the case of ConstitutionDAO, the refund could be handled in a few different ways (there are definitely others that I don't know of or am less familiar with):

Do it through Juicebox​

Steps:

1. Inject the $40+ million back into the Juicebox contract.
2. Multisig sends a tx reconfiguring ConstitutionDAO's funding cycle target to 0, allowing all tokens to be redeemable for a proportional share of all funds in the treasury.
3. Everyone who wants to redeem their PEOPLE tokens can do so. All who wish to stay in and build out ConstitutionDAO can instead keep their PEOPLE tokens and leave their funds committed to the group.
4. The DAO eventually reassess what it wants out of itself, and who will serve on the multisig to continuing operating the treasury on the community's behalf. DAO can also reassess if it wishes to open up to new members and contributions, etc. In other words, DAO continues to do DAO shit.

Notes:

• -- I'd prefer if the Juicebox contracts were looked through by several more people before sticking $40+ mil in them. I personally trust them, but we need community trust and acknowledgement that this is risky experimental stuff. I would love to have the community's confidence in this decision. I'd love to do workshops over the next few days toward this end.
• -- Every person claiming would have a gas fee to pay that would cost about the same as it costed them to contribute: $30-$60 bucks worth of ETH. This sucks especially for folks who contributed amounts around the same order of magnitude as the fee.
• ++ This would require minimal coordination, everyone can take whatever action they choose, whenever they choose to.
• ++ As the Juicebox process is being audited, the DAO could begin manually issuing refunds right away to people who send in their PEOPLE tokens to the multisig.

Multisig manually sends refunds to those who want it​

I saw versions of this idea from @strangechances, @DennisonBertram, and * @austingriffith.*

Steps:

1. DAO reserves around $2 mil to pay for refund gas.
2. Take a snapshot. Everyone who had a balance of PEOPLE tokens at a particular block number would be eligible to request a refund at a rate of 1 ETH per 1,000,000 tokens.
3. The multisig would send tx's to fulfill these requests, covering the gas using the amount reserved.
4. The remaining DAO has to reassess how it manages its tokens if it wants to continue to do DAO shit since PEOPLE tokens are no longer backed by ETH.

Notes:

• -- multisig would have to coordinate around potentially thousands of payments.
• -- it could take a bit for people to signal their request for a refund. The multisig would have a lot of double-checking and button-clicking to do upfront, and be on standby for a while.
• -- the balances won't account for exchanges that happened after the snapshot.
• ++ The cost of gas will be distributed between everyone who stays around. They DAO could even retroactively subsidize the entry gas fee of anyone leaving by issuing refunds ~$60 more than what was contributed, assuming there is a sizable enough community who wants to hold on to their PEOPLE tokens.
• ++ People can have the option to request funds on a particular L2. The multisig can batch transfer its balance to each L2 accordingly and issue distributions from there.

Multisig deploys a Merkle Distributor airdrop​

Comment from @nnnnicholas. Disclosure: Nicholas is not a member-donor of ConstitutionDAO. It was also mentioned @austingriffith.

A version of this using Mirror Splits was proposed by @strangechances who offered to help execute it.

Steps:

1. Take a snapshot. Everyone who had a balance of PEOPLE tokens at a particular block number would be eligible to request a refund at a rate of 1 ETH per 1,000,000 tokens. This is called a "snapshot".
2. Deploy Airdrop/Split contract and send it total funds.
3. Announce timeline for moving funds back to DAO treasury multisig to be claimed by those addresses captured in the snapshot.
4. The remaining DAO has to reassess how it manages its tokens if it wants to continue to do DAO shit since PEOPLE tokens are no longer backed by ETH.

Notes:

• -- This approach will still cost refunders a similar amount of gas to redeeming via Juicebox.
• -- The PEOPLE tokens can no longer be used as a claim on the treasury, because people could then double-dip. PEOPLE tokens no longer function as normal Juicebox project tokens.
• ++ The primary advantages of the airdrop approach is that it can use all or mostly audited code, increasing security as compared to Juicebox's unaudited redemption mechanism.
• ++ This approach reduces gas costs for the DAO (i.e., the people who do not want refunds) as compared to multisig paying gas to send all refunds directly.
• ++ The airdrop could be configured to allow redemptions on an L2, though this adds complexity.
• ++ Allows contributors to retain their PEOPLE token but receive a refund.

... (pitch other ideas by listing steps and tradeoffs)

---

General notes:

• Anyone whose contribution to ConstitutionDAO settled after the PEOPLE token distribution cutoff will be receiving a direct refund from the DAO.
• The timing of the snapshot becomes very important in the scenarios that require one. Candidates include the time the Juicebox closed to new contributions, the moment the auction was lost, or some point in the future (i.e., pre-announced snapshot).  
• Snapshots are captured using a Merkle tree that can be stored in an offchain database or IPFS as in Mirror's Split, which is based on Uniswap's UNI airdop Merkle-Distributor, or emitted as an onchain event stendhal-labs/collab-splitter. The latter would likely be expensive, but far less so than the DAO paying to distribute the refunds manually.

A project's overflowed funds in the Juicebox protocol can serve various purposes depending on the configuration choices the project makes.

A reminder, overflow is the amount of funds currently in a project's Juicebox treasury minus its current funding cycle's target, which specifies the amount allowed to be distributed from the treasury to preprogrammed addresses during the cycle. A project's token holders can burn their tokens at any point to receive a proportional amount of the project's overflow. This proportion can be affected by a bondingCurve also configured per funding cycle. A curve of 100% is a linear proportion.

Here are outlines of how a project's funding cycles might be configured to use its overflow for achieving various treasury designs:

Refund​

Overflow can be used to give all contributors access to their money back in the case of an unsuccessful campaign.

In the case of ConstitutionDAO, the project's first funding cycle is configured with a target of uint256.max, which allows free movement of any funds accumulated in Juicebox into preprogrammed addresses (the Gnosis multisig wallet). It is also set up with a duration of 0, which gives the project's owner (also the Gnosis multisig wallet) authority to trigger a new reconfigured funding cycle at any point. All ETH contributed mints a proportional amount of the project's tokens for the contributor.

The multisig could thus reconfigure the project to have a target of 0 and then inject all of its raised funds back into its Juicebox treasury, which would make all funds in the project considered overflow and therefor claimable by token holders. With the bondingCurve at 100%, each token holder could then burn their supply to receive the same amount of ETH they originally put in.

Ragequit​

A project can use its overflow to allow disenchanted token holders to exit and take with them a portion of the treasury's funds.

Only a project's overflowed funds in Juicebox are available to be claimed by burning tokens. If a project's funds are mostly kept in a multisig (or other contracts/assets), they cannot not be taken into account in the redemption value of a token (changing in V2). A project can thus tune the expected return of ragequitting by injecting liquid funds back into Juicebox, adjusting its target value, and loosing/tightening its bonding curve.

If a project is spending its raised funds at a faster rate than it is pulling in funds, or if the project's rate of token distribution has changed over time, it's likely ragequitting via the built in juicebox mechanism won't yield the same amount as initially contributed.

Shouts to MolochDAO for coining the term "ragequit".

Cash-back​

A project that sells products can use its overflow to give customers the opportunity for cash-back.

TileDAO, for example, currently sells artwork for 0.16 ETH. When works are minted, the sale price is piped into the TileDAO treasury, minting the project's tokens for the buyer in return. TileDAO might want to give its token holders incentive to hold these tokens by giving them utility, perhaps decision making weight in governance, otherwise holders might want to redeem them for some of the project's treasury. This redemption would essentially give the buyer of the art some cash back, the value of which determined by several aspects of the project's funding cycle choices over time.

Realizable profits​

A project can inject funds into its treasury from arbitrary sources, giving all token holders access to them by burning tokens.

The simplest example here would be a project that gathers funds via a Juicebox project to purchase a thing, then turns around and sells the thing for more than what it paid. The funds from the sale can then be injected back into the Juicebox project for token holders to claim if they choose to do so.

---

Consistent through all of these examples are consequential choices that a project can make to offer its community particular treasury designs over time. The address that controls the NFT representing a Juicebox project has the power to make these choices. Whichever EOA or contract stewarding this responsibility on a community's behalf should be scrutinized and held accountable to the extent each community sees fit.

Hopefully what these examples make clear is that the tokens issued by projects using the Juicebox protocol have no intrinsic value. They can, however, be used by projects as a utility for making decisions, the outcomes of which can give them value. It all depends on the choices we make together over time, and the social and algorithmic contracts we use to make these choices binding.

JBX membership is currently represented by 602,065,173 tokens:

Jango has 118,891,959 (19.74%) Peri has 100,255,206 (16.65%) DragonFly Capital has 48,048,000 (7.98%) SharkDAO has 30,063,667 (4.99%) JuiceboxDAO has 27,827,807 (4.62%) 4 addresses each have around 18,500,000 (3%) 13 addresses have between 5,000,000 - 15,000,000 (1-3%) 7 addresses have between 2,500,000 - 5,000,000 (0.5-1%) 28 addresses have between 500,000 - 5,000,000 (0.1-0.5%) 64 addresses have between 100,000 - 500,000 (0.01-0.1%) 56 addresses have less than 0.01%

Membership has been given to those who have helped build the protocol and the DAO, and to those who have supported the efforts by sending ETH to the treasury, with a preference for those who helped in any capacity in earlier funding cycles. Membership has been open to all since the protocol was deployed.

Currently in Funding Cycle #8, each 10 ETH contributed to the treasury by new or existing members mints the following amounts of JBX:

2,579,260 for the contributing member

416,649 for JuiceboxDAO 333,319 for Peri 333,319 for Jango 97,218 for Nicholas 97,218 for Exekias 55,553 for WAGMI Studios 55,553 for CanuDAO

Today, it would take a contribution of 278 ETH for the contributing member to get 10% of the total membership tokens.

Two months ago in funding cycle #4, each 10 ETH contributed to the treasury minted 3,931,200 JBX for the member.

The total amount of JBX issued to members per ETH accepted is decreasing by 10% every 2 weeks. At this current rate with 2 week funding cycles and 35% reserved, in funding cycle #12 each 10 ETH contributed to the treasury will only mint 1,692,252 JBX for the contributor.

Observations​

• Builders and contributors don't know what they're getting when they contribute ETH or are receivers of reserved tokens.
• Membership is getting expensive.
• JBDAOs strategy thus far has been to focus on building in the open, while making clear upfront the resources it needs to be able to build effectively.
• No one in JBDAO has produced much work proposing how we might make membership more accessible to people or distribute it more widely, or why that might be worth prioritizing. Most of what is discussed is about how to solve problems for juicebox projects and for builders who want to come in and improve/grow the ecosystem.
• The way JBDAO is using its 35% reserved rate ensures about 25% of any membership expansion the DAO makes goes to builders who are currently stewarding projects. If the DAO isn't growing its treasury, committed builders don't become substantial members. The remaining 10% go to JBDAO itself, which it hasn't done anything with yet.
• The DAO's casual builders and helpers currently don't have a way to become members other than to make a contribution to the DAO of any amount.
• It might be interesting for the DAO to tapper off its discount rate so that over time, members who consider joining are represented and feel welcome.
• It might be interesting for the DAO to allocate all of a 35% reserved rate to itself so it can hand out some non-insignificant starter membership amounts to more people who are helping out casually, and to people who are currently cranking out tasks and getting to know the system but don't yet plan on sticking around for too long. The DAO could also give membership to other builders around web3 who might be creative and thoughtful voices to have in the room when determining how the DAO could allocate its treasury.

Open questions​

• How might the DAO distribute its allocation of JBX effectively to add more great members now and into the future?

As funds are contributed to the JuiceboxDAO treasury – either as direct payments or as fees paid – JBX is minted and distributed. Currently, 35% of these are reserved and allocated to preprogrammed addresses while the remaining 65% are sent to the contributor of the payment.

The current distribution of reserved tokens for JuiceboxDAO is as follows: There is no cap to how many JBX are minted into existence: as more ETH is contributed, more JBX is created, albeit at a slightly decreasing rate over time due to the discount rate (currently 10% fewer JBX minted per ETH every 2 weeks). With each payment, the pie being shared grows while everyone's share of the pie slightly shrinks.

... except for those on the reserved tokens list. At any given moment, their overall JBX positions tend towards the percent of reserved tokens they're programmed to receive, at the rate of the treasury's growth. This also means that currently 35% of the DAO's value tends to concentrate between the reserved token holders, with the remaining 65% going to a long-tail distribution between those who chipped in or paid fees to the treasury over time, favoring those who did so soonest.

JuiceboxDAO's reserved tokens have thus far been mostly allocated to those few contributors shouldering operational responsibilities to the DAO. Recently the DAO also began reserving tokens for the DAO's multi-sig in order to redistribute to LP staking rewards and other programs.

Going forward, the DAO's greatest opportunity to coordinate incentives among its community will likely come through expanding the reserved pool to include many new members and campaigns with proven commitments to its success, as well as smaller scoped experimental distributions.

With a few basic guardrails and guidances in place such as those outlined in the DAO's governance documents, the DAO should be set up to fairly and efficiently welcome in meaningful contributors, while shedding those who are no longer participating or useful. This process should spread the value the DAO creates to the people actively furthering the project's mission statement, and to the projects building on the protocol who are paying fees over time.

I'm very eager to see more reserved token allocation proposals over the next several months, and for the number of reserved token receivers to grow substantially.

Aside​

The reserved rate also makes a 51% takeover very expensive. JuiceboxDAO currently has a total supply of 577,516,558 JBX tokens. Each ETH contributed mints another 544,320 JBX (353,808 to the payer, 190,512 to the reserved pool). In order for someone to mint 51% of tokens for themselves today, they would have to dump 3,865 ETH into the treasury. This will just get more expensive as time goes on since the total supply will increase over time as the number of tokens minted per ETH contributed decreases.

Last update: 9/07/2021

Current focus areas are:

• Risk mitigation
• Protocol upgrades
• Web experience
• Analytics
• DAO relations
• Liquidity pools
• NFT marketplace
• Governance
• Materials

Focus areas​

Risk mitigation​

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

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

Updates:

• nothing to report.

Help needed:

• Reviewing V2 docs and tests.
• Bug bounties now included in the V2 documentation that's underway.

Protocol Updates​

Goal: Evolve the protocol to be more useful.

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

Updates:

• Progress on documentation. JBSplitStore, JBOperatorStore, JBPrices, and JBProjects are fully documented. See Protocol section of docs.juicebox.money.
• Bug bounties now included in the V2 documentation

Help needed:

• More eyes on the docs
• Pursue leads for solidity audits in next 4-6 weeks

Web experience​

Goal: Improve the Juicebox experience both for people starting communities and for communities that are growing.

Current team: peri (lead), jango, exekias

Updates:

• Added feature for JB Project owners to update assets listed in the Project UI
• will eventually support 721 assets, too
• 'Pay' button Call to Action can now be customized
• Rinkeby support
• JB Interface now has its own dedicated repo and issue tracking https://github.com/jbx-protocol/juice-interface

Help needed:

• Backlog of todos https://github.com/jbx-protocol/juice-interface/issues
• Would love to bring on a dedicated person to get familiar with the UI codebase

Analytics​

Goal: Give projects rich insights into their community treasury.

Current team: peri (lead)

Updates:

Contribution pipeline being refined. Subgraph now has a dedicated repo with a streamlined deployment flow.

Analytics roadmap being refined as steps for V2 migration become clearer.

Subgraph Deep Dive

Help needed:

• Work/todos being tracked here https://github.com/jbx-protocol/juice-subgraph/issues

DAO relations​

Goal: Work towards making sure JB projects and the JB community have the resources and attention they need to get started and thrive.

*Current team: nati (lead), zeugh, mieos, nicholas, jango *

Updates:

• Jango and others converting people from DMs into discord members.
• Lots of people coming into the DAO relations channel.
• Pencil DAO created without any interaction with team. BrainDAO and others coming online.
• Idea: Daoification Hackathon to help JuiceboxDAO members feel more comfortable onboarding others.
• Meeting with largest single contributor: Conversation with Tom Schmidt of Dragonfly Capital
• Lots of progress in Notion: Tools section, How to section.
• Meeting notes becoming standardized and recordings much more frequent
• Gitbook docs welcome page and contract addresses added.
• Zeugh bought Sesh pro.

Help needed:

• Project lead on Daoification hackathon where anyone can join in and create a bunch of projects on rinkeby to be more comfortable configuring and reconfiguring a JB.
• Project lead needed to design and implement faster easier way to create "a DAO for your group chat". Can this be done with a Discord bot?Help Needed
• Feedback to Zeugh for discord restructuring.
• Adding info to Tools.
• More people willing to record calls and upload.

Liquidity pools​

Goal: Add support for JB treasury tokens in secondary markets for communities to be able to value their assets better.

Current team: exekias (lead), jango

Updates:

• No updates. Core dev team is focusing on V2 for the time being.
• Might be a good move to fork the BarnBridge rewards contracts instead of the synthetix ones.

Help needed:

• Someone to help test, verify, and deploy the staking contracts.

NFT Marketplace​

Goal: Give JB projects a place to sell digital (and eventually physical) goods which pipe percentages of revenue to any number of addresses or Juicebox treasuries.

Current team: nicholas (lead), jango, peri

Updates:

• Looped in Peri and Mieios for NFTMKT specification feedback meeting.
• Reprioritized NFTMKT, JB devs will do a sprint this coming week, Sept 27, 2021
• Nailed down V1 spec with Peri's help. Updated architecture, replacing submit with list function, which will save on gas.
• Reaffirmed permisionless design of NFTMKT and v2+ roadmap.
• We will also stand up a couple 721 Creator contracts so artists collaborating with JB projects (e.g., Numo with Sharkdao) can create superior NFTs than on the OpenSea creator contract, which is closed source, centrally hosted metadata by default, and a shared contract. We anticipate one 721 contract for closed collections (where token supply is known in advance) and one open minting collection (where artist can add over time). Nico already has a closed collection contract that we can refine. Can also build a simple front-end to make this easy for artist collaborators (and the broader NFT ecosystem).
• We continue to experiment with ideas about spinning NFTMKT off into its own JB project because the opportunity is large, and we believe that small teams working on focused projects are more effective than one overwhelmingly large vertically integrated JB protocol team. Perhaps initially staffed by same dev team as JB. Can focus on NFTMKT and the creator contracts. Could collect a fee for NFTs sold through the marketplace (2.5% like opensea?) or could be free. If it had revenue it would have more opportunity to expand dev team. Also thinking about token-swaps between NFTMKT and JB 📈🤝.
• Increasing belief that NFTMKT will solve the DEX vs JB dilemma facing DEX-traded DAO tokens, where the DEX is always a better price than the JB, by game-theoretic definition. This limits DAOs' ability to fundraise because DEX trades do not affect DAO treasuries. NFTMKT will allow DAOs like Shark to largely replace direct-to-JB appeals. DEX purchases may still offer cheaper DAO tokens than the NFTMKT, but buyers will not get access to limited edition NFTs via the DEXes. NFTMKT will also be more fun and easy to use for NFT acclimated, compared to JB or DEXes which are unfamiliar to many in that space.
• The team is very excited about the promising design specification and roadmap for the NFTMKT.
• Nicholas also discussed with Mieos affordances in the 721 contracts that will enable WAGMI to create NFTs on behalf of client DAOs. Achievable design requirements even within the V1 spec.

Help needed:

• Review read methods & TheGraph events with Exekias or Peri this coming week
• Nico x Jango will collab to finalize v1 NFTMKT solidity
• Nico to talk to Pencil DAO

Governance​

*Goal: Plan how we make decisions within the community. *

Current team: 9birdy9 (lead), zheug, jango, unicornio

Updates:

• New voting process
• Finalized proposal process
• New governance process:

Governance

Includes Proposal Templates for each common type of proposal.

All JBX holders participate in votes that affect big picture JBX variables.

Changes to recurring payouts are voted on by addresses currently receiving payouts as they have greatest insight and are most affected by such changes.

Changes to reserved token allocation voted on by addresses currently receiving reserved tokens as they are most affected.

Addresses receiving payouts are expected to vote.

• Discussion about whether large token holders and people on reserved list should have max voting capacity or some quadratic strategy that limits outsized impact.
• First trial of these new templates in current governance process.
• @9birdy9's trial payout proposal is the first proposal sent to snapshot according to these forms.
• FC5 reserved JBX tokens will be passed without a formal snapshot for lack of sufficient time to complete our governance snapshot process. We will use snapshots for future reserved token proposals.
• Creation of BANNY gov participation incentivisation token — An airdrop is in the works.

Help needed:

• Refining governance process:
• Creating informational foundations to keep people up to date on governance proposals/timelines.

Materials​

Goal: Videos/visuals/memes/stuff that radiates Juicebox vibes.

Current team: WAGMI studios

Updates:

• WAGMI producing cultural content
• Published overflow video

Help needed:

• Feedback on content
• How can WAGMI help juicebox projects launch
• Helping onboard
• Developing visual identity (cultural material)

Co-authored: jango, peri, exekias, nati, nicholas, zeugh

Current focus areas are:

• Risk mitigation
• Web experience
• DAO relations
• Analytics
• Liquidity pools
• NFT marketplace
• Governance
• Protocol upgrades
• Materials

Focus areas​

Risk mitigation​

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

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

Updates:

• No new bugs/problems discovered in the contracts.
• New repo where security issues are documented here.
• Wallet connection issues in the front end solved. One remaining bug where connecting wallet from the projects page sometimes causes the beneficiary field of payments.
• DefiYield auditors seems to have dropped off. Need to follow up again.
• Focus on security now moved to V2. Documentation, tests, audits, etc.

Help needed:

• It'd be great if more folks could help write tests and review the code and documentation as it gets done. We should collaboratively mold this into its final, secure form.

Web experience​

Goal: Improve the Juicebox experience both for people starting communities and for communities that are growing.

Current team: peri (lead), jango, exekias

Updates:

• New analytics data in project dashboards. Still room to grow, more data sourced into The Graph and ready to use.

• New wallet connection integration. Can now connect with many other wallets with BlockNative integration.
• Progress on Github issues backlog.
• Wording in the interface being reconsidered:  "staking" vs "claiming".
• Researching different UIs for different treasury types.

Help wanted:

• Backlog at https://github.com/jbx-protocol/juice-juicehouse/issues

DAO relations​

Goal: Work towards making sure JB projects and the JB community have the resources and attention they need to get started and thrive.

Current team: nati (lead), jango, nicholas, mieos, zeugh

Updates:

• Gitbook updates underway. Walkthrough, explanation of processes.
• Working with Whiteboard crypto, UltraDao, BeatsDao.
• Focusing on established DAOs. Might refocus to newer DAOs later.
• People should forward questions from #support and from other JB projects to Nati to aggregate into docs.

Analytics​

Goal: Give projects rich insights into their community treasury.

Current team: peri (lead), buradorii

Updates:

• Most updated in the UI under the "Web experience" focus.
• Experimenting with what data can be accessible in the UI.
• No updates on Flipside or Dune analytics.
• People want to see current token holders for each projects.
• People want to see current FC vs upcoming FC.
• People want to see the price the treasury token is being sold at over time.
• People want to see the percent of the tokens that they will own at the time of making payments.
• People want to be able to play out funding cycle scenarios before making reconfigurations.

Open to help:

• Index more Subgraph events.
• Display discount rates (tokens/ETH) of past funding cycles.

Liquidity pools​

Goal: Add support for JB treasury tokens in secondary markets for communities to be able to value their assets better.

Current team: exekias (lead), jango

Updates:

• Experimenting with Synthetix staking rewards contracts: https://github.com/jbx-protocol/staking-rewards.
• Fleshing out UI prototypes:

Help wanted:

• Comms with JBX project owners (e.g., SHARK) to understand their needs from a staking reward/LP perspective.
• Devs with staking rewards expertise.

NFT Marketplace​

Goal: Give JB projects a place to sell digital (and eventually physical) goods which pipe percentages of revenue to any number of addresses or Juicebox treasuries.

Current team: nicholas (lead), jango, peri

Updates:

• Big demand from SharkDAO (and others?).
• Draft of contract looking good.
• Plan for V1 is no UI on juicebox.money, make bare bones JS SDK/library with/for Shark to build a NFT MKT into their forthcoming website.
• Need to finalize what will be included in v1, and what won't.
• Specification draft
• Github repo (private for now)

Goals:

• Finalize spec for v1
• Get a working v0 implementation on Rinkeby by Monday 2021-09-13 EOD
• Get a basic 721 contract together to mint NFTs that we can submit to the marketplace

Help needed:

• Jango will help with contract implementation and testing (thank you –nicholas)
• Next week open to help starting building a JS SDK

Governance​

Goal: Plan out how we will make decisions together.

Current team: zheug (lead), unicornio, 9birdy9

Updates:

• Trying coordinape to test a reputation system. The epoch system feels good, didn't give us the easy integration to voting that we needed after the epoch.
• We're still wroking on our basic model for how to make decisions. Need to balance governance power between token holders and reputation/contributions but we haven't got a way to test it yet.
• We can, at the moment, take the csv of reputation distributed after the Epoch, but are still looking on how to import those in a strategy to snapshot. Need help from more dev oriented folks to communicate coordinape results onto snapshot.

Help needed:

• We need some dev/snapshot help to integrate our new governance system into a snapshot strategy.

Protocol upgrades​

Goal: Evolve the protocol to be more useful.

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

Updates:

• V2 has been announced here.
• Reviewed V2 with Peri, Exekias, and Nicholas, got very valuable feedback that is being iterated on.
• Docs for V2 are in progress here.

Help needed:

• Same as in the "Risk mitigation" section.

Materials​

Goal: Videos/visuals/memes/stuff that radiates Juicebox vibes.

Current team: WAGMI studios

This is a new section that will have updates next time

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.