JuiceboxDAO is running final tests on an updated/forked version of its Terminal contract. Once deployed and approved by JuiceboxDAO, projects will be able to voluntarily migrate their funds and accounting parameters from the V1 terminal that is currently being used to this new V1.1 Terminal with just one transaction.

There are many broader changes being developed in a V2 release scheduled for the coming months. V1.1 is a simpler change that still manages to provide crucial utilities and fixes for projects operating on the protocol.

Here's why a project might want to migrate to V1.1:

Features​

• Pause - Projects will be able to pause contributions to their treasury as well as subsequent token issuance on a per-funding cycle basis. Any new transactions – or pending low-gas transactions in flight – that settle after a paused funding cycle has started will fail.
• Mint - Projects will be able to allow itself to mint more of its own tokens on a per-funding cycle basis. During a funding cycle where minting new tokens is allowed, the project owner can submit a transaction to increase the token supply and send this new supply to a beneficiary of its choice.

Currently projects can only mint new tokens before receiving a first contribution.

• Burn - Anyone will be able to burn their tokens by redeeming them, even when there is no overflow.

Currently tokens are only burnable when there is some amount of overflow that is being reclaimed through the redemption.

• Off-protocol redemption value - Projects will be able to supply a contract to their funding cycles that tell the protocol how much value it is holding off-protocol, like in a multisig wallet or yielding vault. Projects can use oracles in this contract to convert the value of any other asset it owns into ETH for the protocol to use when calculating redemption values.

Currently redemption values are calculated only with the ETH the project has locked in the Juicebox Terminal contract.

• Fee cap - The protocol fee is capped at 5%. JuiceboxDAO can adjust the JBX fee from 0% - 5%.

Currently there is no fee cap.

Bug fixes​

• Fixed bug that prevents a project from updating its reserved token tracker when the reserved rate is set to 0%. This bug prevented the project from reconfiguring from a 0% reserved rate to any other value without inadvertently creating an extra reserved token supply inso-doing. See this postmortem.
• Fixed bug that prevented overflow from being viewed correctly when a funding cycle rolls over before it has had its newly available funds distributed.

Other adjustments​

• The contract is now directly Ownable instead of using an ownable Governance contract proxy. The JuiceboxDAO will own the contract, which allows it to set the fee, and allow other forked Terminal contracts for projects to migrate onto.

JuiceboxDAO runs its community treasury on the Juicebox protocol. The tools at its disposal are also publicly available. Check out the protocol's tokenomics toolkit here.

JBX is the membership token of JuiceboxDAO. Its utility is to vote on proposals of how the DAO should evolve over time. Check out the potential use cases each project's tokens can be programmed to have within the Juicebox protocol here.

Thanks to Nicholas, Zom-Bae, Zeugh, and Aeolian for edits and feedback.

JuiceboxDAO is currently issuing 208,920 JBX per ETH to anyone who contributes to the treasury. This rate currently decreases by 10% every other week. There is a proposal to push this up to 20%.

At the current redemption bonding curve of 60%, the protocol is offering 1 ETH back from the treasury for each 679,652 JBX burned. There is a proposal to change this rate to 95%, at which the protocol would be offering 1 ETH for about 459,219 JBX burned.

The price of JBX / ETH on Uniswap is currently 446,380 JBX per 1 ETH traded.

JuiceboxDAO currently has a reserved rate of 35%, which means 112,495 new JBX get reserved per ETH contributed to the treasury alongside the amount issued for the contributor. 30% of this goes to the DAO (dao.jbx.eth), 24% to jango.eth, 24% to peri.eth, 7% to nnnnicholas.eth, 7% to exekias.eth, 4% to CanuDAO, and 4% to WAGMI Studios.

Observations​

• JBX is currently trading in between the issuance and the burn rates on off-protocol markets such as the Uniswap AMM. There's currently no incentive for anyone to inflate or shrink the JBX supply.

The protocol says nothing about what might happen off-protocol. The following are just my assumptions and not financial advice.  

• If the market price of JBX increases past the protocol's issuance price, any additional demand of JBX can be fulfilled by contributing ETH to the Juicebox treasury which will in turn mint and distribute JBX.

Risk taking arbitragers might be incentivized to mint extra JBX at this funding cycle's rate to cover the 10% spread that will become available when the cycle rolls over and the discount takes effect. They can also benefit from information asymmetry by minting JBX to fill buy orders on off-protocol markets – the JuiceboxDAO community should work to minimize the opportunity for information asymmetry.

Either of these will benefit all JBX holders who have held their JBX from better rates during previous funding cycles – their share of the total JBX in circulation will shrink, but the ETH treasury that backs each JBX will grow at a faster rate, which has the effect of increasing the burn rate.

• If the price of JBX decreases past the protocol's burn rate, further demand to sell JBX can be fulfilled by burning JBX to get ETH that is locked in the treasury's overflow.

Again, arbitragers can benefit from information asymmetry by burning JBX to fill sell orders on off-protocol markets – again, the JuiceboxDAO community should work to minimize the opportunity for information asymmetry.

