Skip to main content

12 posts tagged with "observations"

View All Tags

Year of the Dev

Β· 2 min read
Jango
JuiceboxDAO Contributor
  • 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.

Observations: State of JBX

Β· 6 min read
Jango
JuiceboxDAO Contributor

*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.

NOTICE: Juicebox V1 inefficiencies

Β· One min read
Jango
JuiceboxDAO Contributor

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.

Cross-layer Juicebox protocol: follow up #1

Β· 2 min read
Jango
JuiceboxDAO Contributor

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.

Cross-layer Juicebox Protocol

Β· 2 min read
Jango
JuiceboxDAO Contributor

Projects building on Juicebox need payment terminals that cost its contributors less gas to pay and redeem.

To do so, projects need to be able to accept funds across many different L2s alongside mainnet.

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.

JuiceboxDAO runs on the juicebox protocol itself, if we do nothing at the protocol layer and go with this simple option we will come across the same dilemma. If instead we preemptively consider how we can adjust the Juicebox V2 protocol to make cross layer operation simple for us, we'll likely also be making it simple for all projects who choose to build around juicebox treasuries.

An effective solution will take into consideration that:

  • projects do not want to fragment its community and governance across chains. All members should be cheering for funds to come in from wherever people care to contribute from, and the project's distributed tokens in turn should provide the opportunity to govern its cumulative funds regardless of what chain they're on.
  • the issuance rate of the project's tokens should be synchronizable across all available environments over time. As funding cycles roll over, it's often the case that the weight of token distribution changes. Unless it is by design, there shouldn't be arbitrage opportunities across chains.
  • funding cycle reconfigurations should either be approved or fail across all environments. If a project proposes to reconfigure its funding parameters in one environment but the ballot to do so ends up failing, the change should also fail to take effect in all other environments. On the flip side, successful funding cycle reconfigurations should be reflected across chains.

Stay tuned for specific proposals from me of how this might be achieve across rollup L2s, and please contribute to the conversation with your own ideas so we can arrive at the best possible set of solutions together.

Potential ways to handle the ConstitutionDAO refund

Β· 6 min read
Jango
JuiceboxDAO Contributor

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.

Current state of JuiceboxDAO membership

Β· 4 min read
Jango
JuiceboxDAO Contributor

JBX membership is currently represented by 602,065,173 tokens:

Jango has 118,891,959 (19.74%) Peri has 100,255,206 (16.65%) DragonFly Capital has 48,048,000 (7.98%) SharkDAO has 30,063,667 (4.99%) JuiceboxDAO has 27,827,807 (4.62%) 4 addresses each have around 18,500,000 (3%) 13 addresses have between 5,000,000 - 15,000,000 (1-3%) 7 addresses have between 2,500,000 - 5,000,000 (0.5-1%) 28 addresses have between 500,000 - 5,000,000 (0.1-0.5%) 64 addresses have between 100,000 - 500,000 (0.01-0.1%) 56 addresses have less than 0.01%

Membership has been given to those who have helped build the protocol and the DAO, and to those who have supported the efforts by sending ETH to the treasury, with a preference for those who helped in any capacity in earlier funding cycles. Membership has been open to all since the protocol was deployed.

Currently in Funding Cycle #8, each 10 ETH contributed to the treasury by new or existing members mints the following amounts of JBX:

2,579,260 for the contributing member

416,649 for JuiceboxDAO 333,319 for Peri 333,319 for Jango 97,218 for Nicholas 97,218 for Exekias 55,553 for WAGMI Studios 55,553 for CanuDAO

Today, it would take a contribution of 278 ETH for the contributing member to get 10% of the total membership tokens.

Two months ago in funding cycle #4, each 10 ETH contributed to the treasury minted 3,931,200 JBX for the member.

The total amount of JBX issued to members per ETH accepted is decreasing by 10% every 2 weeks. At this current rate with 2 week funding cycles and 35% reserved, in funding cycle #12 each 10 ETH contributed to the treasury will only mint 1,692,252 JBX for the contributor.

