00:00: Intro with Rich Brown
1:58: Governance at a Glance with LongForWisdom
13:48: Oracles: The MIP10 Backlog with Niklas Kunkel
21:30: MIPs Update with Charles St Louis
24:55: Inclusion Polls Review with LongForWisdom
39:52: Smart Contracts and TUSD with Mariano Conti
1:00:19: State of the Pegs with Vishesh Choudry
Welcome to the May 14th edition of the Scientific Governance and Risk meeting, my name is Richard Brown. I am the Head of Community Development and the Interim Governance Facilitator. I am joined by LongForWisdom, who is the real governance facilitator as mandated by the community. Very exciting stuff.
Today's call is packed. We will hear from a series of mandated actors from the ecosystem, which is another evolution of how we do things here. As a specific group of activities becomes identified, they need to be managed, people need to do work on them, and there needs to be coordination. The way that that happens is a domain or a group of actors is assembled; they come up with a mandate and are voted in by MKR holders to assume responsibilities, as evidenced by my existence.
Today we'll be hearing by the Oracles Team, we'll be hearing from the MIPs Editor, we'll be hearing from the Smart Contracts Team, and we'll be hearing from Risk. So lots and lots to go over.
Discussions happen in the Forum.
Thread about why MKR Holders don't vote has resurfaced, prompting some useful posts from a number of community members.
Further discussion below
@charlesstlouis shares some details of possible improvements to the liquidation system being pursued by the smart contracts team.
@hongbiao_li argues that the WBTC debt ceiling should be increased, leading to several arguments for and against.
@NikKunkel of the Oracles Team opens a signal request to use the weekly cycle to process oracle proposals until MIP10 can be modified temporarily.
Friction points for voting
Rich Brown: What are some of the most common complaints or friction points for people voting?
LongForWisdom: So, the initial post in that thread is a summary of everything. Elliot, a user, shared some core reasons for why he votes. He mentioned that the main reason he votes is that he likes MakerDAO and wants to support it, and that took precedence over the fact that he owns MKR and wants it to gain value. I think it's interesting because it shows that for some people, I mean, obviously, quite a lot of people vote. After all, they want to see the protocol succeed, in a more general sense rather than individually in a narrow sense to make money, which is cool. And then he listed a couple of reasons why he tends not to vote:
The general stuff about outcomes determined by larger holders.
Votes being challenging to understand if you're not looped in.
Being worried that voting without an understanding of the issues will hurt and not help.
The direct benefits of voting are minimal, outweighed by fees, and the time it takes to research.
It's easy to forget.
It's challenging to consider the long term and make rational judgments as to long term indirect benefits.
Rich Brown: It's interesting. I wonder if people aren't being overly frantic. I think that is one of the major friction points, just that it's a huge pain.
LongForWisdom: Yes. That was on several people's lists.
Rich: Yes. If I had to make a list, it would be:
The fundamental tragedy of the commons: Why not just wait for the whales?
Rich: It's a tough one. So if anyone has any solutions about how we can combat that fundamental logical fallacy embedded in human nature since the beginning of time [jokes], please let us know! It seems that the running solutions are:
Delegation. Sometimes, it's framed as a way of weighing against the whales, but it could also mean just giving your vote directly to the whales. I'm not sure how that's a solution, but there you go.
Paying people to vote. As far as I'm aware, that's never been pulled off successfully.
Rich: Interesting problems. Let's come up with a magic algorithm to fix everything; maybe a bonding curve will fix it [laughs jokingly].
Rich Brown: For the people that are joining for the first time or haven't been paying much attention, SourceCred is running an experiment in the forums. If you engage in the forums and do things that are useful according to the algorithm and the community, you get money back. If you're interested, look the for the forum post, read through it, sign up and contribute.
MakerMan's Vault Compensation Review
Rich Brown: There is a long history and complicated situation around the vault compensation strategy. There's also a class-action lawsuit outstanding, so what I can say about this situation is fantastically limited. I will say that this is a community-led effort; the community has identified and organized around an issue that they would like to address. The community is working together to come up with a solution on how to address those.
There are challenges associated with that because the community needs to self-organize and then plug itself into the hooks that have been exposed by the protocol, some of the cultural norms, and all kinds of other things like that. But primarily, this is probably the first exercise of the community coming together to create a project, establishing scope and requirements, documenting them, finding stakeholders, coming up with a project plan, getting people to do work, and figuring out how to compensate them. From my outside-looking-in perspective, the compensation group has been having some challenges around the completion of that project. I think they've been having some resources issues. An issue that touches a lot of people in the ecosystem; if you have skills when it comes to project management, or scoping or doing specialized work, and you have skin in this game or a horse in the race, reach out to the group and offer your help. There is a lot of work to be done, and if you can help out, please feel free to join that group. For it to move forward, it needs to be an effective project. Right now, it looks like two people are doing the majority of the work, causing friction in the ecosystem. So if you can help improve that process, please reach out.
Working group member forum handles: @Joshua_Pritikin @LongForWisdom @MakerMan @monet-supply @Vault2288 @befitsandpiper
We've built quite a backlog of oracle proposals, so that would be MIP10. We have been looking at the contents of MIP10 and, this is slightly my fault since I've designed it separately from the other MIPs, it came to light that it doesn't conform to the monthly governance cycles that other MIPs follow. We are going to refactor MIP10 to be a more standard MIP and behave like the other MIPs, but we have to do something in the interim for all the proposals that we have built-in our backlog.
A bunch of whitelisting proposals from DeFi Saver. These are important because they are automation services, which basically will save CDPs/Vaults before they get liquidated. They're dependent on having access to our oracles for doing this in a trustless manner. If we think about a Black Thursday scenario, we want to support services like automation, so it's vital that we process this type of proposal sooner rather than later.
There's another team trying to get access to the ETH-USD oracle, they're trying to launch soon, and their launch depends on being able to access the oracle.
Live feed proposals
Adding new light feeds will continue to increase the security of the oracle, which I think is essential as the system scales. So currently running the live feeds we have:
I think we should prioritize adding new projects, credible partners in the space for two reasons:
It will generate more of a community around the Maker protocol
It's a protocol for the community by the community.
Instead of referencing some hedge fund, or professional price services, if you see EtherScan, or GitCoin, or Infura, or Kyber, users are going to trust your protocol more. The sooner that we can get these types of proposals into the system, whether they pass or not, the better.
Dealing with the backlog in the interim period
In the past, I've usually done this through the weekly governance cycle. If you look in the forum thread I posted, I think there are a dozen references of how we have done this in the past. So, before we refactor MIP10, in this interim period, I'm proposing that we go through the oracle proposal backlog through the weekly cycle.
Rich: We're transitioning from the processes that arose organically how to do governance and moving to the MIPs process, and it's going to be a phased approach. So, over the next month or two, I'm sure we will be firmly embedded in the new MIP world, but we also have to balance processes with the expediencies of running a business and supporting the protocol. This is probably an example of one of those situations where we need to what works today in towards what's going to work more effectively in the future. Thanks for the recap, Nik.
Cryptowanderer: I think this oracle proposal highlights the tension between precedence and flexibility. Nik is right that a lot of these applications are really good ones. It would be amazing to see them included in the protocol. I'm very much in favor of doing them in the weekly governance cycles. But it's a question for this governance call to which we prefer precedence or flexibility. A large part of what Charles put together in the MIP process is about flexibility. So I think it's great that we lean towards that. But it needs to be clear that there is a tradeoff here. Also, on a personal note, it's great to see you wearing that hat again, Nik. Thank you.
Rich: It's part of the decision-making process. We need to dig into risk versus reward and prioritize. Collateral onboarding is a huge priority for the protocol right now, but it's very complicated. I agree with you completely, Cryptowanderer. As long as you keep a vigilant eye on where we hope to be and ensure that week-to-week, you're closer to that goal, that's generally fine as opposed to tearing off the band-aid and doing everything immediately. There are different philosophies. There's iteration; there's strict adherence to process, there's evaluating business needs as opposed to social and protocol needs, and more. It's enormously complicated. I'm not going to be able to unpack it completely, but assure everyone that I'm enjoying watching it happen. It's a team effort, so we'll have to work together to figure out the solutions.
Seven inclusion polls went out on Monday, and they ended 25 minutes ago. Today, LongForWisdom and Rich are going to perform the inclusion poll review for those seven polls and confirm the results of which proposals can then move on to the governance polls next Monday.
After this segment, Rich and LongForWisdom will do that review of Inclusion Polls.
Governance polls will be submitted for the proposals that have passed the inclusion poll stage. These polls will run for three days, ending on Thursday.
Just to recap, the purpose of these polls is to determine if the proposals at hand should proceed to the final executive vote in week-four of this month's governance cycle.
Next Thursday, during this call, the Governance Facilitators will confirm the governance poll results and dictate which of the proposals will move to that final executive vote.
Mariano is going to speak towards the TUSD token upgrades.
Next Monday, there's also going to be two governance polls for KNC and ZRX that will as part of the weekly cycle, to determine if they will proceed to the executive vote on Friday.
The Community Greenlight Polls have concluded, and LongForWisdom has updated the collateral status index. The next Community Greenlight Polls will go up on June 22nd, in the final week of June's Governance Cycle.
I want to note that if the amendment MIPs pass at the end of this month, the Community Greenlight Polls in the future will begin on the third Monday of the month, running for two weeks and ending in the final week of the governance cycle, instead of carrying over to the following month. This helps make the process more efficient and intuitive.
There were two subcategories added.
The general idea here is that if anyone in the community has an idea for a future improvement proposal, they can go in and post their thoughts and the ideas behind it. And start discussing with other community members, getting feedback, and eventually turning it into a formal Maker Improvement Proposal. The redesign of the Liquidation System, pre-MIP discussion, was posted there just yesterday.
This is a read-only category that will be dedicated to providing more awareness and notifications of what's going on during the governance cycle in terms of voting. It will also be the go-to place to see what the active inclusion polls are, the governance polls, and execs all related to MIPs. That also addresses Andy's comment in the chat further, about having a notification-type system, or at least more places to see what the active votes are instead of a couple of days before the votes. This category is new, and it's bare at the moment, but I will be updating for the governance polls next Monday.
Inclusion polls have finished. Six out of the seven MIPs have passed. Including all of Charles' amendments, Cyrus' onboarding, and MIP13. The one that did not succeed in the inclusion poll is MIP14, which would allow Governance to set a target to receive Dai drawn from the protocol.
Rich: I want to make a comment and a question, as this ties back to many themes and some very tasty and meta/philosophical questions. As an example, let's use any team that wants to do something. Depending on their philosophical and/or political leanings, autonomy, in my opinion, and true agency are pretty hard to achieve if you can't fund your own activities. So we have this situation where we're expecting and counting on the community to self-organize and establish identities and organizations, and to do work for the protocol; so the protocol can be aggressively decentralized, and the Foundation can hand the protocol off to the ecosystem. We can see what this world looks like at that point. The problem is that people need compensation for their work, and we do not have a mechanism to do that right now. There are pros and cons; I'm not throwing shade here. It's a tremendously scary MIP in some ways. Let's detach it from that MIP explicitly. There needs to be a mechanism where value can be taken out of the protocol and given to actors in the ecosystem that are going to support and improve the protocol. Until that happens, it's going to be pretty hard to attract actors in the ecosystem that want to improve the protocol. Let's face it; we all need to eat. It's worth considering how we're going to tackle this challenge because we, the community, need to solve this soon. We need to be able to have agency, and part of that is to be able to pay people to do things. I would like to encourage the community, the ecosystem, and this group to look at that MIP, figure out what is alarming or unpalatable, or what we could change about it, and consider what it would look like in its newest form. That's where my question comes in: what happens now? What is the idea for this? Does it go to the icebox, or can it go immediately back into voting after some tweaks? What's the next step?
Charles St Louis: In terms of what's written in the MIPs, this proposal is made through MIP2; Which is a faster process and lasts for three months after the official ratification of the MIP. This proposal could be introduced for another vote, but MIP2 does state that it has to address the issues that resulted in the initial rejection for it to proceed for another vote. Just to further your point from earlier, if people have reasoning why they didn't want to vote or why they voted no, please provide that in the MIP14 forum post, so we can figure out what the issues were and resolve them.
Rich: That raised another interesting situation that we've run up against a few different times in the past. If a poll goes up and that poll doesn't pass, obviously the ecosystem didn't want it. But every once in a while, there's an unusual situation where one or more people begin to wonder whether the ecosystem didn't get it, or if it was phrased incorrectly, or if it was not a good time. What's the solution? There's this assumption that the ecosystem got it wrong, and we need to ask them again. That's a huge question mark, and unless people point to exactly why the vote was contentious, it's hard to know what to do.
Cyrus Younessi: Isn't protocol funding one of the major themes of future decentralized risk teams and all sorts of domain teams? Is there a competing proposal or some separate track that we're on?
Rich: I think there's a series of conversations and ideas, maybe Charles can comment on it, but we've talked about elected paid contributors(
EPC), domain teams, protocol funding, the subfunction, and the buffer. This is one of the biggest rocks that we have left to turn over. And you're right, Cyrus, it's pretty hard to move forward with any of the existing domain teams that we have identified and then decentralize those. It's hard to come up with new ones; it's hard to attract new talent into the ecosystem unless there's a clear path for people to get compensated for their work, so it's something that needs addressing.
Cyrus: I was thinking about vault compensation. This could be a pretty juicy trial run, paying some specialized blockchain analysis company to pour through the data and confirm the work of the working group.
LongForWisdom: There are several things that would have been useful to have this or something like this to do in terms of the vault compensation stuff. As you said, paying some towards it, but also actually paying the working group members themselves that have been working on it. Several people are working on this group. It's kind of difficult to convince people to work under certain conditions without remuneration. Especially if we want something to happen quickly, if this were something that can wait six months or a year, it would eventually get done. But this is one of those situations where we want something done sooner rather than later.
Rich: Yes, there's nothing better to solve the problem of commitment drop-off than money, paying people for their time. And there are a lot of smaller initiatives that this type of mechanism could be beta-tested on, so I think that the key is that people boost into that MIP and make their concerns known or ask some piercing questions. My guess about the issue is we have a bucket of money with a protocol attached to it, and no valve on that bucket. So it can be scary. There need to be checks and balances, thresholds, circuit breakers, and kill switches. It's just a matter of figuring out the configuration for this kind of valve to live in before moving forward.
Cryptowanderer: I agree with LongForWisdom that there are many use cases for this. I know that lev brought up this fact that we might want to limit to make sure that you couldn't withdraw more than the surplus that would initiate
flop auctions and that LongForWisdom was somewhat against that. But perhaps it's worth reconsidering that given the results of this inclusion poll. And the other thing is that perhaps we need to be more careful about delineating the conditions around what kind of accounts or how the account that receives Dai can spend it. Perhaps that gives people a little bit more security?
Rich: The one thing that gave me pause was picking an account where the money shows up. That made me slightly nervous. If I had to guess what these kinds of things are going to look like, one of these ratified domain teams in the future that we haven't entirely defined yet is going to be an accounting team. The distributed accounting team of the Maker ecosystem. A group of people can get together and say, "OK, we're in charge of the budget that comes out of the
suck and can handle allocations, disbursements, audits, and reviews." We need decentralized accountants. This position is one of the least sexy things. We need to accept that not everything is the rock-and-roll world of risk and smart contract development. Some things are less exciting. We need decentralized lawyers, decentralized accountants, decentralized finance people, and decentralized auditors. I think that maybe a team in charge of the DAO's budget would be able to handle some of these things. Maybe these are my personal biases, but do we want to come up with the perfect algorithm and hope that someone doesn't spend $2.6 million in fees? Or, do we want to have a group of people who are mandated with making decisions about how much funding comes out of the protocol, where those funds go to, and make some assurances to the rest of the ecosystem that those funds are well spent. Compiling value for money. This is a significant issue, and we're running out of time. Perhaps we can talk about it in the Q&A session.
LongForWisdom: Next week, there will be a single poll going up that asks whether all six of these approved proposals should go for an executive. So it's a bundle, intended as a trial run for the executive. If this bundle at this stage passes with a large majority, it's easy to expect the executive to pass.
Something interesting happened last week. I want to thank the True-USD team. I think we have Hal and Ryan here, and they can talk a little bit to the community, but let me first say what happened on the smart contract side.
As you know,
MCD works with adaptors. So any new token or new collateral that we use has to have its own adaptor to interact with the system. In the case of standard or compliant ERC20s, as we call them, we can reuse adaptors. For certain collateral types, we need to tweak them a little bit. This is the case for tokens with different decimal points, than the somewhat standard 18, or with other differences.
In the case of True USD, the token uses what we call an upgradeable proxy pattern, so the actual base address doesn't change, but it gives authorized actors the ability to upgrade these tokens. While this is great in some cases to fix bugs or add functionality, in the case of MCD, adaptors are probably one of the most potent contracts in the whole system.
The Smart Contracts team decided that we were going to test pinning and allowing certain implementations for True USD. Last week, when the code went in, an implementation was added to the allow list. Which MKR voters voted in, and that's the code that the Smart Contracts Team looked at, vetted, and decided was good to go. I'll post the link to the code. But just as the spell was being executed, there were a couple of upgrades to the True USD token. There was a new implementation that the system detected and wouldn't let you
exit the system. Once this happens, you can still draw Dai with any token that was already there, and you can pay your debt, but for example, you can't add more than what's already in there.
I think that it's a good thing that this happened now, with a token that had only one vault open and that it was from someone at the Foundation. We were testing the Vault type on MainNet for the UIs and everything else.
But this also opens up further considerations for other collateral types that may have this upgrade pattern and what to do about it. Also, the fact that we should have better communication with the team behind the collateral.
These are all growing pains that we are going to face more and more, and we have the opportunity to either create new MIPs or come up with some processes for the Smart Contracts Domain Team, the community, and everybody.
Right now, TUSD isn't useable in MCD. For it to become usable, the community would need to vote for the new implementation. The Smart Contract Team would have to look at the implementation and give the OK. I'd like to turn it over to the True USD team to talk to the community a bit, or maybe LongForWisdom can present the community view from the forums.
Hal from True USD: Hi, I'm a smart contract developer on the True USD team. Briefly, I wanted to chat about the upgrades and what they might look like in the future. I think this might help create a process in Maker for other collateral tokens in the future. I'm a big fan of Maker; I've been using it for a year and a half, and happy to be part of the community. My proposal, specifically for True USD, that may possibly become a model for handling future token upgrades is: before any upgrade is made, we publicly announce the upgrade and deploy the new implementation as far in advance as possible. I was thinking about two weeks before the upgrade happens. If each implementation needs a vote, then more time would be helpful. We'd make a public post in the forums and other channels for True USD, with links to the old and new implementations with notes and audits about the upgrade. The question comes down to the voting process for voting on new implementations and how long that could take.
Rich Brown: There are other things to unpack too. The voting on new implementations, adapters, auditing, and technical considerations could be onerous. But there is a larger question for the ecosystem. We have a situation where we're dealing with the first-mover disadvantage to money legos. They can be acting more like money Jengas at this point. If somebody updates a library and doesn't notify upstream about that library, and they have a breaking change, then our money legos turn into money Jengas. I wonder what that implies for additional collateral types and for the wider ecosystem. Is there a need for a social layer to be imposed on top of this stuff? If Maker wants to upgrade a library, do we need to get into a call with five other DeFi organizations to clear that and make sure everyone understands? As we become more tightly coupled in this ecosystem, having people changing things could be fairly disastrous, considering there's money, or value in motion.
Mariano Conti: The solution that we put in pinning implementations and allowing them specifically; doesn't solve the problem completely. Since much can happen in one block, this is just one of the measures. Perhaps the community thinks we're going against what an upgradeable proxy pattern means: make it transparent to the users when they are upgraded and make sure they're expected. Then the risk passes to the
SF. All of those are issues to discuss.
Rich Brown: We live in a vaguely antagonistic ecosystem where the strongest and most adaptable protocols survive. There are no rules or councils determining who releases what and when. I've pitched a social layer before where if project A upgrades that they notify C, D, and E, to see whether they're impacted. That's probably not realistic since you can't predict what the dependency chains will look like in this space. It feels like the solutions need to be more defensive on the individual protocol level. You pick what you're going to support, and then you have circuit breakers. Does that sound more along the lines of what you're discussing, Mariano?
Mariano: Yes, so I'll be specific about this and leave the community to be deliberate. In this case, the Smart Contracts domain team has an avenue of communication with the Trust Token team now and the community in general. Depending on how this goes, it may influence writing MIPs or standards for the future. Right now, we have a token we can't use, so we'll use this opportunity to see how we fix this now and create a more formalized process. There are a couple of avenues I see. A poll on Monday, perhaps, requesting the Smart Contracts team to review the new code and get out a governance poll either Friday or the following Friday. I encourage people to go to the forum posts and tag folks or me from the Smart Contacts team to talk about this. I'm not saying this is urgent right now, but we should discuss the ramifications because we will see this in the future with other collateral types. We caught this one at the best possible time with the least amount of disruption.
Hal: For that discussion, we're open if you have any questions about the smart contracts or anything else specific. We have a Telegram chat already and another public chat. If anyone is interested in learning about True USD and the nature of the changes that we're making, feel free to ask questions there. Thanks for including us in the discussion.
Chris Padovano: Another thing that comes to mind is getting clarity from the True USD folks about how and when a blacklist is used. Recently we had a proposal from Paxos for a stablecoin, and they provided clarity on exactly how that mechanism will be used. It's a huge part of auctions and being able to process the collateral through governance. Having visibility and understanding of how things work legally would be very helpful. Governance, generally, as Mariano mentioned, with any type of centralized collateral, is a critical consideration to keep in mind.
Hal: The blacklist question is pretty straightforward. True USD is a compliant stablecoin where we take care of the Fiat on and off ramping. The blacklist is to prevent malicious parties from money laundering and breaking banking security.
Chris Padovano: I meant the actual implementation of the blacklist and having it in writing.
Ryaan Rodenbaugh (True USD): I didn't see the thread that Paxos shared, but I'd be curious if it's different than the Terms of Service that we've shared in the past. I think it was posted in our original post and followed up on a question about it with a second post. It would be helpful to understand what level of clarity is needed.
cmooney: The biggest fear is that the collateral adapter gets blacklisted. That would be disastrous for the protocol.
Hal: We would never do that; there is no legitimate reason to.
Ryan: I can't think of any circumstance where we would. I can speak to the legal team to give you a more formal answer, but right now, I cannot think of a reason.
Chris Padovano: That's all very helpful, thanks for providing that color on the call. I'll post the links in the chat, but the FAQ that PAX put together I think is helpful and gave a better understanding of their process as well. It's reassuring to hear that you would never blacklist the adapter. This is a thing we're very concerned about because we would have to re-collateralize the protocol for however much is stuck in the collateral type. You understand the concern, right?
Ryan: Yes. We definitely understand the concern. We can check the FAQ from PAX and give the same level of reassurance.
Rich Brown: Sounds like there's going to be an audit trail here. I sound like a broken record, but we should bring this to the forums and have a thread dedicated to this, a place for lawyers to fight it out, reach consensus, get some documentation in place, that would be super useful.
Mariano: I want the community to evaluate a hypothetical scenario. We might have to do this in the future. Right now, with pinned implementations joining and exit stops working without a community-voted upgrade; Imagine collateral with $50 million of value in the system, and then this happens. How would we react? Don't think just this one instance, try to come up with good ways to take care of a situation like this in the future where a lot of value is on the line, liquidations are on, price is going down, and you can't add collateral to the system because we couldn't upgrade. These can all be fixed, but we need to think that over.
Rich Brown: I love that. Like disaster recovery scenarios, and what we would do in situation A, B, and C.
From cmooney to Everyone:
you cannot join() (add) or exit() (remove) collateral if the implementation changes.
From brianmcmichael to Everyone:
From Hal to Everyone:
TrustToken telegram chat for anyone interested in discussing TrueUSD or asking any questions.
From chris_p to Everyone:
From brianmcmichael to Everyone:
Our adapters have full access to DSS and also reach out to third-party token contracts. One real concern is that a third-party contract could change its implementation and perform a re-entrancy attack on the adapter.
From cmooney to Everyone:
It would be nice to see if TUSD has an audit on the new changes, have our domain team check it out, and then vote to whitelist the new implementation.
Total Dai is at $123 million.
$111 million from ETH
$523 thousand from BAT
$9.9 million from WBTC
$1.1 million from USDC.
Overall, Dai has been trading more or less at a dollar. A couple of swings above and below.
What happened with ETH was the price fluctuated downward, and Dai rose up a bit, ETH price fluctuated upwards, increasing ETH<>DAI trading volume and Dai went down a bit. Since the last Dai price rise, there was some ETH price reduction, and we'll have to see if the trend continues where Dai price stays above peg. My guess is yes. If ETH jumps and dips quickly, that has a tendency to elevate Dai price. These are small differences in the grand scheme of things. We'll watch and see, but I'd expect it to stay with a slight buffer above a dollar.
BAT-Dai supply is still stagnant at half a million.
USDC down significantly since May.
WBTC-Dai supply had a sudden high utilization, right after adding it. It capped out close to the DC for WBTC. If we increase the cap, it would be interesting to see how much it still gets utilized. My guess is there are new entrants who want to open vaults but can't due to the cap on the ceiling.
ETH, as a collateral asset, has the largest trend worth examination over time. With the largest DC, it has the most room to grow.
After the decapitation of that growth-curve in March, ETH continued its growth trend. There were individual users performing large mints for short periods. But the lower bound of that line continues to grow. As we spoke last time, around June 3rd, we saw a large mint to generate yield on Compound. A few days later, that user went back and repaid the Dai debt.
That was the most recent spike and dip you see at the top right in the chart. Apparently, for short term use and some speculation that it was to generate volume for COMP token distribution.
The base trend has continued, where smaller positions have been continually opening. The system is designed where users can easily mint large positions for low cost and then repay them in short time frames. Especially with fees so low. This has always been part of the reasoning to keep a short leash on the
DC. Since it creates a lot of opportunities to exploit the buffer for short term usage. It's a stylistic choice by the community, but the room is there to execute moves like that. Especially right now that the debt is back and the
DC is at $140 million. That kind of use case can continue to occur.
For ETH, the 500% Collateralization Ratio Bucket had an uptick. Users who, apparently, have put collateral into the system but haven't yet minted as much Dai as they reasonably could. This over-collateralization brings a lot of latent potential in the system, which is a positive indicator. This potential could be waiting for a less volatile ETH price. Sometimes that volatility can cut both ways because the appetite for leverage is tied to volatility. Volatility also ties into liquidations, which can improve the collateralization of the system. Also, volatility is an indicator that ETH is making price movements, though it's situationally dependent on other variables. On the flip side, there are lower-end CR buckets of 150-200% to consider. The distribution of Vaults over different CR buckets still has that tri-model shape. There are three tranches of users. In the middle is the system average of 300-350% CR. In the last few months, there has been a rise of the lower end CR category centered around 200%.
You can see that reflected in the liquidation walls on ETH of $150/$160, and then at $102.
The Dai-USDC direct trading price, not the ETH-Dai implied price, is in line at 1.0002. That had been higher in the past. It's come down very slightly, though still maintaining a small buffer above the $1 peg.
WBTC collateralization is almost entirely around 250-300%. We know that there are only a few users making use of the WBTC DC. There is a tight group of those users. It's slightly less collateralized than the middle-of-the-road for ETH thought, not particularly risky in terms of a pure asset pricing basis. The major wall is at ~$5500.
Obviously, there are other potential risks that come with WBTC. If you hit $5500, you would see effectively $10 million in liquidations, but very little at any price before that. So this collateral pool is quite binary.
That's it for what I wanted to share if there are any specific questions I'll answer them happily.
Cryptowanderer: I wonder if you can speak about the stylistic choice of not going in for short term use of the protocol. In a personal capacity, do you think it's negative or more neutral? What are your thoughts about the more "get-in / get-out" behavior?
Vishesh: My response would have to be "nice try." It's a technical capability: there is a system that doesn't exact transaction fees that are meaningful. Instead, it exacts Stability Fees, which are, by definition, a function over time. It's how the system works. I can't sit here and tell you whether it's good or bad; the community will decide. Once they have a tool in their hands, how do they want to wield it? It's a structural design component of the system that it's cheaper to use for short time frames.
Thanks, everyone. Thanks to everyone who presented today, thanks, TUSD, for coming on the call. Lots of complicated things to discuss. How the collateral gets onboarded in the system and what happens when that collateral behaves in ways that we didn't anticipate. As Mariano mentioned, please join us in the forums to discuss that issue.
Let's not lose the thread: we need to decentralize quickly and effectively. For that to happen, we need empowered actors. In order for empowered actors to arise, they need to be compensated, and we don't know how to do that yet. If you have ideas about how actors should be compensated, take a look at MIP14 and voice your concerns or ask questions.
Thanks, Charles, for your recap, thanks LongForWisdom, and thanks, Vishesh. See you next week.
MCD: The Multi-Collateral Dai system
CR: Collateralization Ratio
DC: Debt Ceiling
ES: Emergency Shutdown
EV: Executive Vote
GP: Governance Poll
SF: Stability Fee
DSR: Dai Savings Rate
MIP: Maker Improvement Proposal
EPC: Elected Paid Contributor
Artem Gordon produced this summary.
David Utrobin produced this summary.
Tim Black produced this summary.
Juan Guillen produced this summary.
Everyone who spoke and presented on the call (listed in the headers.)