Skip to main content

· 5 min read
Jango

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.

· 7 min read
Jango

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.

· 7 min read
Jango

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.

· 3 min read
Jango

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.

· 4 min read
Jango

Juicebox was deployed 19 days ago.

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

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

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

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

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

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

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

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

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

This dynamic can of course be tuned over time.

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

· 2 min read
Jango

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

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

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

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

· 2 min read
Jango

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.

· One min read
Jango

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.

· 2 min read
Jango

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.

· 2 min read
Jango

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.