Observations​

  • Builders and contributors don't know what they're getting when they contribute ETH or are receivers of reserved tokens.
  • Membership is getting expensive.
  • JBDAOs strategy thus far has been to focus on building in the open, while making clear upfront the resources it needs to be able to build effectively.
  • No one in JBDAO has produced much work proposing how we might make membership more accessible to people or distribute it more widely, or why that might be worth prioritizing. Most of what is discussed is about how to solve problems for juicebox projects and for builders who want to come in and improve/grow the ecosystem.
  • The way JBDAO is using its 35% reserved rate ensures about 25% of any membership expansion the DAO makes goes to builders who are currently stewarding projects. If the DAO isn't growing its treasury, committed builders don't become substantial members. The remaining 10% go to JBDAO itself, which it hasn't done anything with yet.
  • The DAO's casual builders and helpers currently don't have a way to become members other than to make a contribution to the DAO of any amount.
  • It might be interesting for the DAO to tapper off its discount rate so that over time, members who consider joining are represented and feel welcome.
  • It might be interesting for the DAO to allocate all of a 35% reserved rate to itself so it can hand out some non-insignificant starter membership amounts to more people who are helping out casually, and to people who are currently cranking out tasks and getting to know the system but don't yet plan on sticking around for too long. The DAO could also give membership to other builders around web3 who might be creative and thoughtful voices to have in the room when determining how the DAO could allocate its treasury.

Open questions​

  • How might the DAO distribute its allocation of JBX effectively to add more great members now and into the future?

Reserved tokens as a mechanism for effective token distribution

Β· 3 min read
Jango
JuiceboxDAO Contributor

As funds are contributed to the JuiceboxDAO treasury – either as direct payments or as fees paid – JBX is minted and distributed. Currently, 35% of these are reserved and allocated to preprogrammed addresses while the remaining 65% are sent to the contributor of the payment.

The current distribution of reserved tokens for JuiceboxDAO is as follows: There is no cap to how many JBX are minted into existence: as more ETH is contributed, more JBX is created, albeit at a slightly decreasing rate over time due to the discount rate (currently 10% fewer JBX minted per ETH every 2 weeks). With each payment, the pie being shared grows while everyone's share of the pie slightly shrinks.

... except for those on the reserved tokens list. At any given moment, their overall JBX positions tend towards the percent of reserved tokens they're programmed to receive, at the rate of the treasury's growth. This also means that currently 35% of the DAO's value tends to concentrate between the reserved token holders, with the remaining 65% going to a long-tail distribution between those who chipped in or paid fees to the treasury over time, favoring those who did so soonest.

JuiceboxDAO's reserved tokens have thus far been mostly allocated to those few contributors shouldering operational responsibilities to the DAO. Recently the DAO also began reserving tokens for the DAO's multi-sig in order to redistribute to LP staking rewards and other programs.

Going forward, the DAO's greatest opportunity to coordinate incentives among its community will likely come through expanding the reserved pool to include many new members and campaigns with proven commitments to its success, as well as smaller scoped experimental distributions.

With a few basic guardrails and guidances in place such as those outlined in the DAO's governance documents, the DAO should be set up to fairly and efficiently welcome in meaningful contributors, while shedding those who are no longer participating or useful. This process should spread the value the DAO creates to the people actively furthering the project's mission statement, and to the projects building on the protocol who are paying fees over time.

I'm very eager to see more reserved token allocation proposals over the next several months, and for the number of reserved token receivers to grow substantially.

Aside​

The reserved rate also makes a 51% takeover very expensive. JuiceboxDAO currently has a total supply of 577,516,558 JBX tokens. Each ETH contributed mints another 544,320 JBX (353,808 to the payer, 190,512 to the reserved pool). In order for someone to mint 51% of tokens for themselves today, they would have to dump 3,865 ETH into the treasury. This will just get more expensive as time goes on since the total supply will increase over time as the number of tokens minted per ETH contributed decreases.

Juicebox V2: Protocol adjustments useful for adding treasury tokens to AMMs

Β· 7 min read
Jango
JuiceboxDAO Contributor

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.

Juicebox Observations 8/3/2021

Β· 4 min read
Jango
JuiceboxDAO Contributor

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.