Skip to main content

3 posts tagged with "ecosystem"

View All Tags

Β· 7 min read
Aeolian

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!

I spoke with @LexSokolin about DAOs, NFTs, and the performance art of launching network organisms on this week's Fintech Blueprint podcast. We talk @prtyDAO, @sharkdao, @juiceboxETH, & @franquipaola.

apple: https://t.co/k0fr3JdaE6 spotify: https://t.co/AeiRYPbmU3 nnnnicholas.ethβ›±πŸ‘˜ (@nnnnicholas) November 16, 2021

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.

Β· 6 min read
Jango

thoughts in progress. feedback always welcome. plz add to the conversation and let me know if i'm missing some context, it can be hard to keep up with it all.

ConstitutionDAO has reached some sort of a coordination moment. There are decisions to be made both technically and socially, and the PEOPLE will have their first opportunity to really use their voice.

Meanwhile us builders have another opportunity to evaluate and extend our current tooling to best support moments like this for people into the future.

Things we care about when considering refund design: speed, safety, cost, flexibility, convenience, (...?).

In the case of ConstitutionDAO, the refund could be handled in a few different ways (there are definitely others that I don't know of or am less familiar with):

Do it through Juicebox​

Steps:

  1. Inject the $40+ million back into the Juicebox contract.
  2. Multisig sends a tx reconfiguring ConstitutionDAO's funding cycle target to 0, allowing all tokens to be redeemable for a proportional share of all funds in the treasury.
  3. Everyone who wants to redeem their PEOPLE tokens can do so. All who wish to stay in and build out ConstitutionDAO can instead keep their PEOPLE tokens and leave their funds committed to the group.
  4. The DAO eventually reassess what it wants out of itself, and who will serve on the multisig to continuing operating the treasury on the community's behalf. DAO can also reassess if it wishes to open up to new members and contributions, etc. In other words, DAO continues to do DAO shit.

Notes:

  • -- I'd prefer if the Juicebox contracts were looked through by several more people before sticking $40+ mil in them. I personally trust them, but we need community trust and acknowledgement that this is risky experimental stuff. I would love to have the community's confidence in this decision. I'd love to do workshops over the next few days toward this end.
  • -- Every person claiming would have a gas fee to pay that would cost about the same as it costed them to contribute: $30-$60 bucks worth of ETH. This sucks especially for folks who contributed amounts around the same order of magnitude as the fee.
  • ++ This would require minimal coordination, everyone can take whatever action they choose, whenever they choose to.
  • ++ As the Juicebox process is being audited, the DAO could begin manually issuing refunds right away to people who send in their PEOPLE tokens to the multisig.

Multisig manually sends refunds to those who want it​

I saw versions of this idea from @strangechances, @DennisonBertram, and @austingriffith.

Steps:

  1. DAO reserves around $2 mil to pay for refund gas.
  2. Take a snapshot. Everyone who had a balance of PEOPLE tokens at a particular block number would be eligible to request a refund at a rate of 1 ETH per 1,000,000 tokens.
  3. The multisig would send tx's to fulfill these requests, covering the gas using the amount reserved.
  4. The remaining DAO has to reassess how it manages its tokens if it wants to continue to do DAO shit since PEOPLE tokens are no longer backed by ETH.

Notes:

  • -- multisig would have to coordinate around potentially thousands of payments.
  • -- it could take a bit for people to signal their request for a refund. The multisig would have a lot of double-checking and button-clicking to do upfront, and be on standby for a while.
  • -- the balances won't account for exchanges that happened after the snapshot.
  • ++ The cost of gas will be distributed between everyone who stays around. They DAO could even retroactively subsidize the entry gas fee of anyone leaving by issuing refunds ~$60 more than what was contributed, assuming there is a sizable enough community who wants to hold on to their PEOPLE tokens.
  • ++ People can have the option to request funds on a particular L2. The multisig can batch transfer its balance to each L2 accordingly and issue distributions from there.

Multisig deploys a Merkle Distributor airdrop​

Comment from @nnnnicholas. Disclosure: Nicholas is not a member-donor of ConstitutionDAO. It was also mentioned @austingriffith.

A version of this using Mirror Splits was proposed by @strangechances who offered to help execute it.

Steps:

  1. Take a snapshot. Everyone who had a balance of PEOPLE tokens at a particular block number would be eligible to request a refund at a rate of 1 ETH per 1,000,000 tokens. This is called a "snapshot".
  2. Deploy Airdrop/Split contract and send it total funds.
  3. Announce timeline for moving funds back to DAO treasury multisig to be claimed by those addresses captured in the snapshot.
  4. The remaining DAO has to reassess how it manages its tokens if it wants to continue to do DAO shit since PEOPLE tokens are no longer backed by ETH.

Notes:

  • -- This approach will still cost refunders a similar amount of gas to redeeming via Juicebox.
  • -- The PEOPLE tokens can no longer be used as a claim on the treasury, because people could then double-dip. PEOPLE tokens no longer function as normal Juicebox project tokens.
  • ++ The primary advantages of the airdrop approach is that it can use all or mostly audited code, increasing security as compared to Juicebox's unaudited redemption mechanism.
  • ++ This approach reduces gas costs for the DAO (i.e., the people who do not want refunds) as compared to multisig paying gas to send all refunds directly.
  • ++ The airdrop could be configured to allow redemptions on an L2, though this adds complexity.
  • ++ Allows contributors to retain their PEOPLE token but receive a refund.

... (pitch other ideas by listing steps and tradeoffs)


General notes:

  • Anyone whose contribution to ConstitutionDAO settled after the PEOPLE token distribution cutoff will be receiving a direct refund from the DAO.
  • The timing of the snapshot becomes very important in the scenarios that require one. Candidates include the time the Juicebox closed to new contributions, the moment the auction was lost, or some point in the future (i.e., pre-announced snapshot). Β 
  • Snapshots are captured using a Merkle tree that can be stored in an offchain database or IPFS as in Mirror's Split, which is based on Uniswap's UNI airdop Merkle-Distributor, or emitted as an onchain event stendhal-labs/collab-splitter. The latter would likely be expensive, but far less so than the DAO paying to distribute the refunds manually.

Β· 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.