25 posts tagged with "update"

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.

Three trends have characterized these past 30 days:

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

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

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

Focus​

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

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

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

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

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

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

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

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

My proposal for FC#3:​

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

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

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

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

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

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

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

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

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

Core contributors

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

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

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

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

Experimental contributors

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

Allocations

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

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

Reserved token distribution:

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

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

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

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

I propose the following reconfiguration:

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

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

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

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

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

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

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

Payouts: $10,750 total

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

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

Reserved token distribution:

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

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

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

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

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

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

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

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

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

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

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

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

The Juicebox Protocol's bonding curve implementation can be seen in code here, and interactively here. In the interactive model, o is the current amount of overflow, s is the currently total supply of tokens, and r is the bonding curve. The x-axis is the amount of tokens being redeemed, and the y-axis is the amount of overflow that can be claimed by redeeming the x-axis amount.

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

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

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

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

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

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

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

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

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

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