19 posts tagged with "dao"

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.

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.

The first JuiceboxDAO configuration includes a preprogrammed reserved JBX rate of 10%, with distributions to predetermined recipients.

A new supply of JBX is minted each time the project receives a contribution. This JBX goes to a beneficiary address specified by the contributor (usually themselves), with the exception of the reserved tokens. A 10% reserved rate means 10% of these newly minted tokens will be distributable to preprogrammed recipients.

As a result, the configured recipients "vest" their JBX at the rate of the project's growth instead of a cliff/lock schedule. Screenshot from https://juicebox.money/#/p/juicebox

Investors​

• Jango gets 40% of reserved tokens for architecting the mechanism, writing the contracts, thoroughly testing the ecosystem, leading design and development efforts post-launch, and leading project relations.
• Peripheralist gets 40% for architecting the front-end repo, publishing juicebox.money, and leading front-end dev work post-launch.
• AtomicMieos gets 10% for experimenting with content, and helping shape ideas pre-launch and post-launch.
• Sage gets 10% for design and illustration work pre-launch and post-launch.

These numbers are all a bit arbitrary. We decided to start off fairly small and fairly even – it was unclear how the risk profile of pre-launch dev work would compare to post-launch growth and refinement work, and how the Juicebox incentives mechanisms would play out in the wild. As the first funding cycle unfolds, expect a proposed reevaluation of these numbers to better account for risk dynamics and incentives.

The first Juicebox configuration for the JuiceboxDAO lasts 30 days, and includes preprogrammed payouts. They are as follows:

Staff​

• Jango gets $5k for managing contracts and leading dev and design efforts.
• Peripheralist gets $5k for leading front-end dev work and evolving Juicebox to suit needs being uncovered at TileDAO.
• AtomicMieos gets $1k for experimenting with content, and helping shape ideas.
• Sage gets $1k for design and illustration work.

Ops​

(These funds all get paid-out to the JuiceboxDAO governance to be allocated)

• $6.8K to pay back Jango for pre-purchasing juicebox.eth, jbx.eth, and jbox.eth. These ENS names will be transferred to JuiceboxDAOs governance.
• $1k will be allocated for content / art supplies, managed by Futurenate and Sage.
• Figma costs $75 monthly.
• Infura costs $50 monthly.
• Gitbook costs $32 monthly.
• Fleek costs $10 monthly.

The total is $19,967.

The staff payout sums are small compared to market rates for these skills. We decided to start off with a small budget during the first funding cycle to encourage a longer runway, and to be able to re-evaluate needs as the first funding cycle plays out.

Stay tuned for a report on the first funding cycle's spending, and a proposal for the next funding cycle's payouts.

The Juicebox contracts were deployed to Ethereum two days ago. Yesterday, @peripheralist, who built the juicebox.money website, launched a generative art project called Tiles using the Juicebox protocol as its treasury, http://tiles.art. He started a DAO around it, https://discord.gg/bgGwmjWJ85.

With Juicebox, we had built a business-model protocol. With Tiles, he built a beautiful, expressive, and flexible collection of generative art to rally a community around. Neither of us had much of an idea what would or should happen next, but I was excited to take a step back and find out.

My conclusion: From a growth perspective, we can either go out and look for more entrepreneurs and artists that could benefit from using Juicebox, or we can lean into TileDAO since it's the one project that currently uses Juicebox. Since building stuff > shilling stuff is an invariant for me, I think the best thing I can do right now as a $JBX token holder is to participate in TileDAO and help grow it. As other projects start considering building on Juicebox, our job will be to become supporting cast member of their community also.

The founding contributors pre mined JBX tokens to backpay the contributions made. The valuation of each token was the same as it is now during the first funding cycle.

• Jango got $125k for developing and testing the smart contracts.
• Peripheralist got $125k for writing juicebox.money.
• AtomicMieos got $10k for always being around to help shape ideas.
• Sage got $7k for design and illustration commissions.
• Nervetrip got $3k for helping to write an early prototype and do code reviews.
• Austin Griffith got $3k as a thank you for his work on Scaffold ETH, which Juicebox is built using.
• Paul Razvan Berg got $3k as a thank you for writing and testing solidity helper libraries that I used extensively. Especially for math operations on e18 numbers.
• **Teddy Wilson **got $1k for submitting a very useful PR that automates test routines.
• Apoorv Lathey got $200 for a small PR he made to the repo when the code was just getting started.

The numbers are a bit arbitrary, but hopefully enough of you think its a fair start. If not, theres no shame is speaking up. We can always make changes to our reserved token allocation in upcoming funding cycles to rebalance pre mine compensation.