You can claim your JBX here! For more information, read on.​

---

Background​

Juicebox's legitimacy as a DAO is built upon sufficient decentralization of power, access, and ownership. To accomplish this ideal, Juicebox must attract and retain an active community that has Juicebox's long-term interests in mind.

One of the most direct methods for improving decentralization is the airdrop. Several airdrop proposals were made to this effect in FC#15, all of which were rejected.

JBP-103 - Distribute JBX to JBX Holders

JBP-102 - Distribute JBX to Juicebox Projects

JBP-101 - Distribute JBX to v1.1 Party Attendees

JBP-100 - Distribute JBX to Nicholas’ List

JBP-99 - Distribute JBX to Extended Community

As part of a new airdrop proposal, ARCx has crafted a Juicebox Benefits Score which identifies Juicebox community members based on their token holding behaviour and governance participation.

See JBP-114: Juicebox Benefits Airdrop

---

Score Methodology​

The Juicebox Benefits Program identifies and rewards active community members who hold Juicebox DAO’s long-term interests at heart. The score rewards active contributors by measuring governance participation, and rewards long-term support by measuring how long a wallet has held JBX.

Governance Factor (60%)​

The Governance Factor measures the number of Juicebox Snapshot proposals that a wallet has voted in. The wallet with the highest Governance score is given 600 points, and the wallet with the lowest score is given zero. All other wallets are linearly scored within those bounds—for example, a wallet that voted in half as many snapshot proposals would be given 300 points.

HODL Factor (40%)​

The HODL Factor measures the number of UTC dates that a wallet has held at least 1 JBX (either claimed or unclaimed). The wallet with the highest HODL score is given 400 points, and the wallet with the lowest score is given zero. All other wallets are linearly scored within those bounds—for example, a wallet that held JBX for half as many dates would be given 200 points.

---

How to Claim​

Visit airdrop.juicebox.money and connect your wallet to see if you are eligible. You can also claim a free passport to view this score (and other scores) on arcx.money.

On 2022-06-07 at 22:00 UTC, any unclaimed JBX which remains in the smart contract will be returned to the multisig for future use.

Your score on arcx.money might not be the same as your score on airdrop.juicebox.money. To prevent sybil attacks, the airdrop scores were measured at Ethereum block 14,263,369.

---

What's Next?​

Going forward, the community could use the Juicebox Benefits score to make new airdrops, to set up a gated Merch Squad collection, to make gated Discord roles, or even to create exclusive Juicebox-themed ARCx passport skins. These scores are verifiable onchain, meaning they can be permissionlessly used in smart contracts or used through an API.

Some other examples mentioned by ARCx include:

• Distributing airdrops equitably
• Boosting smart contract staking yields
• Verifying social status via Discord roles
• Offering free smart contract insurance to the best users
• Fee & product discounts
• Many more

This score evolves with your behaviour over time! Although the methodology could evolve, Juicebox Benefits projects aim to reward active contributors which support Juicebox's long-term goals. Your participation and support of Juicebox will be reflected in these scores over time.

If you have ideas or suggestions, share them in the ARCx Discord or in #jbx-benefits on the Juicebox Discord.

---

Verify​

Airdrop contract: 0x518e3CdBcda4f0735399c9F1e03A7aBC7562632f Merkle root: 0xba0ccda021dd3008d51728ccd530dfe42d6bba07f8118d8a796e26d80e305009 Sweeper: 0xAF28bcB48C40dBC86f52D459A6562F658fc94B1e

Main Repository

Airdrop CSV

Merkle Root(use yarn && yarn generate-list to verify).

Airdrop contract on Etherscan

---

arcx.money｜ARCx Twitter｜ARCx Discord｜juicebox.money｜Juicebox Twitter｜Juicebox Discord

• Devs aren't just coders. Anyone who recognizes genuine inefficiencies and makes themself useful toward delivering great solutions is a dev.

filipv, STVG, twodam, zeugh, phytann, sage, mieos, nicholas, zom-bae, mrgoldstein, zhape, westlife29, linywan, peacenode, germs, gulan, and a few other JB friends don't contribute code to the core contracts or site, but they show up to dev everything else they recognize can add value: governance, tools, dev ops, analytics, Banny, cryptovoxels empire, Discord bots, podcasts, translations, education, bookkeeping, support, strategy etc.

