00:00: Intro with Rich Brown
05:07: Governance at a Glance with LongForWisdom
09:03: MIPs Process Update with Charles St. Louis
19:42: MIP 14: Protocol DAI Transfer and MIP 13: Declarations of Intent with LongForWisdom
35:14: TUSD Collateral Onboarding with Cyrus Younessi
1:05:22: ConsolFreight and Paperchain with Lucas Vogelsang
Welcome to the May 14th edition of scientific Governance and Risk meeting, my name is Richard Brown. I am the head of Community development and also currently the only Governance Facilitator(
GF) but not for long! We'll talk about that today.
Our agenda includes a great deal to go over as we transition our world from old to new: the monetary policy from the old world and digging into
MIPs here in the new world. As we refine the process, LongForWisdom will be telling us about Governance at a Glance. A
MIPs process update with Charles and what that transition from the old world to the new world looks like. LFW will review two
MIPs he submitted. Cyrus will give us a recap from last week about TUSD. Lucas from Centrifuge will provide us with a review of their two
MIPs, one for console freight and one for paperchain. We are jam-packed today. I'm going to likely tap on people's shoulders to keep time rolling.
I forgot some of my MIPS responsibilities to take care of today. As we start to figure out what the points of order are, how to formalize this, where the speeches go, and when the gavels get banged (this is going to be somewhat shambolic so, apologies)
Today we're in week two of the
MIPs process, the light
MIPs process. As Governance Facilitator, it's my responsibility to review the inclusion polls from the previous week as a sort of "mock-UN review" of the
MIPs process, the only
MIP that we have in play is the inclusion of another governance facilitator. We had a poll to determine the community's appetite for onboarding LongForWisdom. This is an interesting poll for a few reasons.
One exciting aspect is the default inclusion threshold, which is a development we need to internalize. A certain amount of participation is required for a poll to go through. In this poll, the default threshold for a satisfactory yes, or signal that consensus was achieved, was 3k MKR. Happily, it should have ended, and good news! LFW will be officially included in this next week's Governance Poll. If you want to offer him your congratulations with a whopping 93.42% support for his ratification, please do. BUT! Someone voted 'no' with 400MKR. A few days ago, I went to the portal to signal support for Long. I thought to myself, how amusing, I was going to vote 'no' myself, just to see what would happen. But someone beat me to it. Whoever you are, you're a jerk, but there's Governance in action :smile:.
Take it away Long. You're halfway there.
@befitsandpiper discusses the advantages and disadvantages of PaxGold as collateral for MCD.
Still no collateral application from PAXG.
@latetot asks for opinions on using synthetics as collateral in the Maker Protocol; the discussion touches on Synthetix and synths in general.
Kurt gives a brief overview of the TRFM (target rate feedback mechanism) as well as the benefits and downsides of implementing it in the Maker Protocol.
Will proposes producing an initial policy document for use in case a dark-spell is necessary before Governance can determine a more durable, long term policy.
Nothing new this week
The vote concluded with a no.
Rich: Lots to debate here, so we'll carve out some time next week for this topic.
I'd like to go over the same structure as I did last week in the Governance call. Provide a little more detail on this week's activity in the current Governance cycle, what's up next week, and what we expect for the fourth week. I'll also talk about a few more updates concerning the MIPs process and collateral onboarding in general.
I'll be posting this update on the forum as a thread like I did earlier this week. Hopefully, you can get it tomorrow instead of next Monday, so people can read about it earlier on.
Earlier today, the inclusion poll for core personnel onboarding of LFW as Governance Facilitator passed. The results were 5,529MKR to 403MKR, plus the default inclusion threshold of 3k MKR. Yes, votes were higher than both, so the proposal passed.
On today's call, we'll review the results of the inclusion poll: next step is the Governance Poll that we will have next Monday. With respect to next week on Monday, we'll have the Governance polls submitted by the GF. It will run for three days. In general, the governance poll's purpose is to determine if this sub-proposal to add LFW as Governance Facilitator should proceed to the final Executive vote. Ultimately putting it up for acceptance or rejection. If it passes, it will go to the Executive Vote.
On that Thursday of next week, the GF will do another review, similar to this week. Talking about results and making sure we can proceed to the next step. We'll acknowledge that the final vote will be ready in week 4.
In terms of week 4, the executive vote will be submitted on a Monday. It will have an expiration of 4 days. Then it will have no effects. MIPS and sub proposals only move to accepted if the vote is passed within that 4-day limit. If it fails to pass in that windows, the
MIP is changed to the rejected status.
In week four, we have the Community Greenlight Poll (
CGP) to get direction about what to do next with the
MIP 6 applications that have been proposed in the Forums. The
CGP will be posted on the 4th Monday at the same time as the Executive Vote for Long's sub-proposal. It will run until Friday.
On Thursday of week four, the GFs do a Governance Cycle review for this meeting, which gives the opportunity to discuss the past Governance cycle and everything that happened throughout. As well as discuss any potential upcoming Governance cycle and submissions for the next month.
In terms of overall collateral onboarding, I'd like to reemphasize that we are in transition from the current collateral onboarding practices that we know to the
During this period, we'll use the weekly cycle format that we've been using for this month.
Given that the results of the
CGP end on week 4 of this month, May 28th, the
MIP 12 proposals with the Domain teams work for those collateral assets will likely not be ready for the June's Governance cycle. This means the Domain teams will have to determine which assets they will work on, from both the poll and their own judgment. They'll work on the deliverables over the course of June; then, the proposals will likely be ready to enter the Governance Cycle in July.
That's my update. I'll post it as a government thread in the governance category.
Rich: Thanks, Charles, for the recap. One of the main takeaways is that
MIPs will be an enormously useful tool in the arsenal. But it will take some muscle memory to get it fully internalized. So as we plow through this month looking forward to having more integrations next month. Speaking of, one of our secret champions of the
MIPs process is up next.
LFW: Before we do that, Lucas asked about when the first domain team greenlights will be published on the collateral applications. I believe the first ones have already been started, and I think Nik put something up from the oracle team. The deadline is supposed to be Friday (AKA tomorrow). Hoping to see a rush of them happen at the end.
Rich: The primary issue, and I love this since I get to do callbacks to themes in previous meetings, is the path from intention to implementation. Understanding what the
MIPs process entails, especially all of its individual pieces required in order to put them into play. Additionally, dealing with the level of work we have on our plates.
Rich: There are numerous themes. One is pure bandwidth. The
MIPs process has published a best-case scenario for the preferred path to onboard collateral types. One of the frictions that we have run into is the volume of work we encountered with onboarding these collateral types. The coordination across stakeholders and domain teams need to provide analysis for each application.
Rich: Coordinating all of that work is not an insignificant task. We're working on it internally, how to communicate it back to the
MIPs applicants, and we're not there yet. When will we be there? I'm not entirely sure yet. Hopefully, this week, or next week, and we can start digging into the application process. My expectation is that there will be some meetings involved, sort of like a Q&A session between the domain teams and the
MIPs applicants, so we can establish some baselines to understand all of the moving pieces. As an example, when we did wBTC internally, that's something potentially to be expected; it's a well-known project in the ecosystem. It still took a fantastic amount of detailed work across several departments at Maker to make that happen. I'm sorry, Lucas I'm sure that's not satisfying, but we will reach out to you to work with you and other
LFW: It's interesting that we're not talking about the greenlights here yet.
Rich: For sure, it's even more complicated. Nik is sounding off in the chat and Cyrus; maybe you can add some color to the greenlights?
Cyrus: I think that you have covered the bandwidth issue pretty well, we're trying to work through everything as fast as we can, but it's a new process. If anyone has questions, definitely reach out.
I posted a couple of
MIPs in the forum early in the week. They don't have numbers yet(now they do) because the
MIPs editor assigns the numbers.
Protocol DAI Transfer defines a process that allows Governance to transfer DAI to an Ethereum address.
There are uncomplicated requirements. There are no onerous requirements. If you can get
MIP sub proposal through this process, it will be added to an executive vote with a call to the
suck function, which allows Governance to pull Dai out of the protocol and send it to an address.
I wrote this to be a very generic low-level thing we could use, in the case where we don't have a more specific, detailed process. For example, we want to build more complex solutions in the future for treasury management and paying people. But for now, we can fall back onto this.
Questions and Comments 3
Rich: There will be questions, though I think it hasn't just set in yet. This is the first example where the community can self-fund for activities.
LFW: Eventually, yes. The idea is any reason that Dai needs to be sent; the process can be covered by this proposal.
Rich: One of the questions is guardrails: How do we protect the protocol from bad actors? What social layer would we need to vet/verify these actions or even manage those funds in transit? The questions could be endless, but the intention behind the
MIP is compelling. The Foundation's responsibility is to bootstrap the protocol. We do that in different ways; by creating reference implementations in software or by facilitating different roles in the ecosystem until they become self-sustaining. Ultimately, there's no true autonomy in that model unless empowered actors have access to their own funding sources. Having a mechanism like this in place changes the fundamental landscape of how Governance works. I encourage people to take a good look at this one.
LFW: It will be up to Governance to properly vet sub proposals. The onus is on the creator of the sub-proposal to provide a reason why their funding request is necessary.
Charles: I want to add that these proposals are very fresh, and most haven't read through them. There's no need to fully agree now; the intention is to introduce them and move the discussion to the forums. There's no need to have full commentary now.
Cryptowanderer: I have one small comment, I think is worth mentioning. An executive, already in week four, to add you as GF needing 60K MKR within four days is a steep hill to climb. We need to think about a more efficient way to deal with these "process MIPs" that don't have a codebase change and might not have to go all the way to on-chain voting to ratify. It's a complicated question, but our ratifying process for
MIPs without executive votes, so that we don't end up in a situation where an executive vote happening early in the week that will have difficulty getting passed. Ultimately I strongly encourage people to go to the forum and check the technical part particularly. Especially if "sucking" Dai from the
VAT immediately triggers
FLOP auctions. Perhaps Kurt can help because if we're sucking and initiating
FLOP auctions immediately, that could be a problem. If anyone can come up with a way of processing
MIPs without going through the executive vote, that would be golden.
LFW: This is something we have been discussing lately. We don't necessarily need an executive vote to do non-technical
MIPs. Staking MKR is slightly more durable than Polling. As written, non-technical MIPs need to go through the process, but if we do realize that this is not optimal, we might change it.
Crytowanderer: I'm in favor of it ATM, but it's part of the process we can iterate and improve on in the long term. If you submit a MIP to improve the process, not only would that be Meta, it would be appreciated.
CSL: another point to consider is that if there were two different cycles for both technical and process
MIPS, we would have to manage the additional complexity caused by the overlap between the cycles. But you are right, that a core principle about
MIPs is that you can iterate over time, making amendments to them. If there is a lot of consensus in the community about changing this "process versus technical MIPS" life-cycle, it will eventually get voted in.
Lev: I think that there is a natural or canonical turnout requirement for executive votes since you have to overcome the previous hat. You don't have this with polls, where someone needs to make an arbitrary decision for the turnout requirement to make it valid. The executive votes have this conservative quality with a very high barrier. That's important to take into account when deciding on the process. If you do create a process
MIP that goes up and passes with low turnout, someone could point to it later in the future as illegitimate. Since it could be examined as "this is ridiculous, it only had 1k MKR voting for it," or "I never even see that poll." You could not argue that you have not seen an executive vote, as you could with a poll. You're shooting yourself in the foot passing process MIPS on lower turnout Governance polls.
Kurt: That's a good point, and maybe you could go even further and say that maybe for these process
MIPS we should be, as part of the executive vote, putting a hash of the document we agreed to on-chain; so that there is an attestation on-chain.
lev: Absolutely agree about the attestation. That's currently, in my opinion, an issue with the Governance Poll process. I believe, in theory, it's possible to edit the wording of a Governance Poll. I don't know if it happened before or not. I assume that if the proposal has a typo or a small error, it could be edited. I'm not aware of a process to check the wording at vote, this is a side problem, but Kurt's suggestion is great.
Rich: There's no shortage of things on our to-do list or things we could add. But as context, our polls go into GitHub. So there is an audit trail there to avoid ninja editing. It's not the best solution and isn't very decentralized. Wish list for me: I'd prefer that this stuff go into IPFS and called directly from there. If the community would like to see that sooner rather than later, then it's something we could consider. Forum threads, perhaps? If someone wants to accelerate the process.
This is a formalization of Governance declaring the intention to do something or act in a certain way. We've seen this before, with signaling polls: the shutdown of SCD, ranked on-chain voting, compensation of vaults on BT, all have polls saying "we should do X."
It allows governance to set a bounty value on these declarations. For example, if we say we want ranked-on-chain polling, they could add, "and we're willing to pay 50,000 Dai to the group facilitating this." This
MIP is an example of a process that might use the protocol-Dai-Transfer idea. There are boilerplates of how to revoke, accept, or change these.
Rich: I can guarantee that there will be questions later. Thanks, LFW, for this proposal.
We'll be redoing last week's presentation. We'll also discuss the option for a second USDC vault type, which has been discussed on the forums for the past few weeks. Might be an additional proposal added to the TUSD proposal later this month. I'll handoff to Marko for the TUSD presentation.
Our team prepared this analysis of true USD as a potential collateral asset for MakerDAO. For comparison reasons, we used PAXOS and USDC.
There is a slightly false belief in crypto that native assets are safer in a portfolio. Yet, black swan events are still possible in crypto.
USDC-A was added as an emergency asset type to provide liquidity for auctions.
BTC halving is generally a positive event but increases uncertainty in the short-term.
I mentioned dai as a soft peg in crypto, and in the context of Stablecoins present in crypto, we have two types:
Centralized 1-to-1 backed by underlying assets. These have the ability to maintain closer to a hard peg.
Dai, which is a decentralized stablecoin backed by a surplus of underlying assets, maintains a soft peg. If there is no appetite for leverage, then there isn't as much issuance of Dai.
Stablecoin Specific risk, the probability that regulations will impact an industry or market.
A recent report by FRB indicates stablecoin risk, which is market-wide and not asset-specific risk.
USDC Marketcap is dominating the space between each of the three assets.
PAX has a consistently declining trend since 2018.
Both PAX and USDC increased quite rapidly during BT while TUSD did not show an equal pattern, demonstrating that in times of great demand for stablecoins, only a few thought of TUSD compared to these other options.
Considering markets in which we trust. Binance, Coinbase, and OKEX. USDC dominates trading volume over time. PAX is losing market share but still hanging on while TUSD is losing market share.
Same data in absolute numbers. We can see USDC very strong, TUSD not very strong.
This is a comparison of trading volume on Ethereum layer trading venues.
USDC is definitely dominant in these protocols. TUSD has a presence, which is good, but the numbers are much lower. PAX is also present, but less than TUSD. In the last week, Curve Protocol added PAX.
What is a bit worrying about PAX is that trade volume in Uniswap is so low. Uniswap's a fundamental venue for trading in the space and indicates that PAX's low trading volume is an issue.
Present in Aave and Nuo. For Nuo, not sure what is going on. On Aaavea, there is a bit more aggressive strategy than Compound. Nuo has a higher risk tolerance for collateral assets. Out of the 900k deposited in Aave, about 75% is deposited due to curve protocol. Curve protocol is a bit sophisticated, which indicates that only about 200k is deposited in Aave from everyday users who want stablecoin yield.
Same data presented as a market share. PAX is not included because it is not in those protocols.
Well, known labeled addresses in Etherscan. USDC is dominating. PAX is present in some decentralized venues and also has larger balances than true USD. TUSD not present in many such venues.
In this comparison, we looked at Holder addresses labeled on Etherscan.
Metric shows how many holders/transfers added on average per day. USDC has the highest growth rate, PAX is also growing, while TUSD is definitely much lower than both of them.
Transaction count per day overtime. Borrowed from Token Analyst.
TUSD (in purple) is not as active on-chain as some other of these coins are.
Positive potential for risk diversification. Regulatory risk is marketwide and, thus, undiversifiable.
Small potential for Dai minting, due to low usage and transaction of TUSD.
Supply did not increase relative to other large stablecoins on Black Thursday.
TUSD has a declining trend since the end of 2018, which is the most important metric for a centralized stablecoin.
Cyrus Younessi: Thanks for that awesome presentation. I'll post in the chat the link to the forum and the proposed risk parameters. We can open it up for questions or discussion. Proposed risk parameters: Stability Fee 0%, Debt Ceiling 2 million, Liquidation Ratio 120%.
I think the most fruitful discussion would be about the debt ceiling and its relation to other stablecoins in the system. Right now, the USDC debt ceiling is 20 million, and the idea is that we could put a cap on this class of stablecoins. If we were trying to put USDC in with a, say, 2 million dollar debt ceiling, then we can consider reducing USDC as well. Additionally, I'd like to tie into the conversation a USDC-B vault for emergency liquidity purposes for auctions. I know this is a lot to take in, so I'm happy to continue this in the forums as well.
Chris Padovano: Wasn't the recommendation that TUSD provides little diversification in terms of regulatory risk. It doesn't seem like anyone is going to mint Dai. Maybe there are better-centralized stablecoins that Governance should be focusing on, that people could be more excited amount?`
Cyrus Younessi: When we put proposals for parameters, governance is welcome to vote against it. I think we have reflected that lack of interest with a fairly low debt ceiling. I think 2 million is the lowest that has ever been proposed for a collateral type, almost like a bare minimum. If even that is too high, we should discuss this.
Chris Padovano: I thought this was a great presentation that showed that TUSD is fighting such an uphill battle. I was also surprised that PAX was around for so long. If we are going to pick another centralized stablecoin
CY: you could also use the wrapped bitcoin argument that maybe activity could pick up after addition to the protocol.
CP: With wrapped BTC, that actually did happen. Someone went out and minted a thousand wrapped BTC, and wrapped BTC is kind of a newer idea. I think we should focus on governance fatigue. We should really be making our shots count. Especially when we're talking about adding new collateral types that we are excited about. Your pitch really persuaded me, this doesn't seem, like no one seems excited about this I want to take the other side. I don't know.
SamM: Does it have to be either-or? Can't we just bring as much collateral as possible as long as it's not a complete scam, and control our exposure based on the debt ceiling?
CY: Exactly. And to be clear, I don't think that Marko or anyone from the risk team is trying to project an image of excitement or else. That is for Governance to decide. From the risk standpoint, I would be interested to hear if an even lower debt ceiling would make sense. At that point, I would say, "probably not." I think the primary argument that Chris is making is about adding to governance overhead. But I don't see how that's something that we can deal with at this time. But I don't see how that's something that we can deal with at this time, because the intention is that plenty more collateral will be coming through the system. It almost makes sense to learn how to deal with that sooner rather than later.
CP: Right, exactly. That's totally fair.
CY: If there comes a time when there's like 30 collateral types in the system will require some reworking on how we manage the portfolio. It's better to see that now with easy collateral types.
CP: Of course, yea, so I'm persuaded.
RB: I'm trying to stay aware of the time. We have a lot to go through, so Cyrus, can we please turn over to Lucas?
Cyrus Younessi: Yes. Please, let's continue this discussion either over forums or in the chat.
I'll address a big topic which is introducing real-world assets to
MCD. Given the time, I'll brush over a lot of things and set the frame for a conversation, and hopefully, we can turn it into more of a discussion. Please refer to community calls, and forum threads, regarding the details about some of the technical aspects. I'll share more information later as well. Nevertheless, I think I need to give a little bit of background on what Centrigue is and what we do.
Centrifuge does decentralized asset finance for what some people call "real-world assets." Allowing businesses to use real-world assets, such as invoices, (extended to real-estate or anything that you can borrow against). We enable asset originators who have these assets to tokenize them, bring them on-chain, and pool these portfolios of individual loans and issue an ERC20 token that allows investors to invest in these pools.
We have two asset originators in the
MIP 6 proposal process:
Paperchain, best described as a streaming revenue analytics company that allows music labels to see how their music is performing on the different streaming platforms, such as Spotify, Apple Music, Google, and so on. As part of their business, they want to offer these music companies/labels/artists the opportunity to advance part of the cash flow they're going to collect. So, you have an invoice where Spotify tells you that they will pay you a given amount in 60 days for your music. You want to go to a bank and borrow money on that invoice; this is typically called factoring.
ConsolFreight is a freight software technology provider that helps freight forwarders to break up shipments and coordinate shipping goods across the world. They have invoices by shippers from distributors, like supermarkets, that use them to organize their deliveries. The assets they are interested in bringing into
MCD as collateral are these freight invoices. Regarding what stage they are at, ConsolFreight created its first securitization and initial 49 loans worth a total of 278,000 Dai and sold those to 10 different investors that now own an ERC20 token that is generating a yield on these invoices. As these invoices are paid back, the DROP token holders, as they call them, can redeem their token for Dai, which is principal plus interest.
Most abstractly, you can think of this system as individual loans that are represented by nonfungible tokens. We do not just issue one ERC20, but we also use what structured finance calls senior and junior tranches, where the DROP token is insured by the TIN token, meaning that you have two classes of investors. The TIN token investors get a potentially larger upside but take any losses first. The DROP token holders get a fixed interest lower rate and are insured by any losses based on TIN token percentage investment.
What we did with ConsolFreight, they had 278,000 Dai in loans. Of that, TIN tokens holders invested 28,000 Dai and Drop token holders invested the remaining 250,00 Dai. As long as the portfolio of invoices returns 250k + interest in Dai, Drop token holders will not see a loss. If they return 260,000, it means that the TIN token holders will face a significant loss. If they return anything more than the original investment, after the DROP token holders have been paid out, the TIN token holders get to see any money.
Why do this? The reason for having two different tokens is to have an asset that is much more stable and has some sort of insurance, which is the liquid and much more stable asset, the DROP token. The TIN token, or underwriter token, is the token the originator uses to have skin in the game.
In the instance of ConsolFreight, the TIN tokens are 50/50 Centrifuge and ConsolFreight itself, putting a small stake, guaranteeing the performance of this portfolio of loans.
Is this structure normal for receivables financing? The split structure is definitely used in all sorts of debt financing, even other kinds of financing. I think it makes sense for Maker and lenders that want to have a very stable asset. As an investor, you can now change your risk assessment from an individual asset in the portfolio going bankrupt or being at a loss and losing that fraction of the portfolio to a pool of assets and the losses surpassing what the TIN token holders have invested. So a Drop token holder, I have a much lower risk. That's how Centrifuge assets work.
I would like to talk in general about how real-world assets behave as collateral in Maker. I think it requires a lot of rethinking, and I had way too little time to highlight many of the points in detail.
I'll start with the positive things: ConsolFreight or Paperchain have a known demand for capital. We just talked about how much TUSD or BAT is used to generate Dai. It's a very different use case for me as a BAT token holder for me to say: I want to margin trade or use that BAT as collateral to get some security or get some safety by borrowing Dai. The difference is that an asset originator will go to the market, sell the Dai, give the Fiat to freight forwarders or to the music labels, and then use that as one of their main source of capital.
Another thing is that in the current market climate, a lot of these crypto-assets right now are not generating a lot of yields. These DROP tokens can generate yield because these are real loans to real businesses that have the cost of capital if they go into traditional financial markets, and we can capture that in the DeFi ecosystem instead.
One other thing that is oftentimes criticized when looking at real-world assets in Maker is that all of these assets are not truly decentralized. They aren't, and they rely on a legal framework. But one opportunity that we have here is that if we diversify and start onboarding different kinds of real-world assets with different kinds of originators and different legal restrictions, that is something that can add to the diversity of the portfolio and make Maker a more secure system.
One of the key questions we have to ask is, "is MCD the primary or secondary market for these assets?" With Paperchain, and ConsolFreight, directly petitioning the Maker community for inclusion of the assets, Maker has the chance to be the primary lender. Meaning that the asset originator deposits DROP as collateral and gets Dai directly from the Maker Protocol. For that to work, however, we must understand that in supply chain finance, you very often see advance rates of 90% or even 95%. What that means for Maker is we have to start being much more comfortable with pricing assets and giving it risk parameters that reflect this and can compete with this real-world asset class.
Another thing of what Centrifuge has focused on, when thinking about these real-world assets, is short-term debt. That means trade finance assets are a really interesting category because if you have a loan that's due in 120 days, it's much easier to price it just because the macro-economic circumstances don't change quite as much over those 120 days. You have a much higher turnover, and you have faster feedback to see how this works. What this still means is that these assets, by crypto standards, very illiquid. There is no instant market for freight invoices that we can tap into and use as price oracles. The credit industry in the traditional financial world use pricing models that factor in credit risk by different lenders and arrive at a net asset value of a portfolio that doesn't rely on price discovery in the market but rather an agreed-upon model. As the Maker community, we have to start thinking if that is something that we want to incorporate, or do we want to insist on there being a market? How do we feed prices to oracles when we know that the price of an invoice doesn't change for the most part of the time it is active? Maybe it changes once it goes into default?
Lastly, keepers are something that I want to start discussing. The kind of keepers that will have to be brought into MCD are different. They exist in the real world: they are distressed debt buyers that specialize in buying under-performing pools of loans. Different collection agencies buy individual assets. We'll have to bring those entities to the table and start including them in these discussions that we're having. I want to start a dialogue around these topics. We've been hosting calls that we open up with whoever wants to discuss. We can form working groups. I'm open to working with Domain teams. I would open it up for questions, but I don't know how much time we have left.
Lucas Vogelsang: Centrifuge has been hosting their own calls. We sometimes announce on the Maker forum, and we have done what we call an "Open Collateral Onboarding Call" that we plan on doing every two weeks. The last one happened last Wednesday; I think we'll do another one this coming Wednesday. Happy to take the conversation there if people are interested.
Lucas Vogelsang: the question I would like to get feedback on is, "Do you think that Maker should offer a lending product? Should MCD be the primary lender for these assets? That is a question that will come up, because asset originators will want to borrow directly, and Maker has a very interesting proposition for them. They can borrow instant money with a flexibility that you can't find anywhere in the traditional financial ecosystem. But if you start opening up to real-world assets, you cannot just rely on a price feed that comes from a couple of exchanges anymore for telling
MCD how to treat these vaults.
Helge Qvan: I usually go by the name PlanetX. Your proposal is fantastically interesting. I do struggle a bit with the pricing of the collateral. I know you have said that this is very stable collateral, but we have to know how to sell this if the vault ever goes under. As far as I understand, you rely on the manual evaluation of the collateral. Is that correct?
LV: When you think about our ERC20 tokens, they're a fraction of a portfolio of loans. These loans are legal documents that we bring on-chain as NFTs priced and underwritten by as many diversified oracles or attesters as you can think of. So this NFT might be attested by a financial auditing firm to say that the paperwork is correct. You could try to get a fraud scoring company to rate the likelihood of fraud on that counterparty. If there's credit scoring information on these different assets, you could read out what the score is this individual lender. This will give you a risk rating on the particular asset. Which Tinlake, our contracts, will use to determine what the interest rate and the advance rate for this asset is. So at that point, we have a price for this asset. Then we calculate the NAV of the portfolio, which looks at these invoices, calculates the expected cash flows and the probability of default, and comes up with a number of what this asset should be valued at in the book. This is no different from what a credit fund would do today to assess its own portfolio. We're giving this price to DROP and TIN investors to invest in these pools. That is what we would want to try to put that value of the DROP into MCD.
PlanetX: so far, I'm with you. Could you explain what Maker will need to do to sell collateral?
LV: Keepers will have to bid on it, that's no different.
PlanetX: So, this would need to be a manual process?
Lucas: No, it wouldn't. There should be different keepers because you're not a keeper that wants to buy ETH and sell it on the next exchange for a small gain. You will obtain security that is a fraction of a set of invoices.
PlanetX: For crypto purposes, this market needs to be set up from scratch?
LV: Yes, the appropriate parties would require onboarding. We had these first investors invest in DROP that ConsolFreight issued. Anyone could bid on them. There would be some small differences with your average keeper since it moves much slower. Maybe a 6-hour auction window would not be enough, but at the same time, they're a lot more stable.
LFW: Regarding the vaults, is Centrifuge going to make one giant vault or lots of different vaults? If we have to liquidate, would it be one giant vault or several vaults? And the general case seems to be that the Drop token shouldn't take large hits. What incentives are going to be for keepers to stay around in the general case?
LV: Your comment in the chat, you said, "I think this is more like warehouse financing than margin lending; there are differences in how Maker would need to handle it. I think the theme is an interesting one. To get back to what you were saying, "Is Maker in the secondary or primary market?" I think the opportunity to offer a credit product to these asset originators in the primary market is exciting. But that does mean that yes, the asset originator will create one giant vault for the category of DROP and collateralize that with their DROP and then start drawing Dai from it. There wouldn't be different vault holders that use different collateralization ratios that might get liquidated at different times. The entire asset pool would behave very similarly. You could look at it as one position on the balance sheet or one item of collateral. It should be much more stable. The price would be slower moving. You would not have these movements of what we've seen today, with ETH margin trading. As long as these assets are performing as expected, liquidation should be an improbable scenario. Just to give you an idea, in B2B invoice spend, the default rate of these assets, depending on the industry, is less than 1%. If you look at credit funds for factoring, they have a fraud risk that's probably the biggest, but these assets rarely have these crashes that we see in crypto. The question on how do we get keepers to stick around, we need to integrate everyone and make them familiar with the system and move slowly.
LFW: My question was more: is there one big vault and one day everything falls apart, or have several ones that are being liquidated. If there's only one vault where it's all or nothing, would keepers stick around in the chance that everything falls apart one day? With the current system, you have different vaults with different liquidation ratios. With this, you're asking people to stick around for this 1 in 100 cases.
LV: Well, you would have a few days to liquidate this portfolio, not minutes. Keepers have a different kind of time span that they're working on. They are not trying to offload your asset as soon as possible in the next exchange to get more liquidity.
LFW: So we would be in a situation where we want something like a 20-day liquidation process where you source keepers where they get liquidated?
LV: I think that might make a lot of sense.
CP: Or you could put the obligation on the issuer to contract keepers to liquidate their collateral. There's a lot of contracts flying around, right? That could just be seen as an obligation for real-world asset collateral. One of the burdens of proof should be, "we're going to make sure that there are people around to buy this ship when it goes underwater."
Guilherme Remor: In terms of these initial businesses, Paperchain and ConsolFreight? How old are they?
LV: I think Alejandro is on the call, maybe you can talk about ConsolFreight. PaperChain has been there for over a year now. Actually, the Maker Foundation did a first pilot transaction where we went through this entire process of bringing an asset on-chain, securitizing the collateral, and selling it. At that point,
MCD wasn't live yet, and none of this was done in MakerDAO. But we went through this legal side and part of the on-chain. I think this was last August if I remember correctly. PaperChain has been around for one and a half years.
GR: And I imagine that over that time for the business to be maintained, they have built some history with other lenders?
LV: I think Paperchain and ConsolFreight both want to use Maker as one of their first backers. ConsolFreight has gone live last week with its first set of assets. Paperchain has a track record of working with labels offering them analytics products but does not provide financial products outside of it.
Alejandro Gutierrez (ConsolFreight): We're a company established in 2016, started in logistics and moved into supply chain finance. We have been exploring other avenues to get funding. We have explored similar possibilities with some American companies before the COVID19 situation, but our eyes are now focused on the crypto space and especially with Maker.
LV: I want to emphasize what Kurt just said "that collateral can be anything that has value. I think the real dichotomy is commodity-backed versus debt-backed and how we see Maker's place in financing these assets." We're able to cut out a slew of intermediaries and established parties in the financial system that we see today by being a primary purchaser of debt if you want to call it that or compare to that. I think that's the opportunity we have to generate an interesting yield on relatively stable assets. There are definitely downsides that come from not just working with highly liquid assets. The upside is that we have yield and a whole set of US dollar stable assets that can bring stability to the system at times where crypto is not stable and sort of balance things out.
GR: Because of the nature of the issuance of short-term debt as you're mentioning, are you mostly thinking about use cases involving short-maturity trade financing through factoring or any other use cases that we should be considering.
LV: In the current economic climate, we want to focus on safer bets that are easier to price. One of the advantages of focusing on trade finance assets is that this is money that has been already spent by the business, it's just waiting for payment. Of course, this money is used to grow the business, but you're not borrowing against the expectation that the company will have long-term success and growth in revenue.
GR: And in terms of maturity that you would issue, you don't expect long timelines? As far as I currently see in the risk parameters we now have in the Maker ecosystem. Usually, there's no maturity to the debt that we have in the ecosystem, so that would be a change as well.
LV: We're reaching the time limit, Charles is asking to move this to the mips channel on RocketChat. We are going to have a call next Wednesday, at 19:30 European time, that's 10:30 Pacific time and 17:30 UTC where we can discuss this as well. Also a discussion on the
MIPs proposals. I'll post the slides and some of the links in the RocketChat governance channel. Thanks for the time.
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
GC: Governance Cycle
GF: Governance Facilitator
CGP: Community Greenlight Poll
SF: Stability Fee
DSR: Dai Savings Rate
Tim Black produced this summary.
David Utrobin produced this summary.
Igor Teslya produced this summary.
Juan Guillen produced this summary.
Everyone who spoke and presented on the call (listed in the headers.)