CIP-57: Treasury Management Authority

Simple Summary

This proposal aims to give Treasury Management Authority of the Main Treasury Gnosis Safe [0x60e7343205C9C88788a22C40030d35f9370d302D] to the Finance Guild and specifically a Treasury Team within the guidelines presented here.

Abstract

Finance Guild: Oversight, selection of Initial Treasury Team, input on budgeting and taxes.

Treasury Team: Develop strategies and recommendations to signers for managing Treasury Funds for the purpose of ensuring the long term financial viability of CityDAO. If a member of the Treasury Team is also a signer, they may initiate a transaction in relation to the treasury Management Plan.

Main Treasury Signers: Required to execute transactions recommended by the Treasury Team. Signers may deny execution of an action requested by the Treasury Team only if the requested transaction falls outside of the guidelines proposed in this CIP.

Guidelines:

Allowed Actions:

  • Exchanges/Swaps involving the following tokens:
    • ETH
    • WETH
    • USDC
    • USDT
    • DAI
  • Deposits into yield protocols
  • Transfer of funds in relation to legal or tax obligations

Not Allowed unless approved by separate DAO proposal:

  • Transfer of any funds to an externally owned address that is not an exchange, yield generating protocol, or related to legal or tax obligations.
  • Selling or buying of NFTs
  • Activity that could be considered day trading

Motivation

CityDAO must ensure treasury funds are utilized to fund day to day operations, pay taxes, reduce portfolio risk, and secure the financial longevity of CityDAO. Treasury Management is a topic that requires expertise, timing, and follow through. Although community wide CIPā€™s and voting provide transparency and community input, too much discussion creates noise and the duration of the voting process encumbers the ability to manage the treasury in a timely manner with the appropriate context.

29 Likes

If we have a Treasury Team, is there a reason that we would still need a group of multisig signers who also have access to the treasury? How would this work in terms of having one multisig for the treasury, but two disparate groups who have the authority to sign transactions? Or would the Treasury Team supplant the current multisig signers?

The Treasury Team doesnā€™t need the power to actually sign and execute transactions. They could just provide recommendations. For example, a large part of a potential strategy is selling eth for stablecoins to de-risk our treasury and ensure we have funds if thereā€™s a market draw down.

A recommendation would be to sell ā€˜xā€™ eth on this date and the current multisig signers can initiate and execute. It could be helpful to have a signer from the Team to queue up txns since theyā€™d be familiar with the context and logistics of a trade and be part of the job. It should always be the job of signers to question and have context for transactions, and this would be no different.

What I think is good about these limiting guidelines is that it should be easy to spot anything that falls outside of the scope. This grants the team very limited things they can suggest, some of which we have legal obligations to perform. For instance, we shouldnā€™t have to put up a vote to transfer funds for quarterly tax payments as itā€™s something that just needs to happen.

I didnt get it, the prososal says ā€œThis proposal aims to give Treasury Management Authority and the power to execute transactionsā€ and then after Da3vid question you answered ā€œThe Treasury Team doesnā€™t need the power to actually sign and execute transactions. They could just provide recommendations.ā€

Iā€™m confused. Could you re explain maybe ?

I definitely support depositing into yield protocols to make our treasury sustainable. If this proposal would allow that to happen then Iā€™m 100% in for it.

In terms of day to day operations, how does this affect our current guild structure?

1 Like

Feedback 1: Multi-sig generation process
I suppose you might have this in mind already. Just to share you the situation from one of the gamefi project that I currently get rug. They just have the transparency issues in the dev fund utilization so the community request to impose addition control.

  • Dev generate multi-signature (2 signatures) and send one of them to the 2nd person (CEO).
  • Fund moved to multi-sig contract
  • However, dev can still withdrawal fund without CEO permission
  • The CEO and community are really confuse + angry
  • After that, we find out that the dev know both signature since the beginning
  • Dev end up holding two signature and the CEO only have 1 part of it. That sound really funny but the community is on fire now.