• Devs are individuals, not entities. DAOs, VCs, corporations, campaigns, and projects may have great devs within them, but aren't devs themselves.
• Devs like to dev with other devs.
• Devs are often artful.
• Devs are never zero-sum thinkers.
• Devs should continue to improve how we build alongside each other at scale and audit each other's work along the way. More agency, less management.
• Leaders are devs who also delegate effectively between other devs. Any dev can be a leader, the more the merrier.
• Devs should continue to work towards improving the experience of other devs.
• Devs who build in the open have leverage.
• Resources follow devs.
• Power decentralizes as more people become devs.

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

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

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

Features​

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

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

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

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

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

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

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

Currently there is no fee cap.

Bug fixes​

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

Other adjustments​

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

Communities using Juicebox can leverage their reserved rate decisively when they want to make it more difficult for new members to join. Funds can still be received, but more of the newly minted tokens will be owned by the project itself. The current project members can use this to decide how they will manage their subsequent growth on a per-funding cycle basis.

When the project wishes to make membership more accessible again, members can do so by lowering the reserved rate.

There's currently a discussion happening in JuiceboxDAO deliberating if it might be wise to move its reserved rate from 35% to 50%.

The reserved rate can also be useful for other purposes, this is just one possible metaphor that can be used to guide decision making.

Becoming a contributor at JB wasn't exactly intentional.  It wasn't until a conversation with a community member that I was able to articulate and realize that getting paid was more than just a possibility. I had first learned about DAOs a few years ago but never really understood what they did or how they got things done.  How do DAOs coordinate? How do they align their philosophy?  How did they keep each other accountable?  All of these questions were very difficult for me to wrap my head around. I then stumbled upon JB after finding out about the NOUNS project and then finding SharkDao which was using Juicebox for its treasury.

What I talked about with this JB community member was the fact that I didn't say a word in Juicebox for 2 - 3 weeks.  I attended a couple of town hall meetings and listened in on some voice chats that were happening, not knowing what the agenda was or what they were going to be talking about.  I remember reading a bunch of  threads in Discord, trying to follow one or two specific issues, to see how the community tried to solve them.  What became clear was that it was important for me to not try to understand what a few people were doing, but to try and understand what the community was doing.  That was an epiphany for me.  It made me ask, "where do this community's values and my personal beliefs and ethics intersect?"

This was the moment I started to look for tasks that helped me align myself with the community philosophy.  I started to shift my mindset from a quiet observer to thinking about how I could provide value that  could help advance the protocol and in turn, the Juicebox Community.  As I was exploring, I realized that I was also learning how to navigate the community.  How to navigate the notion, the web site, the Discord and everything else that might go along with JB.

To those wanting to become Juicebox contributors: follow a couple of tasks or issues and see how those issues are being solved by the community.  Then see if those solutions line up with how you might handle those issues. That doesn't mean you have to agree.  It just means that how we talk to each other and how we interact with each other lines up with how you want to talk to people and how you want to be talked to.

If you start this way, not only will you find a way to contribute but you will see that the Juicebox community will help you contribute.  You'll see that Juicebox will view you not just as someone that has a valuable skill but someone that has a philosophy that aligns with the goals of the Juicebox community.

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

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

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

---

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

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

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

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

Observations​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Entering the world of decentralized autonomous organizations (DAOs) is kind of like opening the gates to Narnia: it's thrilling, it's confusing, and because real money is involved, it's somewhat scary.

Late 2021 appears to be the frontier of DAOs, and best practices and playbooks for starting and governing DAOs are being written as I write this.

In particular, the DAO stack - the set of software tools required to run a DAO - is beginning to mature. One such example is Juicebox - a DAO treasury protocol - which was recently picked by the ConstitutionDAO to raise almost ~47million USD in an attempt to buy a copy of the United States Constitution.

In this article, we'll define the fundamental functions of a DAO and describe the tools required to fulfill these functions. The content is a derivative of Juicebox contributor @nnnnicholas 's episode on The Fintech Blueprint Podcast; if audio is your thing, check it out!

What's a DAO do?​

At present, a DAO is more of a concept rather than a strict organizational definition. We'll talk about DAOs as they are being used today in the crypto/NFT world. In this world, a DAO has 2 main functions:

1. Building a treasury of assets (NFTs, Ethereum (ETH), or some other token)
2. Governing the treasury

