Deepening 1hive's Investment in Gardens-v2 via Juicebox and Community-Wide Protocol Fee Exemption

🌿 Proposals
#1

Proposal Title: Deepening 1hive’s Investment in Gardens-v2 via Juicebox and Community-Wide Protocol Fee Exemption

Proposal Information

Gardens-v2, the innovative DAO management platform nurtured by 1hive, has launched its next growth phase through a Juicebox financing campaign (Link). This proposal aims to reaffirm 1hive’s commitment to its homegrown project by actively participating in this fundraising effort.

As an incentive and reward for the 1hive community’s continued support, we propose acquiring a special NFT that grants all 1hive members a complete exemption from protocol fees on the Gardens-v2 platform. This unique benefit allows the entire community to directly share in the financial success of the project they helped foster.

Protopian NFT:

This NFT is unlocked after purchasing a minimum of π (3.1416) ETH worth of Garden’s Juicebox tokens.

image
image584Ă—742 118 KB

Proposal Rationale:

1hive’s participation in the Gardens-v2 Juicebox campaign not only provides crucial funding for the project’s development but also serves as a powerful endorsement within the Web3 ecosystem. This reinforces Gardens-v2’s credibility and demonstrates the DAO’s confidence in its long-term potential.

The community-wide protocol fee exemption NFT is a tangible reward for 1hive members, aligning their interests with the success of Gardens-v2. This model fosters deeper community engagement, strengthens the bond between 1hive and its incubated project, and showcases the power of decentralized collaboration.

For Gardens-v2, this deepened collaboration secures crucial resources through the Juicebox campaign while solidifying the invaluable strategic partnership with 1hive, a community renowned for its innovation and decentralized governance expertise.

Expected duration or delivery date:

The NFT granting protocol fee exemption will be purchased immediately upon the DAO’s decision* to participate in the Juicebox campaign. The positive impact of this investment and community-wide incentive on Gardens-v2’s growth trajectory will be continuous and significant.

*10% of signaling will be considered as a community decision to appprove this funding operation

Funding Information

No Honey request from the common pool. Instead we would use the ETH from the 1hive treasury safe.
Amount of Juicebox token to be purshased to earn the NFT: 20891 Gardens Juicebox (~11k USD)

Ethereum address where funds shall be transferred: 0xc6c2E9EFB898A42DB4137B07b727b45e0C353d81 (Gnosis 1hive treasury Safe link)

Gardens’s Safe on mainnet: 0x1B8C7f06F537711A7CAf6770051A43B4F3E69A7e

The HNY requested will be swapped within the 1hive treasury for the necessary tokens to participate in the Gardens-v2 Juicebox fundraising campaign at the Protopian NFT tier. The minted NFT will be held by the Garden’s safe in mainnet until transferred to the yet-to-be-determined Council safe of Gardens V2’s 1hive community.

Juicebox campaign funding usage distribution (ETH):

Note that there is also a 30% of juicebox token issued to Gardens that will be distributed for contributors and growth initiative.

Summary of the flow:

[Gnosis] 1hive Treasury Safe:

  • Out: 11K USD in wETH bridged to mainnet

[Mainnet] Gardens Safe →

  • In: Bridged tokens
  • Out: Swap tokens to ETH and fund Gardens project through Juicebox
  • In: 20891 Garden’s Juicebox tokens + Protopian NFT
2 Likes
The case for Redemptions
#2

There has been some discussion about how 1Hive will use Gardens v2, but it doesn’t seem clear to me that we would want to enable community fees at all, so the NFT wouldn’t actually be necessary for the community to avoid protocol fees.

If a signaling proposal is used like that I will dispute it, I think this would essentially be circumventing how funding proposals are intended to be used. A funding proposal should be used to request Honey from the common pool and then it can be converted as needed to complete the requirements of the proposal.

However, in this case such a proposal would not be possible given the request would be too high a proportion of the available Honey. This is indicative of a larger issue related to linking the value of Honey to the value of the Treasury, but I’d rather shine a light on that issue and seek a remedy then set a bad precedent by circumventing our funding mechanism for this proposal.

#3

I agree on the part that it looks like circumventing. I was kind of collecting alternate solutions as well, this is why I shared this with Sage. But we should definitly have 1hive showing interest on his incubated project otherwise who will ? :smiley:

#4

I don’t know how much influence 1Hive has in that regard… I would hope that prospective investors would be able to look at Gardens v2 and its target market and come to their own conclusion.

Either way, pretty much all of our current outflows are already going to the Gardens team via streaming proposals. So we are definitely showing continued interest even if 1Hive doesn’t participate in the juicebox round, no?

#5

Cross-posting from Discord.

The Gardens team made some updates to our Juicebox campaign that should make it much more attractive for 1Hive. These are:

  • Protocol fee sharing - 4.5% of Gardens v2 protocol fees will now be split between Protopian holders, and 0.5% will be split between Beekeeper Holders.
  • Premium community placement - Protopian holders can create communities with featured placement in the v2 app.
  • NFT cap reduced - minting limit lowered to 100 Protopians and 500 Beekeepers.

