Request for Comment: Treasury Framework

Thanks team, this all seems eminently sensible. Couple of small Qs-

- is the intent to have a dashboard to capture how we are tracking against the allocations? Some are harder to track than others without referencing multiple data-sources e.g. "Assets should be limited to 5% of their respective circulating supplies."

- "In no event shall the treasury deploy into assets with maturity or lock-up greater than 1 year, with the exception of select strategic assets." - this seems a bit open to interpretation as "anything we hold more than 7.5% of is by definition strategic" ... unless the definition of strategic assets below were to be made more specific? Can we at least list those specific assets for now given our focus on governance is limited to just a few protocols?

Thanks again, yes from me.

thomasscovell

To question one, the goal would be to have an objective check against the policy that we get approved for such that it minimizes human error in said checks. If we put engineering efforts into a dashboard that will check that we are or aren't in acceptable windows of tolerance to our goals, it an be transparent and objectively checked by anybody. This is transparent and helps keep the Treasury Team accountable.

To question two, "Strategic Assets" actually have an OIP Qualification within the DAO vernacular. OIP-51 defined the first ones and OIP-110 added to the list. We would use future OIP's to qualify if more were needed or to deprecate those that are no longer important.

The spirit of that clause is to prevent any asset being locked up for longer than a year, even if it's marked strategic. In the past, we had FXS that was locked up for four years and the current treasury team feels a lockup of that length is never needed. A year is the maximum and most lock up periods will be several weeks as defined by the gauge votes.

Thanks for participating in the discussion!

I like money

Hello treasury team, I have a few questions:

How does the treasury team see the impact of the BLE on POL?

What is the thinking behind the 'Assets should be limited to 5% of their respective circulating supplies.'? Why was that number chosen?

Mark11

Hey Mark,

These are great questions. I'll take them in order:

Personally, I see BLE and POL as two discrete but largely unrelated things. For POL, we bear all IL Risk as we own both assets. For these reasons, we have to take a long, hard look at things like OHM/ETH IL since we have a stability mechanic and ETH does not. That creates increased risk if ETH sees a large correction and a gap opens in the pool.

For BLE, we hedge that risk with the counter party. They receive a Pro Rata share on exit and this allows some space for risk distribution both from the incentivized cost to operate and from the IL.

Like any new product, it's a test as well. We can go to market, evaluate traction, monitor behavior and if actuals meet or beat the thesis. It's a liquidity exercise that we can keep a close eye on to watch performance.

For clarification on the 5% of circulating supply, it's a conservative boundary to ensure we don't get into a liquidity crunch. Thinking of LUSD specifically, early Olympus found itself in a position where it was holding a little quarter the supply that starts to have real, tangible impact on the partner. 5% per assets circulating supply was collectively seen as conservative. Would totally be open to hear counter arguments where more or less can and should be considered.

Thanks for the engagement!

JaLa The treasury team recommends a 75%/25% between stable assets and volatile/ directional assets

After recent events I would like to see greater allocation for volatile/directional assets. I'm comfy with 50/50 in case there would be some framework defined where majority of that would be ETH/BTC.
We need to decrease our exposure to "down-only" assets which stablecoins proved they are. They're stable until they broke. In current situation where there's not truly decentralized stablecoin with enough liquidity for us (pointing at you LUSD) I'm willing to take rather greater volatility risk than de-pegging risk. This can be re-evaluated once some alternatives emerge (crvUSD or AAVE - ghost?).

I would echo @hodlmao above. 75%/25% stable/volatile is too conservative imo. Possible framework:

1. The community adopts the position that stables are kept solely for the purpose of supporting the lower cushion of RBS. If there are other use cases for stables the community likes these could be factored in.

2. Using historical data on the cost of IBs, we estimate how much it would cost to maintain the lower cushion for a year + some insane error term. For example; imagine IBs cost $2M for the past year (idk the actual number). Plus a 5,000% margin for error means we need $100M stables in the treasury. The different parameters can be modelled for the community to evaluate and vote on.

3. When reserve bonds are turned back on, they are only on for stable assets until we reach that threshold of $200M. After that its purely ETH, wBTC and whatever strategic assets we may want (CVX, BAL etc)

I like this framework because it links treasury management to RBS, its programmable but with room for DAO discretion, its data driven and it provides forward guidance for the market. It would make OHM backing more volatile. Worth it imo. I personally think no stable asset is gonna be big enough AND decentralized enough until OHM gets biig.

The question then is what stables to hold. There's not many suitable options out there but we do have room to increase LUSD exposure. What's the most of their mcap we can hold without being seen as a risk by the liquity team?

hodlmao

This was discussed today and will taken into consideration was we structure the OIP. Thanks for the comments!

We need to accelerate this pronto - need to get more ETH in the treasury asap!

+1 Next steps?

This is great, are there any updates on when the application will go live?

I thought this was a terrific writeup @yieldohmie wish more DAOs were this proactive and transparent as it makes it much easier for community contributors to bring forth useful solutions. Excited to share some specific solutions in a few weeks.