Episode 70: January 23, 2019
00:00: Intro with Rich Brown
3:14: Recap of Forum Topics with LongForWisdom
26:10: Migration Risk with Primoz
42:17: State of the Pegs with Vishesh
52:34: Open Discussion about
SCD: The Single-Collateral Dai system
MCD: The Multi-Collateral Dai system
CR: Collateralization Ratio
DC: Debt Ceiling
ES: Emergency Shutdown
EV: Executive Vote
GP: Governance Poll
SF: Stability Fee
SLP: Secondary Lending Platform
DSR: Dai Savings Rate
CDP: SCD CDP
Vault: MCD CDP
Introduction & Governance
Summary & Introduction
Welcome to the Jan 23rd Governance and Risk call. We are going to talk mostly about Risk in this call. Last week we had a great call discussing much of our governance-related issues. Both governance and risk management are complex worlds that will require more depth of attention.
We’ve set up communication channels like this call, the forums, and Rocketchat. Numerous community members like Sam and LongForWisdom have stepped up to work within the framework of these channels to build out processes, guidelines, and signaling methodologies. The community has also worked within these channels to determine how we manage the levers/policy tools available to us. A perfect example of that is Sam’s efforts to create a DSR spread vote. There’s a fantastic amount of activity happening in the forum lately. This governance call will eventually be more targeted towards addressing the various issues and proposals that show up in the forums.
There’s a lot of work ahead of us, getting these ideas into initiatives/plans/proposals and then to on-chain votes. We need to figure out how to alternate between risk-centric issues and governance-centric issues. Our goal is making sure our governance becomes efficient.
Give us feedback about the call.
DISCUSSIONS HAPPEN IN THE FORUM
Forum Activity Recap
Questions and Discussion
- David: One thing I like about recent forum behavior is that the owners of Signal request threads create new threads that summarize the discussion and views to-date. For example, Derek’s thread where he summarized the SCD GS conversation. That thread summarized all the relevant points from the previous posts and combined his own positional knowledge to help move the issue forward. This behavior makes it easier for people to jump into issues mid-way through.
Rich: (goes back to the discussion on reputational systems in MakerDAO) There are things I’m concerned about to though. On the other hand, many people don’t care about reputation/online-web-points/etc., and they won’t wait for this to work. It’s exciting, but another thing to consider is pre-filtering and incentivization within reputation. Do we want to incentivize people that are driven by the gamification of status? Is that a quality that good Governance requires. We don’t have an identity on the blockchain until then; we have status as a stopgap solution.
T: ETHtrader on Reddit has Donut(s). Merely a good case study to think about making reputation fun, they eventually put a token on Ethereum and made it tradeable on Uniswap.
C: I apologize for creating that meme. I had nothing to do with the tokenization.
R: Donuts are also an excellent example of how a reward system based on contributions can be fun until it ruins you.
chat: “Gasless voting?”:
Rich: Gasless voting ties into both incentives and reducing friction. We have developers here who can talk about that friction. If I recall, leveraging relayers was a possible solution to subsidize gas costs, but not sure where we are with that conversation. Is that a significant friction, though?
LFW: You can vote with 1
GWEI which is less than a penny. It’s very inexpensive to vote.
SamM: For me, the friction is not so much the cost, but rather the waiting. I mentioned the load time for governance poll voter breakdowns and the need to load multiple pages and synchronously wait for them to load. Waiting to vote, waiting on the blockchain, etc. Any way to make that quicker?
Rich: That’s likely a UX pain to evaluate. I suffer through this often. I heard from Chris Bradbury that there are initiatives afoot to set up a caching layer, but I’m unsure of the progress.
Derek: We’ve got it on the backlog. We need to see what else we need to prioritize in that space. There are a few UI/UX components, but that may include a redesign of the Governance app. There are several ideas we need to pull together into a roadmap. Happy to share with everyone when it’s fleshed out.
Rich: If the DSR-spread GP idea works, what are its implications? The idea was that now we potentially don’t have to poll for it every week. How often should we vote on the spread? Sam, you have some thoughts on that?
Sam: I think it should run weekly for now. I figured there would be a large consensus (99%) that people would want the DSR to follow the SF. If that sentiment keeps up, then we can reduce the frequency.
Cyrus: Add 0% to the poll next week?
R: My mistake, I didn’t add that, but yes, next week! Thanks for the reminder.
- Sai stability fee when up to 9% last week. This week, the MCD ETH stability fee is being voted up to 8%. DSR will be 7.75% if Friday’s EV passes.
Saw a high migration flow last week. We also crossed the 100 million Dai mark. About 8 million Sai migrated. Dai supply increased for about 12 million, which means an additional 4 million Dai was minted in a week.
Also saw Sai in the migration contract start to accumulate, at one point there was about 6 million Sai deposited, after which the 2nd largest SCD CDP used this Sai to migrate.
- From last week’s call, this was the one CDP doing the most minting. I originally thought that this would be the last CDP to migrate, but this theory was destroyed. This CDP has changed its mind, likely either due to worries about
tax implementation or limitations of Sai liquidity.
This week I prepared some stats that are not directly related to migration, though I think they are useful for MakerDAO governance.
- Not much has changed since last week’s analysis.
MCD system stats
SCD system stats
DAI & Sai 24hr VWAP Graphs
24hr trading activity:
Dai 24 hour volume-weighted average traded very slightly below peg for a short time. Despite discussions regarding increasing SF’s on Rocketchat and Twitter, we should understand that these are very small deviations. It’s unclear if it’s deviated enough to warrant any action.
Middling amount of trading volume in the last 24 hours, around 2 million.
- Sai trading volume is very low, around 240k. Shockingly, the volume-weighted average price is pretty close to peg despite the drying up of liquidity.
- Interesting point, Dai and Sai are closer in trading activity in terms of liquidity on Uniswap than globally.
MKR trading activity and liquidity is an important topic and will become more relevant when we start discussing risks in the event of auctions and the various appetites for printing MKR and selling it off, and what price impacts be vs. MKR burn, projected revenues, and stuff like that.
- Interesting topic area to keep in mind for the future.
- On a longer time scale, Dai trading activity has been pretty solid at 25 million.
The top graph is the amount of ETH locked as collateral in MCD vaults.
The bottom graph is the amount of ETH Dai issued from MCD.
They both correlate closely but can be interesting to view together to track spikes and drops in collateral movements. This is helpful to understand how the amount of collateral and debt fluctuate over time.
Questions to Vishesh
Discussion and Questions
Cyrus: Thanks, Vishesh! Anyone have thoughts on Sai liquidity as it relates to ES? Since, as per Primoz and Vishesh, Sai liquidity has been dropping. Is there a point where it becomes impossible to migrate?
Primoz: It’s always going to be possible; it’s just a matter of price. Market makers might mint Sai and sell at a premium. If Sai SF is going to be 9%, perhaps they will charge an extra percent to help that migration to Dai.
C: What’s a reasonable price then? SF going up limits the options in terms of liquidity.
Vishesh: A better question is: “what’s your goal?” If the goal is protecting users from a price impact on migration, then I don’t think forcing shutdown helps. Eliminating the overhead and management of the system is the only goal I can think of, In terms of forcing a shutdown. The asset is, more or less, leveling out to some bottom.
C: There was always an implicit context that Governance would protect users from those large price impacts. E.G., if the price jumps to $1.05, then an emergency GS might be called. In that context, Governance would do what they could to prevent that, but if you change perspective to minimizing overhead, then what happens if the peg does deviate?
P: I think we need to focus on when ETH is crashing, that’s when CDPs want to de-leverage, and people want to buy Sai. Now with Sai liquidity mostly drained, the spike will be higher, and we might see Sai above $1.
C: In November, we saw $1.03 or $1.04. It could easily be much higher now.
LFW: We should have a signal poll for a liquidity-based shutdown. Rather than based on peg deviation since ideally, we would shut down before the peg deviates.
V: That’s kind of my point. Since we’re so low in liquidity now, we’re setting people up for a price motivated danger.
L: So, you’re saying that if we should shut down on low liquidity, now would be the time?
V: I don’t think an additional 10% drop in liquidity is likely in the next few weeks. Nor will it make a big impact on price in the event of an ETH run-up or crash.
R: Let’s say I’m a large holder, with $50K in fees, and ES is looming. Is tax designed to reach parity with what my fees would have been? What happens if someone has 10k in fees or less? Are they taxed proportionally? Or is this parameter like a big stick, do I imagine that correctly?
N: It is a VERY big stick. If you make sure that the tax is equivalent to SF’s, then it lacks the incentive to pay SF’s, which would then lack the supply crunch to close positions, where pricing would be over a $1 to close positions.
tax effective, you have to hammer it down, making it more expensive than SFs.
Besides, the period
tax is running after implementation is short. The
tax_period doesn’t have to be a month; it can be a few days. We could discuss that timing more.
You mentioned fairness, which gets tricky. CDPs were opened at different points in time. When you apply
tax that won’t be taken into account. My thought is the
tax parameter should be set by profiling all the largest CDP’s. How long they’ve been open, how many unpaid fees they’ve accrued, then set
tax based on a profile that most of them fit.
N: One more thing.
Tax paid goes to PETH holders, not MKR holders. Ironically, the largest PETH holders are the largest CDP owners. There is an amount you get back when you pay tax. When thinking about what we want the tax to accumulate to, we have to think about that reimbursement too.
R: This parameter implements with the understanding that MKR holders need compensation for their risks managing the system. But that’s not the case; it’s SCD, so it’s the PETH holders.
C: Does it benefit MKR holders directly/indirectly?
N: No, as an MKR holder, your incentive is to pressure people to pay back before
tax parameter implements. We have to toe this line between using a large stick and wielding its responsibility.
L: You mention the communication issue, I kind of agree. If anyone gets hit by a tax, we want anyone to close their CDP beforehand, that makes sense. Will we reach 100% of CDP holders without an outpouring of blog posts? If we can’t hit 100% of people, then we shouldn’t apply a non-proportional tax, in my opinion.
R: Primoz points out that a lot of these CDP owners are likely inactive for a very long time.
Links from the Chat
Tim Black produced this summary
David Utrobin produced this summary
Igor Teslya produced this summary.
Everyone who spoke and presented on the call (listed in the headers)