The campaign also uniquely benefits 1Hive since the community already gets 10% of Juicebox proceeds, and is also likely to benefit from the 50% of proceeds being set aside for future Gardens token liquidity. Plus, we can leverage a 1Hive Protopian purchase for visibility / marketing, and to get some of the other communities we’re working with across the finish line on their own Protopian buys. With all this, I’m feeling much more confident advocating for this as a good investment move for 1Hive. (edited)

1 Like
#6

Intro:

  • As a ROI perspective, the benefits of acquiring a Protopian NFT have recently increased significantly, prompting us to re-evaluate the possibility of 1hive obtaining one. (See previous message from @paul for more details)
  • Given the current HNY situation, a traditional Funding Proposal is not feasible.
  • We initially explored a direct request from the Common Pool, but this proved unsuitable.

image

Proposed Solution:

  • We are proposing a signaling proposal against the 1hive treasury.
  • If the required conviction threshold is reached, a manual transaction will be executed to withdraw the necessary WETH (3.141592 ETH) from the treasury safe to purchase a Protopian NFT priced in Juicebox tokens.

image

Treasury representation:
image

Key Metrics:

  • Conviction required to pass: 469.31 HNY
  • Threshold needed to execute: 4.09%
  • Requested percentage against the treasury: 3.17%

Additional Proposal:

  • Leveraging the signaling proposal’s flexibility, we’ve included a secondary threshold for acquiring an additional Protopian NFT. Calculations provided:

image

Links:

#7

I’ve disputed the signaling proposal as I said I would above if it was used in this way. But I’d like to expand on that point for the sake of anyone who may get drafted by Celeste in order to make their decision on whether or not the proposal should be allowed, and I would hope that the council multisig members would at least respect the decision of Celeste in that regard.

To provide some context… I contributed significantly to the design of 1Hive, have spent a lot of time thinking about and feel confident speaking about the intention behind many of those design choices. One of the design choices which is relevant here is the use of Honey as the common pool asset rather than something like DAI or even ETH. The idea was for the community to use Honey as a store of value for the community, which would encourage us to work together to make Honey valuable and to direct outflows from the common pool towards activities which were productive and would grow the value of Honey (either by increasing demand, or simply by collecting and returning honey from the market back to the common pool). The expectation was that by holding honey, you were making a bet on the communities ability to direct resources and grow the value of honey, not simply to reward contributions toward public goods by inflating honey indefinitely. When you contributed labor and earned honey in exchange, you were earning a sweat equity in 1Hive and since Honey was a liquid asset you could choose to hold onto that or sell it to someone who wanted to speculate on it instead.

What we have found in practice is that it is extremely valuable and highly pragmatic to be able to accumulate value and have exposure to a more diverse set of assets than just automatically converting all incoming value back into Honey. It allows us to accept grants from related communities in their native assets (like we did with Agave and STAKE/GNO) and even use those assets productively (like when a community member ran a gnosis validator on our behalf). So the result is that in practice we supported efforts which didn’t immediately convert value directly back into Honey but instead accumulated that value in various multisigs which have mostly been consolidated into what we now call the council safe.

This I think is the crux of the issue, and why I have challenged the proposal. Given the current value of Honey, the supply and the share of the supply in the common pool, making a request for the amount this proposal is requesting would not be possible because it would require more than 100 percent conviction to pass.

As this post also points out, if we were to consider the current value of the treasury held by the council safe as the common pool, it would be possible to make a proposal requesting that amount and pass it with a relatively minimal amount of conviction.

But even if it matches the parameters, it does not make sense to use the entire treasury amount as the common pool value. If we think about the original intention of the protocol, we would be converting that value into Honey (by buying it on the market and transferring it to the common pool), this would mean that we would be increasing the price of all Honey and also increasing the balance of the common pool relative to the total supply. This is an important distinction in terms of how things work and the expectation that someone who holds Honey would have with regard to how value flows through the 1hive protocol, but it also factors into the calculation used to determine the threshold required to pass a proposal. Unfortunately it is somewhat difficult to determine exactly what the result would be given that it would not make sense to use the treasury to buy honey as a single transaction, and if done over time its hard to predict exactly what effect would be making it not really feasible to use this to come up with an accurate “threshold required to pass”.

Another approach would be to use the hypothetical redemption value as the price for honey, then calculate the required amount of honey based on that, and use the existing gardens v1 interface to determine the required support for a proposal.

For example:

Price of Honey = Total Treasury Value / Total Honey Supply = 363340 / 57398 = 6.33
Requested Tokens = Dollar Amount Requested / Price of Honey = 11500 / 6.33 = 1816

image
image1216Ă—540 45.5 KB

This approach would also work with actual funding proposals so we wouldn’t need to use signaling proposal with arbitrary thresholds at all, with the understanding that a proposer can request to exchange the Honey they receive from the common pool with the council safe for its redemption value in whatever mix of assets are required.