Feedback 2: Multi-sig criteria
The multi-sig is very fine. However, the criteria for allowed / not allowed actions should not associate with the multi-sign. It should be broken down and associated with each treasury asset type in the treasury.

  • From CIP-39, my understanding is that there are some risk management measure to prevent asset value volatility. (These are huge portion, low movement, high lot size)
  • In the other hand, our treasury is the source of fund for guild operation. (more frequent but smaller lot size)

Those are different type which require different treasury policy and operational process. So, this should require different risk measure and it can lead to different allowed / not allowed action defined above.

Feedback 3: Segregation of Duty & Delegation of Authority
To prevent conflict of interest, there should be Chinese wall implemented between the person who responsible in treasury and finance book keeping (i.e. front / back office). In our case, just ensure they are not the same person or they are not sharing the same interest. Both party of the Chinese wall should hold one of the multi-sig if necessary.

If there are some bottle-neck in fund utilization, we can implement delegation of authority to sub-wallet without multi-sig which the outstanding is limit (i.e. < 2000 USD) and the guild leader can request to withdrawal with limited amount (i.e. bounty < 200 USD). If it above the threshold, that it should be requested from main multi-sig related process.

2 Likes

Updated the Simple Summary and Abstract and removed the word execute. The idea is that the Treasury Management Team would develop a plan, which includes trades (almost always would be eth to stablecoin) and deposits into yield generating protocols. The existing signers would execute upon the requests of this plan.

Treasury sustainability is the ultimate goal. There would be no day to day effects on the current guild structure since this is designed to be a subset of the tasks for Finance Guild to tackle. This is actually necessary for guilds to continue operating since guilds are currently funded with USDC, we need to adequately plan to move ETH to USDC to fund ongoing operations.

Thanks for commenting.

Feedback 1: We currently donā€™t have a single point of failure and donā€™t think this applies to our situation.

Feedback 2: CIP-39 is a good example of why this proposal would be more efficient and in the best interest of the DAO. The strategies in CIP-39 are essentially the strategies that would be implemented under this plan. The goal is to not go through a governance process every time for treasury actions that are essential for our day to day operations. Having an overall picture of how our assets work together is important.

Feedback 3: We now have guild wallets (sub-wallets) that prevent bottle-necks in fund utilization.

Definitely agree on preventing conflicts of interest. In the original post I suggest that signers of the multi-sig are responsible for scrutinizing each transaction the Treasury Team requests so that no harm can be done. The allowed actions are very narrow so that power is restricted. The multi-sig is comprised of people from multiple guilds as well.

2 Likes

I like this beginning. Think it is directionally correct but will require future additions around definition of the Treasury Team and the process of making recommendations. Good framework to start with though, nice work Alex.

Also, as discussed, we should add BTC to the allow-list. We can do work to figure if it is technically feasible as well as research to the risks of wBTC.

2 Likes

Thinking more about this, Iā€™m not sure it makes sense to include BTC since we donā€™t have an address to point the authority towards.

Iā€™d still be concerned wBTC poses too much risk and the yield isnā€™t there to justify it for being an interest bearing asset.

This has been a good read through, Iā€™m mostly on board at the moment

One thing slightly missing for me in the Simple Summary section is a very short/brief summary of what the real problems exist with the current structure, why they are really important to have resolved, and how CIP-57 resolves them

I see thereā€™s the voting subject for taxes etc thatā€™s a challenge and should just be paid not voted on, but what else?

1 Like

Great proposal.
Only concern I have (and itā€™s not blocking my vote which Iā€™m casting); is that Iā€™d appreciate either movement limits or ratio stables/tokens or similar guidance to put just a little more of a bounding box on the authority here @alexthims ā€“ but safe enough to start with for now given itā€™s a multi-sig w/ good threshold and diversity of signers to contest if something looks really strange or overly aggressive/risky.

1 Like

@MemeBrains I think weā€™d keep most spending within guilds as possible. There could be unforeseen things related to compliance or legal issues, filings, etc that pop up that need to be handled. Certainly any situations that are in this category will be promptly shared.

@bpetes We did discuss this briefly, but didnā€™t want to get the limits or ratios wrong to start. We might add some self-limits along the way, I think theyā€™re great suggestions. There most certainly should be limits for yield deposits, which is part of risk management.

We are working on that @MemeBrains with a form for CIPs. Just to help standardize & categorize the information a little.