# Que Gardens? ## Todo - Check if TEC/current Gardens Swarm is building a UI for the Marketplace that we can use for converting existing tokens to MiniMe governance tokens. Probably not if we'd rather use a widget/embed the functionality into the main site. - Investigate blacklist registry added to/removed from using Celeste or Honey votes. - Investigate Garden creator wizard and what steps will be involved. ## Using an existing token If using an existing token the template will include the marketplace app to convert the existing token 1 to 1 with the orgs MiniMeToken. If the extra marketplace functionality isn't used, in future this contract could be re-written to be significantly more light weight. Creating the governance token could incur a fee in the original token which would be deposited into the common pool, available for distribution. The original token could also be deposited manually by other token holders or some external inflation process. No inclusion of Dynamic Issuance in this case. ## Creating a new token If creating a new token then the initial distribution can be determined by the creating community. Some could be set aside as bounties and rewards or airdropped, the rest would be earned through the Garden's conviction voting app. 1Hive could vote to add irremovable liquidity using Honey and the new token to bootstrap the new Garden's economy. Since there is some risk here as the locked Honey would be available to the new Garden's distribution receivers, the community would need to be trusted to some extent. The Issuance paramaters for the Garden would need to be checked to ensure they're reasonable. And restrictions could be applied such as the liquidity contributed by the new token has to be atleast a specific percent of the initial supply. Alternatively we could require a new Garden to deposit Honey when creating their Garden which is matched with some amount of the new token in a liquidity pool. **If we do require it, then what parameters (amount of honey and percent of new token) seem reasonable? If it is a small requirement presumably that doesn't incentivise the use of Honey much, but if they are large it likely would.** Dynamic Issuance would be installed in these Gardens to inflate the supply when below a specific amount and deflate when above. Even if these communities don't have many inflows creating deflation, the dynamic inflation will still be useful providing the Garden's token increases in value. ## General Apps included - Disputable Voting, for config updates. - Disputable Conviction Voting, for distributing the orgs token. - Agent as the common pool vault to allow the Garden to use funds flexibly. Should add the common pool token to the `safeExecute()` blacklist. Note it can still use the common pool token using the standard `execute()` function. ## Individual Gardens UI Has to take into account Gardens with and without an Issuance app (easy enough), and with and without a marketplace app, for Gardens created with a token and using byot (bring your own token). Ideally we will integrate a marketplace app widget for Garden's using byot. ## Aggregate Gardens UI Users will be able to login with their address and select which Gardens they are indluded in their feed **through their profile or a separate tab?** The feed will have the same filters and sorting as the current 1hive.org feed but extended with options to filter by Garden. The full list of Garden's available for selecting from will be ordered by total liquidity available in their common pool's token Honey pair. ## How to blocklist DAO from UI We could use an on chain registry which is added to during Gardens deployment and removed from if a DAO is not adhering to the covenant. Alternatively, since deploying a DAO emits an event with an address of the DAO we could allow all DAO's by default and make a blocklist contract that is added to if a DAO is not in line with the covenant. **How would the blocklist be decided? Using Honey votes? Using Celeste with a Disputable App or Govern?** The 1Hive UI's will use this to determine whether DAO's should be viewable. Luke mentioned using APM, can this be expanded on?
Last changed by  
 
William Griffiths
890

Read more

Vesting proposal

Users can opt to take their basic pay directly from their swarm immediately. Alternatively they can deposit their base pay into a vesting contract and create create a vesting where they specify a timeframe for vesting which determines a multiplier of the amount they are paid. Timeframes, multipliers and cliff time (if any) to be discussed. The vesting pool will need to have access to individual swarms funds so when a vesting request is made, the base un-multiplied value is taken from the swarm's funds available for distribution via the vesting contract. Alternatively the funds need to be approved to be taken by the vesting contract before creating a vesting. The extra funds paid above the base rate will be taken from the common pool by the vesting contract. Creating a vesting must be permissioned and only callable by addresses that received funds from the common pool, so swarms must use a vault/safe that can call external functions eg Aragon Agent or the Gnosis Safe. To create these transactions is easy with Gnosis Safe using the transaction builder, it's more complicated if using the Aragon Agent. Each successful vesting request creates a superfluid emission for the amount determined by the timeframe/multiplier chosen. Superfluid allows you to define a payment amount and a period of time over which you want to pay it. This should be visible on the standard Superfluid UI. Unfortuantely for now we can't create superfluid streams with a start date in the future so we couldn't emulate a cliff, but it sounds like something they're open to adding so at some point we could include a cliff.

1/13/2022
Aligning on 1Hive direction