EDIT: removed note about there not being a link to the spreadsheet where this is calculated, It’s there at the bottom I just missed it on my first read.

1 Like
#8

1Hive’s governance does not account for tokens other than Common Pool Honey being held by the DAO. This is a clear design shortcoming of 1Hive.

We’re solving this in Gardens v2 by letting communities create multiple conviction voting pools, each with their own token, all tied to the same Covenant. For now though we’re stuck with the system we have.

This proposal treats the ETH tokens in the Council Safe as if they were in their own conviction voting pool with the current parameters of 1Hive. Note that the ETH in the Council Safe only makes up around 1/3 of the value of non-HNY treasury assets, and around 1/4 of all of 1Hive’s AUM, so the majority of value 1Hive holds isn’t being used in this calculation.

I don’t buy into the “hypothetical redemption value” concept, and the idea of moving all of 1Hive’s treasury assets into Honey is highly controversial and I would not support a proposal suggesting we do that.

Given our situation, it makes most sense to me that we would treat funding proposals for non-HNY tokens in the Council Safe as if they were funding proposals for HNY in the Common Pool, and we would treat larger decisions - like moving the entire treasury somewhere new - as a Decision Vote and use that proposal type.

#9

Agreed. Let’s prioritize coming to consensus on how to fix that and fixing it.

This is not clear in the above post, it implies that the calculation is being done on the treasury total value, not just the ETH value. Would be nice to clarify which it actually is in the proposal?

I think that’s fair, we haven’t agreed on implementing redemptions yet, nor have we agreed to move any assets into separate gardens v2 pools.

It would be reasonable to expect either of those things to require a decision vote.

Since we haven’t had a decision vote on either, it seems reasonable to block this proposal until that is figured out no?

#10

Let’s just treat funding proposals for the redemptions contract the same way. No need to brick the entire treasury with Decision Votes even for small proposals.

#11

If we are not ready to do a decision vote yet, but we also want to have an interim solution that allows us to start allocating treasury funds right away, I think choosing the solution that is more conservative with regard to spending and the status quo is the more reasonable one.

While the mechanism I suggested would emulate to some degree how things would work if we were to implement redemptions, it would not allow honey holders to redeem without approval of the multisig, and it would not mean that we have to implement redemptions in the future at all. It would just allow us to use the existing funding proposal mechanism for allocating treasury resources. It also requires ~32% conviction for this proposals rather than ~4%, so its a significantly more conservative approach with regard to spending and the status quo than what you are suggesting.

We don’t have to decide on redemptions or having separate pools for every treasury asset or some other option yet to be discussed.

#12

^ this math is inaccurate. The Total Treasury Value is closer to $590k. Probably the number didn’t include GNO validators, the mainnet Safe, shared liquidity, and the Common Pool itself.

The calculation also considers the treasury value with the entire supply of Honey, but then only includes the Common Pool supply of Honey as the denominator in the CV threshold. If the point of that is to throttle the amount that can be requested at once, we already have the Spending Limit parameter for that.

But if for some reason we wanted to go with that double spending limit, then the threshold with the correct values would be:

Price of Honey = Total Treasury Value / Total Honey Supply = 590000 / 57398 = 10.28
Requested Tokens = Dollar Amount Requested / Price of Honey = 8482 / 10.28 = 825.1

Threshold to pass = 5.53%

Screenshot 2024-08-13 at 11.44.42 AM

But much simpler to me is to treat each Treasury token as its own Common Pool, each with the same CV parameters as 1Hive.

Probably best to let Celeste decide.

#13

I used the number that was used for “total treasury value” in the spreadsheet provided in the original proposal, Perhaps @Gossman123 can clarify exactly how he determined that number.

If the treasury is larger than what was used in that original calculation then yes obviously the required amount of honey requested and the threshold would be lower.

From a practical perspective, I think it would be reasonable to consider the council safe and its liquid assets (excluding Honey) at the treasury for the purposes of this calculation, since that is what would be used to exchange Honey, or be directly requesting from. Things like the gno validator, or movements of funds to a mainnet safe I think could be treated as external investments that are not currently a part of the treasury (but which will presumably will eventually be returned to the treasury at some point in the future).

The intention there is to as best as possible treat the treasury as a community resource for all Honey holders and inherit the properties of the common pool as closely as possible.

So using the total supply to determine the value of Honey makes sense, and is compatible with the idea of eventually decentralizing management of the treasury and linking the value to Honey to it using redemptions.

If there is a desire to alter the parameters of conviction voting and the spending limit, wether high or lower I think thats probably a separate conversation.

This seems significantly more complicated to me since it would require using signaling proposals and manually calculating the threshold as opposed to using funding proposals and having the contract and existing frontend do the math to determine the threshold.

#14

Separate CV pools for each token can be run on Gardens v2 entirely through the smart contracts.

Ultimately these are 2 different systems for manually calculating thresholds, simulating funding requests for tokens not in a Common Pool, and counting on the Council Safe to execute them.

Unless other people have new opinions, the Council Safe should just go with the Celeste outcome.