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.