14 posts tagged with "guide"

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.

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.

A project's overflowed funds in the Juicebox protocol can serve various purposes depending on the configuration choices the project makes.

A reminder, overflow is the amount of funds currently in a project's Juicebox treasury minus its current funding cycle's target, which specifies the amount allowed to be distributed from the treasury to preprogrammed addresses during the cycle. A project's token holders can burn their tokens at any point to receive a proportional amount of the project's overflow. This proportion can be affected by a bondingCurve also configured per funding cycle. A curve of 100% is a linear proportion.

Here are outlines of how a project's funding cycles might be configured to use its overflow for achieving various treasury designs:

Refund​

Overflow can be used to give all contributors access to their money back in the case of an unsuccessful campaign.

In the case of ConstitutionDAO, the project's first funding cycle is configured with a target of uint256.max, which allows free movement of any funds accumulated in Juicebox into preprogrammed addresses (the Gnosis multisig wallet). It is also set up with a duration of 0, which gives the project's owner (also the Gnosis multisig wallet) authority to trigger a new reconfigured funding cycle at any point. All ETH contributed mints a proportional amount of the project's tokens for the contributor.

The multisig could thus reconfigure the project to have a target of 0 and then inject all of its raised funds back into its Juicebox treasury, which would make all funds in the project considered overflow and therefor claimable by token holders. With the bondingCurve at 100%, each token holder could then burn their supply to receive the same amount of ETH they originally put in.

Ragequit​

A project can use its overflow to allow disenchanted token holders to exit and take with them a portion of the treasury's funds.

Only a project's overflowed funds in Juicebox are available to be claimed by burning tokens. If a project's funds are mostly kept in a multisig (or other contracts/assets), they cannot not be taken into account in the redemption value of a token (changing in V2). A project can thus tune the expected return of ragequitting by injecting liquid funds back into Juicebox, adjusting its target value, and loosing/tightening its bonding curve.

If a project is spending its raised funds at a faster rate than it is pulling in funds, or if the project's rate of token distribution has changed over time, it's likely ragequitting via the built in juicebox mechanism won't yield the same amount as initially contributed.

Shouts to MolochDAO for coining the term "ragequit".

Cash-back​

A project that sells products can use its overflow to give customers the opportunity for cash-back.

TileDAO, for example, currently sells artwork for 0.16 ETH. When works are minted, the sale price is piped into the TileDAO treasury, minting the project's tokens for the buyer in return. TileDAO might want to give its token holders incentive to hold these tokens by giving them utility, perhaps decision making weight in governance, otherwise holders might want to redeem them for some of the project's treasury. This redemption would essentially give the buyer of the art some cash back, the value of which determined by several aspects of the project's funding cycle choices over time.

Realizable profits​

A project can inject funds into its treasury from arbitrary sources, giving all token holders access to them by burning tokens.

The simplest example here would be a project that gathers funds via a Juicebox project to purchase a thing, then turns around and sells the thing for more than what it paid. The funds from the sale can then be injected back into the Juicebox project for token holders to claim if they choose to do so.

Consistent through all of these examples are consequential choices that a project can make to offer its community particular treasury designs over time. The address that controls the NFT representing a Juicebox project has the power to make these choices. Whichever EOA or contract stewarding this responsibility on a community's behalf should be scrutinized and held accountable to the extent each community sees fit.

Hopefully what these examples make clear is that the tokens issued by projects using the Juicebox protocol have no intrinsic value. They can, however, be used by projects as a utility for making decisions, the outcomes of which can give them value. It all depends on the choices we make together over time, and the social and algorithmic contracts we use to make these choices binding.