Either of these will benefit all JBX holders who chose to hold their JBX through the sell pressure – every JBX that is redeemed at a redemption bonding curve leaves some ETH on the table from its proportional share (60% curve leaves a lot more on the table for holders than a 95% curve, exaggerating the effect). In all cases except a 100% redemption curve, the JBX circulating supply will be decreasing at a faster rate than the treasury's ETH supply. This will marginally increase the burn rate for JBX with each subsequent burn, which will add upward pressure on prices, shrink supply, and leave only the holders that turned away the potentially mounting exit incentive to keep building.

• Over time as the market pushes against the issue and burn rates, a JBX holder's burn rate will increase and might eventually exceed the value that the JBX was minted at.

The more pressure on either side, the more the burn rate increases for each holder. On the other hand, the burn rate will stay the same if the market is being satisfied off protocol.

Tail market events benefit JBX holders most, albeit in a contained and measured way. The only thing that does not benefit JBX holders is the lack of change in JBX demand over time. Under this mechanism, it seems we are sacrificing price swings for resiliency.

• The DAO is spending ETH each funding cycle to pay out contributors, services, and grants as proposals get approved by JBX holders. The impact of this spending is spread across all JBX holders, marginally reducing everyone's burn rate.

The DAO could also allocate ETH off-platform in its multisig wallet or various other contracts across web3. This value is currently impossible to account for in the burn rate given the current version of the Juicebox protocol.

• The reserved token list only captures value when the token supply is growing. Once token supply has expanded and the market is satisfied off protocol, reserved token holders are massively incentivized to push the price up towards its limit.

• It is expensive to mint 51% of all tokens in existence, even without a reserved rate. If this were to happen, the ETH used to mint the token majority would immediately fund an increased burn rate for every token holder from previous cycles. The new influential JBX holder would have to appease a community with potentially significant exit incentive.

This same effect exists if the 51% is bought all-of-the-sudden by thousands of uncoordinated people on the internet.

• The DAO (dao.jbx.eth) currently receives 30% of reserved JBX tokens. The DAO is considering committing a percent of this built up supply to circulate among contributors via the DAO's discord.

It can do so in many ways, one approach is to split the allocation among the addresses on the reserved list, who are then encouraged to split this initial supply entirely between those who they work closest with and who's contributions they want to recognize. Those recipients are in turn encouraged to continue circulating this supply.

The goal is to make sure everyone who is building and maintaining the protocol and ecosystem becomes significant JBX token holders that can formally help the DAO make decisions.

If this internal JBX distribution system increases the governance participation of new builders and of those who steward the protocol, then the DAO may benefit from expanding this program by increasing the portion of reserved tokens allocated to the DAO treasury, and reducing the reserved token allocation to other recipients.

Before you start a project on Juicebox V1 or contribute funds to one, understand the following inefficiencies. These are shortcoming of V1 that have imperfect work arounds for now.

1. There is no pause button. The best you can do is configure the reserves rate to 100% if you do not want to give new contributors any tokens. You can set an address responsible for burning tokens as the reserved token recipient.

2. When a project's reserved rate starts at 0% and is then reconfigured to be higher than 0%, a new token supply will become available to distribute to the preconfigured reserved token recipients according to the rate chosen. For example, if moved to 100%, the total supply will double. Again, you can set an address responsible for burning tokens as the reserved token recipient. This inefficiency was discovered on August 18th. Here's more.

3. There is no direct burn transaction, but tokens will be burnt when redeemed. Therefor in order to burn, reconfigure your target such that there is overflow, then redeem tokens and then inject the overflow back into the treasury.

From the original post:

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

What if the simplest option was the best option?

Although deploying the same Juicebox protocol in each EVM compatible L2 environment forces projects to choose which they would like to operate on, it might be most reasonable to pass along this choice and complexity to each project while suggesting thorough operational strategies to weave these isolated environments together at the DAO/social/governance layer.

Here are some potential operational guidelines, using JuiceboxDAO as an example:

• Juicebox protocol is deployed identically on several L2s and side chains. JuiceboxDAO creates a project on each one where fees will be collected and contributions accepted.
• JuiceboxDAO will have different tokens on each chain. JuiceboxDAO membership is composed of a strategy that take each of these tokens into account. Members are responsible for managing the entirety of the DAO's treasury across all chains.
• JuiceboxDAO submits treasury reconfigurations to each chain independently. Each chain can have funding cycles that operate on different schedules, have different token issuance rates, and different ETH distributions. This flexibility can be used to orchestrate arbitrary multi-chain treasury designs, although also introducing management overhead. Extend to new environments responsibly.
• JuiceboxDAO can move its ETH/tokens between environments adhering to the constraints of each chain, leaning on existing and upcoming generalized bridging infrastructure.
• It can deploy converter contracts if it wishes to support conversions between each of its membership tokens.

Any other project could choose to operate on one or many environments where the Juicebox protocol has been deployed. If they choose to operate on many, they would have to manage the complexity of doing so. Once projects have begun experimenting and settling on effective patterns, I'd hope a playbook would emerge as a reference for future projects.

Leaving multi-layer coordination for the social layer introduces some operational overhead and risk, but also keeps the protocol layer flexible and simple.

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.

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