Let's say your favorite podcaster decides to set up a DAO for their podcast. They need assets (read: money) to keep the podcast going and do bigger and better things like merch and in-person events. So, they need a way to build a treasury of assets. They'll issue an ERC20 token (let's call this token $PODC), and anyone who contributes funds to the treasury will receive $PODC token in exchange. You, the listener, believe in this podcaster and want to be a part of their success. So you buy some $PODC token and contribute to the treasury.

As a $PODC token holder, you have perks. You can propose changes to the podcast format and make guest proposals, and you can also vote on other proposals. You and the other token holders now have skin in the game - or skin in the podcast - and have a meaningful impact on the podcast and its success. The DAO can be creative here, too. Holding a token might grant you access to a private discord, private meetings, or airdrops. In a successful DAO, the DAO may vote to distribute excess funds to token holders.

Don't like what the DAO is doing? No worries! Your tokens are 100% backed by the treasury, meaning you can sell your token back to the DAO and receive your original investment (less gas and other fees).

An attractive characteristic of a DAO when compared to a traditional private company is transparency. Every aspect of the DAO is available on and verified by, the blockchain. Any eager individual can observe the flow of assets and call out dodgy activity. Importantly, no accountants or lawyers are required!

The DAO stack​

To achieve the 2 functions of a DAO, we're going to need some tools. Luckily, smart folks are putting in the leg work and the DAO stack is maturing rapidly. Below, we'll discuss Juicebox, Gnosis, Snapshot, and Aragon - 4 key tools in the DAO stack - and how they fit together to form a DAO.

Juicebox​

The Juicebox protocol is a programmable treasury. In practice, you can think of Juicebox as a decentralized alternative to Kickstarter; a way to raise funds on the blockchain. It fulfills the first function of the DAO: building the treasury. Technically speaking, Juicebox is a set of smart contracts deployed on the Ethereum blockchain that handles the issuance of tokens and the building of the treasury.

In our podcast DAO example, the podcaster would create a Juicebox project. They can define various parameters that dictate how the project will operate, like funding targets, the exchange rate, payouts, and the number of tokens reserved for founders. The Juicebox project has an associated token: $PODC. To contribute to the podcast DAO's treasury, I would head to the project's page on https://juicebox.money, connect my Metamask wallet and contribute ETH. In exchange, I would get some $PODC token based on the Juicebox project's predefined exchange rate.

Gnosis​

Who "owns" the treasury? A single person could own the treasury, but nothing is stopping them from running off with the bag besides reputational risk.

Enter: the multi-signature wallet, commonly known as a "multisig". A multisig is fundamentally a contract that can hold assets and execute transactions, with one exception: it requires the signature of more than one address to execute transactions. Just like a business where you need multiple signatures to do anything, a multisig requires some number of signatures (typically m of n, say, 2 signatures out of 3 signatories) to execute a given transaction.

So, when setting up the podcast DAO, we would create a multisig between the podcast founders (say, the 2 podcasts hosts and any other significant contributors). The multisig would be the owner of the Juicebox project. This allows us to have multiple individuals controlling the parameters for fundraising so that no individual can go rogue.

Gnosis is the go-to tool for creating and managing multisigs. It provides a clean and simple UI to enable the management of a multisig. Signatories connect their Metamask wallet and can approve and reject transactions from Gnosis.

Snapshot​

How do you vote with your DAO tokens? Snapshot.org! Snapshot is an off-chain voting tool used to propose and vote on changes to the DAO. It leverages IPFS to store votes.

A proposal is just a document that lays out some change to the DAO and gives a single choice amongst multiple options in a voting mechanism. Anybody holding the DAO's token can vote on a proposal for which result they prefer. For example, someone might create a proposal on Snapshot that a certain person is interviewed as a guest on the podcast. As a $PODC holder, I can navigate to the proposal on Snapshot.org and vote yes or no. The weighting of my vote is proportional to the amount of $PODC I hold.

A proposal is accepted by the DAO when a certain number of votes is reached (say, two-thirds, or 67%). When a proposal is accepted, it is the responsibility of the multisig signatories to carry out the proposal.

Importantly, there is an element of trust required for this to work effectively. At the end of the day, the multisig signatories have complete control over the treasury, and they have to be willing to carry out the wishes of the DAO. This risk is mitigated by the nature of the multisig: because it requires multiple signatures, the likelihood of coordination amongst bad-acting signatories is somewhat mitigated. Reputation is on the line, too, so signatories are somewhat incentivized to act in the best interest of the DAO.

Aragon​

As noted above, Snapshot voting happens off-chain, but on-chain voting is possible. In comparison, Aragon provides on-chain voting. With Aragon, no aspect of the DAO is happening in your web browser. Instead, absolutely everything would be executed as a transaction on the blockchain. In some sense, this makes the DAO more decentralized, but also a little bit less agile and quite a bit more expensive to interact with.

Takeaways​

DAOs are becoming more and more popular, and there is no single playbook for creating a DAO. We are in an ecosystem of DAO tooling. Juicebox, Gnosis, Snapshot, Aragon are composable tools that can be mixed and matched with each other to create the infrastructure that is a single DAO. Each DAO will make different choices about which pieces of tooling and what level of decentralization is appropriate for their project and goals.

---

Follow [@aeolianeth] on Twitter.

In its first funding cycle, each project issues 1,000,000 tokens for each 1 ETH received.

Level 0​

In its simplest form, a Juicebox project can be configured to fundraise and provide refunds.

Example: I pay 5 ETH into a treasury and receive 5,000,000 tokens, and you pay 5 ETH and receive 5,000,000 tokens. There are now 10 ETH in the treasury and 10,000,000 tokens total. Since I own half of the tokens, I can redeem them to get half of the treasury's total – in other words I can get a refund. You can do the same.

Level 1​

A reserved rate can be added which will allocate a percentage of the minted token supply to a preprogrammed list of addresses.

Example: The project sets a 10% reserved rate that goes to the DAO's multisig address. I pay 5 ETH into a treasury and receive 4,500,000 tokens, and you pay 5 ETH and receive 4,500,000 tokens. The DAO's multisig now has access to 1,000,000 tokens. Because of the reserved rate, I can no longer redeem my tokens to get a refund – I will only get 90% of what I paid.

At a reserved rate of 100%, no tokens go to new contributors.

Level 2​

A funding cycle target can be set which blocks off some funds from the treasury that can be distributed by anyone to a set of preprogrammed addresses.

Example: The project sets a target of 1 ETH. I pay 5 ETH into a treasury and receive 5,000,000 tokens, and you pay 5 ETH and receive 5,000,000 tokens. The treasury now has 10 ETH –  1 ETH is within the target, and the other 9 are considered overflow. I can redeem/burn by tokens to receive my proportion of the overflow, which is 4.5 ETH. The 1 ETH target is still distributable to the project and not accessible to token holders.

Level 3​

A redemption bonding curve can be added which reduces the amount of the treasury that can be reclaimed by redeeming tokens.

Example: The project sets a 50% bonding curve. I pay 5 ETH to the treasury and receive 5,000,000 tokens, and you pay 5 ETH and receive 5,000,000 tokens. Because of the redemption bonding curve, I will only receive ~2.5 ETH if I redeem my tokens. The rest is left to share by those who are holding, so you could now redeem your tokens and get the remaining ~7.5 ETH.

Level 4​

A discount rate can be added to decrease the rate of tokens that are minted and distributed when contributions are received over time.

Example: The project sets a 10% discount rate and a 14 day funding cycle duration.  I pay 5 ETH to the treasury and receive 5,000,000 tokens on day one during the first funding cycle. Fourteen days later during the second funding cycle, you pay 5 ETH and receive 4,500,000 tokens.

Level 5​

It is important to note that a project can change its reserved rate, target, redemption bonding curve, and discount rate on a per-funding cycle basis. Some projects might choose to have no funding cycle duration for the most flexibility, meaning they can reconfigure the project on demand. It is really important to trust the owner of the project because they have a lot of control to shape the tokenomics.

A project can also set a ballot contract in its funding cycle to create conditions according to which all proposed reconfigurations must abide.

Example: The project sets a 3-day delay ballot contract. If the project owner wants to reconfigure any funding cycle property, the transaction to do so must be sent at least 3 days before the end of the current funding cycle. If the reconfiguration was made within the 3 days, the next funding cycle will instead be a copy of the current one, and the reconfiguration would be eligible to take effect after that one.

People can build arbitrary ballot contracts as long as it conforms to IFundingCycleBallot.

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

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

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

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

From the original post:

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

What if the simplest option was the best option?

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

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

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

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

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