Pre-requisite reading: https://forum.1hive.org/t/aligning-on-narrative-and-high-level-direction/4322 It's been a while since Luke made the above call to the community to try and establish a shared vision for 1Hive going forward. There wasn't a great deal of response to his call and since then the value of Honey has continued to diminish and contributors have continued to leave or become inactive. Considering this and the increasing fragmentation of 1Hive into many unrelated projects and self-governed swarms, some change is necessary if 1Hive is not only interested in surviving but also thriving. Refocussing on organisational apps From the beginning 1Hive was always about building and experimenting with inclusive organisational infrastructure. The core of this infrastructure is now represented as Gardens and Celeste. These are the necessary components for continuing this grand experiment. Without them 1Hive has very little future. There are many swarms within 1Hive that support these applications and there are many that, although promising and useful in their own ways, do not. Considering the limited resources we currently have available I think it's paramount that as a community we refocus our attention on these core applications until we're in a more sustainable position. A sustainable position is one where Honey is a desirable asset and the best chance we have at making that the case is by popularising whatever requires Honey to use. Celeste requires dispute creators to pay for those disputes in Honey and users of Gardens (which cost Honey to deploy) are incentivised to stake to Celeste to potentially have a say in disputes that arrise. Ultimately Celeste is the most likely to create the biggest demand for Honey, since users of any applications that rely on it are incentivised to want to be involved in potential disputes which requires they stake Honey to it. Current efforts to make Celeste more widely used include Gardens (including a Garden involving Maroon5's NFT's), Quests, and a developing collaboration with Gitcoin. We have also explored integrating with Gnosis Omen and building a function naming registry in the past. Beyond this it has been suggested we liase with other DAO's or crowdsale platforms to see how we can integrate Celeste into their processes. If we can establish applications that rely on Celeste and are used regularly we will create a sustainable demand for Honey.

12/21/2021
Celeste integration for the Gitcoin proposal process

Is the current proposal created on chain anywhere, eg Ethereum or Polygon? I see a deposit is required to the Polygon multisig in order to initiate an appeal of a proposal and presume this is the only interaction with a chain for an appeal. Seen here: https://discovery-1.gitbook.io/gitcoin-knowledge-base/-MjC5KnuB6HdGrn7Kh8T/gitcoin-policy/policy/appeals/appeal-process-stage-1 What details are necessary to decide whether or not a proposal should be approved? These will need to be uploaded and pinned to IPFS so they can be referenced by Celeste, either via a custom UI or the Gitcoin DAO UI. Eg Proposal details (is there a web link to this on Gitcoin? Or do we have to upload it separately to ipfs and create a link?) Proposal requirements eg https://support.gitcoin.co/kb/article/79-why-isn-t-my-grant-active/ Arguments for and against from proposal creator and assesors as evidence in Celeste Should there be a deposit from the appealer to create an appeal on Celeste which is forfeit if they lose? How much and what currency?

12/10/2021
xDai to Mainnet/Arbitrum migration (wip)

Honey is currently native to xDai and the bottlekneck for security of Honey is the xDai bridge validators. Since xDai is dragging it's heels it seems wise to construct an exit strategy as L2 solutions become available. Arbitrum seems to be the most promising solution, atleast in the short term. Arbitrum also allows for arbitrary L1/L2 bridging transactions out of the box. Note Arbitrum L2 -> L1 transactions will currently take one week (plus batch submission delay, 8 hours on Rinkeby) due to the need to wait for the chains dispute period to pass. L1 -> L2 transactions seem to take ~5 minutes on Rinkeby, presumably some batch submission period. I expect mainnet to be similar. Using this bridging feature the initial plan for migration to an L2 is to migrate the Honey token to the Ethereum mainnet and issuance, voting, conviction voting, celeste etc to Arbitrum. With HoneyV2 on L1 if in future we decide Arbitrum isn't the right home for 1Hive's governance infrastructure, we can vote to move the ability to mint/burn HoneyV2 to a different L2 without having to migrate to a new token. HoneyV2 Since there will be no governance actions on Ethereum/L1, HoneyV2 could be a standard ERC20 with the permit pattern eg Aragon's Govern Token instead of a MiniMeToken which is quite inefficient and only necessary for doing on chain governance decisions using Aragon infrastructure. The bridged HoneyV2 on Arbitrum/L2 will be a MiniMeToken, the total supply of which must mirror the total supply of HoneyV2 on Ethereum so it can be used within the 1Hive protocol to enable issuance and voting as it currently is. This means that instead of minting and burning new HoneyV2 during bridging, some of the total supply of the Arbitrum HoneyV2 will be granted and locked.

9/21/2021
Read more from William Griffiths
Published on HackMD