Episode 146: June 17th, 2021
01:27: Governance Update
04:00: GovAlpha Core Unit update
05:21: Forum at a Glance
08:56: Protocol Engineering Team Update
20:09: Oracles Team Update
23:15: Risk Team Update
25:18: Real World Finance Update
30:47: Growth Core Unit Update
35:36: Sustainable Ecosystem Scaling Update
40:40: MIPs Update
47:46: Discussion on Institutional Vaults
Agenda and Preamble
- Hello everyone, and welcome to the MakerDAO Scientific Governance and Risk meeting number 146, taking place on Thursday, June 17th at 17:00 UTC. My name is LongForWisdom. I am the Governance Facilitator at MakerDAO. We have got some regular updates from the usual suspects. We are going to try to initiate a discussion on institutional Vaults. This has been a topic that has been discussed over the last couple of weeks.
- We like people to get involved; we like people asking questions and commenting, so please, do not be shy if you have something to say.
- Last week’s Executive has yet to pass. I think it is currently 36.000 MKR supporting out of 70.000 on the previous hats. There is still a little way to go. Hopefully, we will see that go through in the next few days. A quick reminder, we have the month of June’s ratification polls for MIPs as part of the monthly governance cycle now live for the next ten days; they went up on Monday, so please vote on those if you have not already. We recently changed the monthly governance cycle such that these polls were the only requirement for proposals to be ratified. Therefore this is your chance; there is no executive after this in the absence of technical changes; please vote if you have not. We also had a couple of other polls this week as part of the usual weekly cycle. We had three SushiSwap LP onboarding polls which passed. That was, I believe, for the ETH-LINK, YFI-ETH, and AAVE-ETH pairs. Those all passed, which is great. We had a couple of
dust parameter polls as well. One proposes moving the
dust parameter from 5.000 DAI to 10.000 DAI. The
dust parameter is also known as the minimum debt floor, which is the minimum amount of DAI that someone can withdraw from a Maker Vault. We had an ETH-B specific
dust parameter poll which moved ETH-B
dust from 15.000 to 30.000 DAI. Both of those passed as well. When it comes to this week’s executive, assuming that last week’s one passes and they are not blocked, we should include the
dust changes I just described. However, I will wait for Smart Contracts to confirm that it will also enable the flash mint module, which has been in the queue for a while.
GovAlpha Core Unit update
GovAlpha Weekly Update
- We recently posted in the forum an onboarding post, essentially describing some things people can get up to in GovAlpha, and requesting anyone interested in working with us to get in touch. If that is something you are interested in, please get in touch with me. Another thing I am going to say regarding GovAlpha is that we are approaching three months since we got a budget, and we will be doing a quarterly review post at the end of June. It will be fairly long and comprehensive. I look forward to that in the next couple of weeks. This past week we have been putting out fires a little bit alongside the usual recurring commitments. Not too much to report, I am afraid.
Forum at a Glance
- One announcement that you may not have noticed is that the Risk Core Unit has added even more features to the dashboard. I have a feeling Primoz will want to brag about those a little bit in his segment. First, however, there are links if you want to get on there.
Forum at a Glance for June 11th - 17th
Real World Assets May Report
- An update on the state of RWA has caused quite a stir in the community. There is a lot to learn in this thread, but a reminder to engage assuming good faith and in the spirit of collaboration.
What is stopping us from investing in the PSM USDC?
- A discussion on deploying the USDC capital from the USDC-PSM-A facility, I recommend checking out a prior post on Balance Sheet Manipulation as well.
@Planet_X brings forward some questions on the state of marketing at MakerDAO and discusses how we can coordinate our efforts between Core Units.
tin/tout parameters for new PSMs
@ultraschuppi follows up on a previous Signal, asking the community if they support the Open Market Committee 2 making decisions on the tin and tout (Fee in and out) for incoming PSM vault types while asking the community for their input on the initial Debt Ceilings.
Adjusting ttl on flap-auctions
@ultraschuppi back at it with the signal plans Here proposing a change in the duration to surplus auctions, Signal ends June 24th.
- Seth Goldfarb: In regards to the marketing Maker thread that Peyton mentioned, we will be having a discussion about that on Monday. There are some details in the thread; if anybody is interested in joining, please feel free.
Protocol Engineering Team Update
- In development this week, we have got the Direct Deposit module. This is a final PR taking into account the global settlement considerations. Then the big one is the Flash Mint Module which earlier this week was deployed to Kovan. I encourage anybody if you get a chance to play with the Flash Mint Module on Kovan. I think I am going to switch gears and play with that for the afternoon. These are also lovingly referred to as recreational nukes. The Flash Mint is a big deal; it is maybe more like a nuclear power plant. It will add many capabilities to arbitrage the peg in different locations or have enough Dai liquidity on hand for arbs to just go in and work out peg issues. It also gives us this native toolkit to do a bunch of cool stuff where people can rebalance Vaults of one type with another type and stuff like that. There is a lot of obviously pretty cool things that can be done with it. It is a pretty big deal; everyone should take a look.
- For delegate voting, we are waiting on some feedback from the delegates regarding whether or not delegates should expire. Then there has been much work on the SushiJoin adapter. We are ensuring that it behaves correctly under an emergency shutdown. We are also dealing with auctions for the SushiJoin adapter and ensuring that rewards are appropriately distributed. Lots of work in that area. - As far as DSSVest, work wrapped up on that module, and DSS interfaces took some changes for the DSSFlash. In reviews, we have some of the clipper-specific stuff for the CropJoin. There is a factory for deploying
flip. I think it is
join, which is a more detailed technical nuance. We are working with BlockScience to improve formal modeling skills. We are also engaged with them and experimenting with their tooling. Finally, there has been much research on the Oracle tail risk mitigations. This is the case where the Oracle team puts a ton of work into making sure that we do not ingest bad prices, and Liq 2.0 has us leaning on some of that work. We added minor mitigation in the ClipperMom to trip the breaker on liquidations if the Oracle price changes by too large a delta between updates. However, we think that for proper defense-in-depth, we will add maybe a little bit of extra stuff there. There is just research happening with regards to that. For L2, the Optimism team changed a bunch of their token standards. We have a vast PR accommodating those changes. Moreover, we are engaged with Sertora using their tooling to do formal verification and proofs. All of that is coming along; it is just that even the API or the framework that we are targeting is kind of a moving target on us. It is a little bit tricky. Then for discussions, I think we have been discussing with the Growth Core Unit about institutional Vaults. There will probably be some discussions about that later. Also, we have had scaling-related discussions with SES.
- We have been talking about their sandbox and scaling models and seeing what areas PE can hand to SES to create safe sandboxes and incubate engineers to work on the protocol. Also, I think Brian is working with Oracle to give them an instant access module for authorizations to whitelist readers against the medianizer and the oracle. Aside from that, does anyone else on the PE team have something that I forgot that they want to mention? Finally, I should say I have been working a little bit on making sure the auction demo keepers are also functioning correctly, so there is some keeper work. Does anyone have any questions?
- David Utrobin: Can you repeat that last bit about the keeper work happening?
- Chris: There is this auction-demo-keeper repository, and the point of that repository is that it is a backstop keeper. It is supposed to be a reference implementation. It started as a reference implementation, but we want it to be a backstop keeper for the protocol. That way, in an insane liquidation event, the hope is that any member of the community could spin this, clone this repo, put a private key in it, point it at a node, and start the thing up. It will give it a little F, do the authorizations, and start flash loaning the collateral and then handling liquidations under Liq 2.0. That is the point of the repo. Any other questions?
- LongForWisdom: Has the Flash Mint Module been audited? Does it need auditing? I know it is quite a small thing, so maybe it does not.
- Chris: It has not gone through any formal audit. Well, I do not think so; if we did, it might have been around the end of last year, but I do not think we did.
- SamM: No. It has not. However, it does not need it. It is dead simple. We have had multiple reviews from the team. It is safe.
- Chris: We have looked at it and tried to think about what is capable, and Sam brings up a good point in chat which is that there is a kind of lindy effect around the DC that we are thinking of giving it, which is around half a billion because you can get that from a Dai flash loan or flash loans around that amount from other places. We do not feel like we are adding anything to the ecosystem that would be too dangerous.
- Brian McMichael: Flash loans caught us by surprise. It has just been standard practice to build around that and account for mass amounts of liquidity.
- Frank Cruz: Chris, looking at an institutional Vault, have you guys looked at any KYC and AML third-party providers in case that is required?
- Chris: Not the PE team but maybe Business Development, or Growth, or somebody has looked at that. However, right now, I think the institutional Vaults we have been looking at are not at that scale. They are already crypto-native institutions, so I do not think there is a KYC requirement right now.
- Nadia: Yes. I agree with you. We have been talking with a few because we know with whom AAVE will work, and it will be easy to onboard them on the process. Still, at least at this stage, we are on the first steps of creating institutional Vaults; the polls will be managed by Nexo and other similar companies that we already know. I do not think we need a KYCA company in the middle. What we will need, and it is what I wrote in the post, is a deep analysis of the financial statements and everything related to Nexo in this case or any other institution that wants to have this kind of Vaults because, in that sense, the Risk team will have to analyze not just the collaterals but also the institution that will own the Vault.
- BrianMcMichael: We forgot to mention also that I did a permission Gemjoin adapter earlier this week. Therefore we do have a prototype of a joint adapter that could be used to whitelist individual parties if we need to go that route.
- Kurt Barry: I would say, in general, the blockage on this is not engineering complexity. It is fairly straightforward to build some permission into stuff or build, say, fixed rates. I think it is more about the risk management and scalability concerns more than anything.
Oracles Team Update
- We have been setting up the Core Unit. The poll for the Oracle Core Unit is also live right now. I think it has been up for four days, and it runs for two weeks total. Go vote on that; whether you approve or disapprove, it does not matter; go vote. We are continuing work on the stETH oracle. I still have not entirely decided whether we will use the contracts that they wrote or whether we are just going to go with a feed-based approach. If we did use their contracts, we would deploy our instance because theirs is upgradable, and we do not want to take on any of that risk if we were to go that route. Still undecided, but it sounds like we are getting closer to a solution. I am also talking to a couple more potential light feeds. That will be interesting. I do not think we have onboarded any light feeds in quite some time. I cannot share any names yet, but you should see some proposals pop up in the forum fairly soon. The last thing is that you should vote on the executive because we have many yEARN whitelisting proposals for the Oracle to do delegated vaults, which gets our oracles used more. Still, the delegated vaults inject yEARN TBL for those tokens into Maker. They can borrow Dai and then put that DAI in there and their Dai into their Dai kind of Vault. We could see a pretty significant uptick from the UNI, LINK, AAVE, and I think the last one is COMP, from those Vaults. Let us see what happens there.
Risk Team Update
- The update will be brief today because we are mainly occupied with three larger collateral evaluations: stETH, D3M, and Polygon.
- We want to have the stETH evaluation complete by next week. We need another few weeks to finish the others. As promised, we posted the SP-SUSHI-ETH and xSUSHI risk evaluations.
- We also added new sections to our risk dashboard mentioned by Payton. It now shows the auction statistics and everyday performance. In addition, there are now interactive simulations for MKR loan losses. Another page now features all of our forum posts, including all past parameter changes and proposals. You can visit at maker.blockanalitica.com. Feedback is appreciated.
Real-World Finance Team Update
- Three-point update today: The first is NewSilver regarding the executive summary issue. I will publish a post soon, but we are working on a solution. To summarize, it was an option for the asset originator to change the executive summary, more or less the terms of the agreement. There were two changes: One of the drop APR does not affect us anyway, and the other one was a change to the metrics to know if a loan can be accepted or not in the pool, which was 85% LTV and now up to 90% LTC lump cost. We will focus on NewSilver tomorrow evening. I will place a link to the call. You will be able to ask any question to NewSilver and understand why the change was made. However, the issue is that we should, at least, have the opportunity to discuss the changes, and we did not because maybe I got an email, but I did not act on it, or I did not get an email. I do not know precisely what happened. I am still looking for the post mortem on it. As far as the solution to move forward, we will add a mandator that has already acted previously. However, upon the actor, we have a notification list, and we make sure that everyone on this list gets an email before changing the parameters. We will have a period where if we liquidate the Vault, no change in the executive summary can be done until we have exited all the positions, no matter if it takes one week, one day, or one year. We will always keep the same terms until we exit.
- We are still working a lot on onboarding law firms. Currently, we are in talks with three law firms. One in the Cayman Islands and two in the US advise us on all the RWA topics, one of the significant components of the new budget on vote currently for the RWF team. As a new Core Unit currently, we do not have any budget for that. I am using part of the budget for something else to pay for the lawyer because I gather it is more important right now. It is 20.000 DAI per month on the legal stuff for the next budget, but most likely, that would not be enough, so I will have to take it from somewhere else inside my budget.
- The last point that I think is essential to note. We are also working on the SolarX Cayman Trust Structure. SolarX is a solar farm in the state of New York. The point of this project is that the closing should happen next month more or less because obviously, the guys need to add the credit line to buy the land from the owner and start all the audits and the construction of the solar farm. I just wanted to note that the only reason why we might move fast on this topic is that on our team, we have Christian that is working on that. He was head of legal for a 16 billion LNG project, and it is not like every day we have someone that did something way more significant than what we do currently. That is why I think it is a good opportunity for Maker to move on this topic. Then the whole team will take a vacation. Does anyone have any questions?
- Brian McMichael: I just want to mention that Maker Governance should probably look into the history of Solyndra, which tried to build a solar farm in Nevada and ended up spending about 700 million dollars of US government money before they went bust. I do not want to make a big deal about it personally, but I think there is some precedent behind things like this.
Growth Core Unit Update
Growth CU Weekly Updates
- We began conversations with our partners in El Salvador. One of them is actively working with the government and creating educational campaigns. They did approve Bitcoin, but it is not a very crypto-friendly country as of yet. These people want to assist merchants with local crypto payment integration and help ramp up this crypto acceptance phase. In addition, they want to attract tourists who would like to buy real estate through Bitcoin.
- We have two approaches: one being through retail users, which will require much explaining about Bitcoin and Dai, which would be very tedious. So instead, we can create an educational campaign for retail users who live in El Salvador. Another approach is to help partners launch a solution for merchants that can easily convert BTC to Dai.
- The government is also a potential approach but will be difficult because we need to propose using Bitcoin in exchange for Dai loans. If this works, it would be a fantastic use case. However, the government and retail do not understand Dai, and lots of education would be required with almost any approach we take.
- The Sovryn Bridge went live! It accepts Dai from the ETH Mainnet or BSC to RSK Networking using the Babelfish protocol, which will be live very soon.
- Also, @Gustav_Arentoft and I are going to be speaking at EthCC. We will be cover things from the roadmap foundation and the DAO. Gustav will be speaking about RWAs in the Maker Protocol. Once we have more details on what time we present, we will let you know.
Sustainable Ecosystem Scaling
- Quick update from us, we have been doing a lot on the admin side, which will be reflected on our document later. Anyone can spin up a core unit if they want to. We keep having these talks with very interesting teams to join the incubator, and I am looking forward to sharing details later.
- There’s this thing that I have not put in here yet because I wanted to make a better presentation. I think Chris already announced it. We are working with the PE team to work on the project sandbox. So we will be giving more information about that soon.
- Frank Cruz: Juan, what is the total count for the number of incubates?
- Juan Guillén: Right now, we have two that have already started. That is dTalent, which is three people, the other editor and Natalie. Then we have the DUX, five people if I am not wrong, so so far, it is eight.
- Frank Cruz: No, sorry, I meant how many possible Core Units are you incubating?
- Juan Guillén: We have a budget, and we also can help other teams, so in some cases, we are helping projects that want to spin their Core Unit informally, and we help them navigate governance. However, we are expecting to onboard maybe two more teams. We believe that these two Core Units, dTalent, and DUX, will be quite fast in general. Maybe in four months, they will be up and running, and all set up to start focusing on other groups and core units.
Weekly MIPs Update
- Juan: You left out the GovAlpha Budget Modification.
- David: Dang it! Sorry. Yes, this budget modification was posted by a non-team member of GovAlpha. As a MIP Editor, I posted my opinion that this should be proposed by either the facilitator or a member of GovAlpha. Therefore, the GovAlpha team was allowed to take over this proposal or allow the non-team member to follow it. Essentially, we decided not to assign it an SP number; it is now determined as a signal for what the community is looking to expect and GovAlpha’s next budget update. This was a unique situation being the first of its kind.
Institutional Vaults, Permissionless Access, and Managing Large Vaults
- LongForWisdom: We are hoping to spin up a discussion around in vaults and get an understanding of how the community feels about this.
- Nadia: This trend with institutional Vaults began because we initiated conversations with the largest users. We wanted to understand why they are not deploying more capital into these Vaults. We wanted any feedback about the MKR protocol. We spoke with Nexo and Primoz. What we understood was these user’s amount of capital and what they like. We decided that we need to provide better terms for this kind of user. At the same time, we are seeing other DeFi projects that are thinking of having institutional products that contain KYC, separate pools, and permission solutions. It is a good next step for us to begin thinking about these things. These actions will allow us to open larger Vaults on ETH, BTC, and collaterals. However, we have to understand what it takes; should we take permission or permissionless method? What are the technical and security implications for our decisions? We spoke with the Protocol Engineering Core Unit. They have a model that will allow us to propose a whitelisted Vault containing preferential terms for a couple of different institutions to begin working on a product for institutional users. There is more information in this post here.
- Christopher Mooney: There was much back and forth when we discussed this. We were not sure if this should be permitted or permissionless. Permissionless is a cherished attribute within this blockchain economy we have been building. I was resistant to the idea of whitelisted Vaults. However, we need to understand the pragmatic point of view that our protocols will offer better rates and help increase our Dai supply. I hope to take these institutional Vaults and whitelist one of their addresses, giving them access to basic risk terms. We review and attempt to figure out how to offer all users a permissionless method to appeal to other users. Whenever an institution asks us, we should figure out how to provide that to the masses. Otherwise, we will end up creating a new traditional finance system bringing up back to zero. Also, RWA is all permissioned Vaults, which we need to figure out to make it permissionless.
- Kurt Barry: What are the terms that these institutions want? How do they differ from other Ethereum users today?
- Primoz Kordez: Permission Vaults makes sense because it allows direct communication similarly to RWA. We want to know the balance sheet and unwinding procedure of borrowers. Through this, we can offer better terms. Most terms that institutions are after want a lower LR and low fees. This means that they would mint more to have a buffer against being liquidated. However, this alone is not enough to have everything from direct communication with them. Once we can understand their technical actions, it would become much safer for us to offer better terms. On the other hand, through permissionless Vaults, we can only see on-chain activity and hope that each user is safe for the Protocol.
- Lucas Vogelsang: At that point, by underwriting the credit risk, we are getting into the issue of ensuring any recourse against the business outside of what is locked up in the Vault. Do we want to simply rely on institutional reputation?
- Primoz Kordez: No, we are not talking about below 100% CR. We are thinking about 130% CR or a little lower with special capacity and fixed rates. The terms would be a huge benefit. One of our ideas was to implement origination fees and low SFs to guarantee that they will be long-term users. However, we do need to study how this idea works with borrowers.
- Christopher Mooney: There is an opportunity cusp. This will not be a widespread thing that we will be doing for every Vault. We will have a threshold for how much of this stuff we will be doing. We need time to expand L2 as well as other things.
- Kurt Barry: Permissionlessness is good. We are not getting rid of the existing permissionless offerings that we have. This is just a way to use very specific permissioning for a small part of the system to generate more Dai supply. This is naturally a good thing as long as Dai itself remains permissionless. There are concerns about scalability versus the use of time. We should choose a smaller number of high-quality relationships with institutions. Overall, these decisions can produce a net positive for Maker.
- Tim Schuppener: I am split between opinions. Permissionlessness is something that I cherish within the blockchain space. However, I do understand that have agreements and terms with institutions can prove to be very helpful. For example, we had many discussions concerning ETH-B Vault low LR. We finally continued with raising the DC. Through this experience, I believe that we cannot offer institutions lower than 130% CR if we want to keep the one-hour oracle delay. However, maybe they do not even need it. If they are professionals at managing their positions, they may be confident with just ten minutes.
- Kurt Barry: The primary purpose of the oracle delay is to protect the system from an oracle attack.
- Nik Kunkel: We use this hour to perform an Emergency Governance Vote to ‘unfuck’ the system.
- Kurt Barry: The hour delay also helps to prevent liquidations. It just comes with the package.
- Nik Kunkel: NOnetheless, it is all about Vault management. When you have an open, permissionless Vault and do not know the users’ experience level, we must provide them that hour from a risk perspective. If you look at the YFI Vault, which mostly contains yEarn, they are borderline under overcollateralized and have always been covered.
- Tim Schuppener: Yes, however, we were not able to agree or find consensus on making them a special deal considering they have a track record of everything-
- Nik Kunkel: Nexo does the same thing. They all have the same track record.
- Christopher Mooney: They are slightly different; yEarn is also monetizing. It is treasuring instead of putting collateral assets. There is a bit of danger with yEarn that turned some people off.
- Tim Schuppiner: I agree, there is more risk involved with the yEarn Vaults. However, we do not have any guarantee. We just have their track record but no method of punishing them if they happen to fail us. With an LR under 130%, how much of a market drop can we survive without them being liquidated?
- Nik Kunkel: They are still significantly overcollateralized.
- Primoz Kordez: Nexo is maintaining 400 to 500% CR. They are protected against more than 50% drops. They can also mint more.
- Tim Schuppiner: So they are not planning to go near 130%?
- Primoz Kordez: That depends on our agreement. I do not believe they want to be so close to the LR.
- Nik Kunkel: It would be nice to split the CR into two components: one is the lowest amount you can mint, the other is much lower relating to liquidation.
- Tim Schuppener: I discussed this half a year ago. Sam even made an addition to the Liq 2.0 repository.
- Christopher Mooney: If we want to add that into Liq 2.1, we need to consider that right now.
- Nik Kunkel: It is a best of both worlds; You do not have this liquidation risk and address the capital efficiency problem.
- Lucas Vogelsang: Lev said that longer oracle delays would be the preferential treatment we can offer that can achieve the same thing. We can expand it to two hours so that they can get closer to the collateralization ratio. If this works well, we may not even need to provide a lower limit.
- Nik Kunkel: Can you elaborate? That sounds very risky. A one-hour delay is theoretically a put option hedging against the price drop. Increasing that delay results in increasing the ‘value’ of that ‘put option.’
- Lev: Your idea would play very well because you potentially do not have this extra put option. It is also not out of the question to have legal recourse for these positions. There is some blended risk involving credit risk, which you manage by managing the DC for those positions. From a market perspective, our biggest weakness is our strict collateral terms. Other projects offer much better terms than us, which attracts institutions. We need to think about oracle delay, initial maintenance, and credit risk. We have a massive advantage in terms of rates but are offset by this disadvantage in collateral terms.
- Lucas VovelSang: I agree, Nick. It is not preferable over the maintenance ratio. This would just be a method to offer more flexibility.
- Nik Kunkel: Okay, it sounds reasonable. Does anyone know how complex it would be to split the CR into two components?
- Brian McMichael: It is not that complex. We already have a PR for it but came in a little late, so we ended up slating it for Liq 2.1.
- LongForWisdom: Is this something you can do separately from Liq 2.1?
- Brian McMichael: Possibly, but it would make things much more complicated.
- Kurt Barry: This is in the realm of possibility and should not take much time.
- Nik Kunkel: Regarding recourse with legal agreements, who is the counterparty on the Maker side?
- Lucas Vogelsang: If you figure out a trust that all the RWA projects want to use, it could work. It is complicated but should work.
- Christopher Mooney: These Vaults never discussed legal recourse because we planned them to be over collateralized. The parameters would not be set for easy liquidation.
- Nadia: We were going to post a proposal, but now I do not think we need to incorporate a company for legal agreements. I may be wrong.
- LongForWisdom: Lev has left, but he believes we can get far without legal recourse.
- Christopher Mooney: Eventually, we will have other structures with RWA. Once we find a reliable one, we will lean on that.
- LongForWisdom: It would be nice to provide this in a scalable way as well, where we can have one permissioned Vault with favorable parameters. It would be hard to please everyone with one Vault, but if Nexo works it out, we may have people come to us and ask for similar results.
- Brian McMichael: We already have too many projects, and tokens backlogged that we are trying to process and come up with a good method for meeting client demands.
- LongForWisdom: We can coalesce around a few variants to not be an individual thing per person. We can offer three options to pick from.
- Brian McMichael: If we gave options with higher
dust limits, for example, we would lean towards a safer permissionless solution. However, we would not be able to look at their balance sheets and CR history.
- LongForWisdom: I know we discussed the
- Primoz Kordez: We can set the
dust high during onboarding, but then we need to lower it because there are many risks involved if the maintenance is high, which may not allow us to make partial repayments. You can lower the
dust after onboarding. The DC must stay above 0.
- Frank Cruz: From a compliance perspective, is there any downside if hypothetically Nexos has a client that brought in ‘unauthorized’ money into the Vaults?
- Primoz Kordez: That is a question for the Legal Core Unit.
- Frank Cruz: Okay, Nadia, can you give an update from that Circle meeting?
- Nadia: It is today within a few hours.
- Christopher Mooney: There is probably a permissionless way to ensure that vaults have enough outstanding debt where liquidation was painful enough so that they were self-incentivized to manage it. There may be ways to create a similar deal for prominent players.
- Brian McMichael: I just realized that we might be able to do this more efficiently with a minimum requirement on
join but keep the
dust low in the system.
Common Abbreviated Terms
CR: Collateralization Ratio
DC: Debt Ceiling
ES: Emergency Shutdown
SF: Stability Fee
DSR: Dai Savings Rate
MIP: Maker Improvement Proposal
OSM: Oracle Security Module
LR: Liquidation Ratio
RWA: Real-World Asset
RWF: Real-World Finance
SC: Smart Contracts
CU: Core Unit
- Artem Gordon produced this summary.
- David Utrobin produced this summary.
- Jose Ferrari produced this summary.
- Everyone who spoke and presented on the call, listed in the headers.