Treasury management in Gardens

đŸ”„Swarms
#1

The Gardens architecture 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 recommended 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 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).

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: First treasury manager in existence that allowed to deposit and transfer ERC20 tokens, a very simple contract.
  • Agent app: 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: 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 proposal 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 concessions.

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, unwrapping the proportional amount of tokens when the proposal is executed (a la Redempcions 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 figuratively 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 increases 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 workaround this challenge 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 (see also this) and balancer vaults. They are such interesting topics but at the same time quite challenging.

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?

9 Likes
Commons Swarm: How are we doing?
Gardens Swarm Funding Proposal #4 đŸŒ»
#2

Adding some thoughts here based on the Discord discussion today.

@sem you added this in Discord, expanding to 4 options for multi-token treasury management:

  • Ignore them [non-governance tokens in conviction voting]. This is what we would be doing now. They could only be retrieved using tao / disputable voting
  • Use different instances of conviction voting to request them. This has the problem of the different threshold.
  • Wrap all the tokens in one and request it using one instance of conviction voting. This you could ask for portions of the Common Pool, which solves the problem but may cause a bad UX.
  • Use oracles to retrieve the value of the tokens in the common pool and set a global threshold in accordance.

This last option is unexplored in the forum post because it’s more complex, but we are already using price feed oracles to determine the conviction required for stable amount proposals, so it would not be that difficult to implement to extend that. Looks like an interesting direction to look.

In my opinion #1 and #4 are the only ones worth exploring because they don’t add complexity to the already-complex Conviction Voting system. We’re having trouble as-is with people understanding how CV works


For #1 to work it would help if the disputable voting was integrated into conviction voting proposals to make those events seamless for non-HNY funding, but I have no idea if that’s possible or how hard it’d be. This outcome where only HNY counts towards conviction needed to pass I actually think is a beautiful way of keeping HNY the dominant token in a multi-token common pool setup.

#4 I’m guessing the solution everyone’s imagining when they first think of a multi-token common pool within conviction voting. I like it for this reason, but there’s a reasonable debate about whether you gain anything from this approach vs. #1.