# Treasury management in Gardens

The Gardens arquitecture that 1hive uses is a simple and beautiful idea. It only involves one token (HNY), that is issued dynamically based on how much tokens are left in the common pool, and that is allocated to contributors through a voting mechanism (Conviction Voting) that uses is as a governance token. It is elegant.

Of course reality is more complex and if we want to generalize the idea of Gardens to other organizations, sometimes we have to add some changes to this original model. This is the case for example of the "bring your own token" gardens, like BrightId, or gardens that use more than one governance token, like Agave.

There are other cases in which the garden wants to have their treasury in a different currency other than their governance token. It is the case of Token Engineering Commons, which uses wxDAI as request token for example.

In the current version of Gardens, although, once we have specified a token to request in conviction voting, we can only change it uninstalling conviction voting and installing it again (a nasty process since a lot of things are attached to it, such as the agreements app, the token manager hooks, and a price feed oracle). So it is highly recomended that once we set up the conviction voting app, we do not change its tokens (we can change the other configuration parameters).

We already have discussed how [de-hookifying the garden tokens](https://forum.1hive.org/t/are-token-manager-hooks-useful-anymore/4288) could improve this situation by enabling (1) gardens governed by multiple tokens and (2) tokens that govern multiple gardens. Although the changes proposed in the previous post are huge, we probably won't need to wait for Gardens v2 for being able to change the governance tokens ([still work in progress](https://github.com/1Hive/voting-connectors/pull/2)).

However in this post I would like to discuss how to change the request token of a garden without having to reinstall Conviction Voting, and even being able to manage multiple tokens in the common pool.

## Treasury management apps

First, let's see how treasury management has been dealed by Aragon DAOs.

* **[Vault app](https://github.com/aragon/aragon-apps/tree/master/apps/vault):** First treasury manager in existence that allowed to deposit and transfer ERC20 tokens, a very simple contract.
* **[Agent app](https://github.com/aragon/aragon-apps/tree/master/apps/agent):** Agent is the king of treasury management in Aragon DAOs. It is basically a Vault on steroids: a place where a DAO can store their (fungible and non-fungible) tokens and can make interactions with any other contracts.
* **[Redemptions app](https://github.com/1Hive/redemptions-app):** Developed by 1hive for the Dandelion Template which resembles Moloch DAOs interactions, Redemptions allows tokenholders to redeem their tokens in exchange of a portion of the whitelisted tokens that are held by a Vault or an Agent.

The current gardens use the Agent app as their Common Pool.

## Funding proposals with multiple tokens, the dilema

Conviction Voting funding proposals request a specific amount of tokens, such as 25 HNY in the case of 1hive garden, or a specific value in stable coin for example 10,000 WXDAI ≈ 27 HNY (converted to HNY at the moment of the execution of the vote).

It is important for Conviction Voting to know how much funds a propoasal is requesting in relation to the total funds in the Common Pool. This is easy to do with the simple model of only one token (although it gets a bit more complicated when the proposals are requested in a stable amount, where a price feed oracle has to be involved in the calculation of this amount).

Things get way worse if we had to manage multiple request tokens, having to keep track of many valuations. If we try to avoid setting a price feed oracle for each one of the Common Pool tokens, we have to do some consessions.

We have to have a different threshold for each token, or treat all the tokens of the treasury as if they were all one. One price feed oracle for every possible token is a bit too much in my opinion (as they have to be constantly updated), so let's explore these other options.

### A diferent threshold for each token

Imagine we have 10 ETH (currently $30,000), 50 HNY ($18,000), and 100 WXDAI ($100) in the Common Pool. Solidity code does not have a clue of how much value carry each token type, so we are going to treat each one of them independently.

We install one Conviction Voting app for each token, so we can request ETH to the first one, HNY to the second one, and WXDAI to the third one. The honeypot UI is still not supporting this, but it could display all the proposals of the three Conviction Voting apps in the same feed.

The issue with this approach is that each token would have different degrees of difficulty to be requested: 10% of ETH ($3,000) would cost the same conviction as 10% of HNY ($180), and the same as 10% of WXDAI (to only obtain $10). I would not recommend anyone to request WXDAI in this DAO :sweat_smile:.

### Treat all treasury tokens as one token (wrapping them all as it)

The other way a gardens have to be exposed to many tokens and offer them as request token in their funding proposals is to wrap all of them on one token and use it as unit of account, unwrappig the proportional amount of tokens when the proposal is executed (a la Redemptions app).

In order to do this, we can create a new Raceme app that implements the Vault app interface and a non-transferable ERC-20 interface. It will be an app and a token at the same time. It will have the following characteristics:
- The `balanceOf(addr)` of the Raceme app is `1e18` (1 token with 18 decimals).
- The `balanceOf(addr)` of any other address is `0` as fuguratively all the Raceme tokens are within the Raceme.
- The `totalSupply()` is also `1e18`, so a portion of a token, let's say 0.5, represents the 50% of all the tokens in the Raceme
- We can use the `deposit(token, value)` and `transfer(token, to, value)` as in any other Vault / Agent to manage the funds. The main difference is that when using the transfer function with the Raceme address, it sends the unwrapped tokens.

So the interesting things of theoretical Raceme app are that:
* It implements the same interface of a Common Pool and a Request Token, so we can connect a Conviction Voting app to it.
* Conviction Voting can request for a specific percentage of the Common Pool (for example 2%, codified as 2e16).
* When the Conviction Vote is executed, a proportional amount of each token contained in the vault is going to be transferred to the beneficiary of the proposal.

This approach has it's drawbacks as well:
* Using Racime we can request for a percentage of the Common Pool, not for a specific amount of tokens. We only know how much tokens you are going to receive when the proposal is executed. This is because we can not aggregate the value of all tokens within the token balance of the Racime app, and we have to use a constant value that represents the 100% of the Common Pool.
* It can only be used along with apps that work well with tokens that represent percentages, such as Conviction Voting. It could not work with a bonding curve, for example, as the bonding curve is expecting that the balance increses or decreases after depositing or withdrawing funds from the app.

## Conclusion

The road to have a good treasury management in gardens is full of curves. The main problem is the difficulty of knowing the value of each of the assets hold into the treasury. We can workarround this challange with the two solutions presented in this article, but they have their own drawbacks as well.

Probably we could implement one of them as mid-term solution as we explore how to include advances in the space such as [yearn vaults](https://www.youtube.com/watch?v=9vTaNl2_B8A) ([see also this](https://www.youtube.com/watch?v=a1TsO62402c)) and [balancer vaults](https://www.youtube.com/watch?v=ABbtYtMDhFA). They are such interesting topics but at the same time quite challanging.

I wonder if as a community we can come up with simple solutions to apply to this interesting problem, how can we manage and distribute many tokens instead of just the gardens governance token?