---
tags: Issue Discussion Call
---

# Issue Discussion Call #03: MKR Burner and the Surplus Buffer

## Agenda

- [00:00](https://youtu.be/Lo7SlztoH6w): General Introduction with Thomas Flitter
- [03:40](https://youtu.be/Lo7SlztoH6w?t=220): MKR Burner
- [22:59](https://youtu.be/Lo7SlztoH6w?t=1379): Surplus Buffer

## Video

<https://youtu.be/Lo7SlztoH6w>

## General Introduction

### Thomas Flitter

[00:00](https://youtu.be/Lo7SlztoH6w)

- Good day, everyone. Thank you for joining us. Welcome to the Issue Discussion episode #3 of MKR Burn and Surplus Buffer. My name is Thomas Flitter. The engagement lead for the GovComm team. I am joined with David, Artem, and many of you with whom I have read, discussed, chatted, and talked about some of these topics. I hope for a lively conversation today. As we progress through the presentation, please raise your hand or comment in the chat function that David is helping monitor. We will answer your questions. Towards the end, we can open discussion about any comments, feedback, or questions. This session is being recorded. Just as a disclaimer, this is provided for information purposes only. The views and opinions expressed in this meeting are those of the people involved and do not reflect the official policy or position of MakerDAO, its contributors, CUs, or affiliates. This communication makes no representation about the enduring accuracy of the information and appropriateness for a given situation. The content is provided for information purposes only and should not be relied upon as legal, business, investment, financial, or tax advice. Consult your advisors for those matters, references to any digital assets, the use of finance-related terminology, or for illustrative purposes only and do not constitute any recommendation for any action or an offer to provide investment financial other advisory services.
- Hopefully, everyone can view the slides. We will overview and talk about Maker Burn and Surplus Buffer. I want to go on to talk about our agenda. It is my first Issue Discussion call and our third one in line.

## MKR Burner

[02:44](https://youtu.be/Lo7SlztoH6w?t=164)

- We have done our welcomes and introductions. Our topics today are Maker Burn and Surplus Buffer. We will have an open discussion and talk about any questions you may have. Then we will wrap up talking about shaping the future topics for discussion. Today's topics were derived based upon a lot of the activity through the forum and discussions. It is a relevant topic to talk about as they are informed polls, voting. We hope to develop some good suggestions, maybe recommendations about these topics.
- Let us start with Maker Burn. Many discussions and opinions have been about burning Maker and increasing the Surplus Buffer. When we look at Maker is, and I have had to teach myself being new to the company, we realize over 900,000 Maker tokens are in public circulation. It's an ERC 20 token is native to the Maker protocol. It is a governance token and recapitalization source for the Maker protocol. As a governance token, Maker is used by its holders to vote on many different things, which I found very interesting. Voting is used to execute changes to parameters inside the Maker protocol like stability fees, DSR, DC, and many others. Voting is also used to make decisions on the non-technical aspects of the protocol, like asset priority list, government processes, role mandates, and even electing individuals to fill specific roles. The MKR or Maker token is the source of recapitalization; when the Maker protocol runs at a deficit, Maker is issued and auctioned to cover it. It was launched with one million Maker tokens at its inception. That is an interesting number. The possibility of the Maker token supply dilution gives holders a strong incentive to govern the system well. There are responsibilities of the holders. Their primary responsibility is to ensure the Dai peg's stability, making the Maker token interesting. The overall health of the Maker protocol is that the holders' interest is to focus on improving growing the Maker protocol by building out the governance processes and infrastructure. We have to ask ourselves, what would incentivize us? What would incentivize those drivers to want to burn Maker tokens? We have to look at what is the current state of the burn. When we are doing research, what is your policy? What is your procedure? Moreover, understanding there is no standard procedure or policy, correct me if I am wrong. We make a manual adjustment. It ties with our second portion today, the Surplus Buffer. The buffer and the burn have been adjusted manually. Looking at many discussions on the forum and some signal requests, many delegates, contributors, and folks are asking, what is appropriate? Where do we need to take this? That is part of what our discussion will be today. To take a look at, where are we right now? We have done these manual processes. Is it more towards an automated process? Is it something that we can come along with and bring some ideas that maybe we want to move forward during this discussion session? I wanted to get everybody's thoughts and opinions.
- Is there anything else you would like to add to this very beginning section before we talk about the driving forces of burning and not burning Maker token?

[8:02 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=482)

- I want to emphasize the connection between the Surplus Buffer and the MKR Burn. You talked about whether or not the Maker protocol has a standard policy for burning. The burn functionality is codified in the smart contracts where the Surplus Buffer has a certain limit. When it passes that limit, it begins to auction off that excess Dai for MKR that is then burned. The way we manage the Surplus Buffer and that little functionality is directly linked to managing the burn. It does not have to be, but that is a conversation for later.

[8:55 - Thomas Flitter](https://youtu.be/Lo7SlztoH6w?t=535)

- The next little piece that I want to talk about is: what are some of the incentives, what are the driving forces? We discussed looking at the Surplus Buffer, but Maker functions as a capital recapitalization source for the protocol. It acts as collateral of last resort to absorb losses beyond the expected losses from a collateral lot in vaults. If burn happens, Maker value is believed to be propped up, and therefore, Maker is a more reliable recapitalization source. These are what a community is laid out. We have pulled this information from multiple sources like forum chats and informal polls. Burning Maker increases proportional ownership for his existing holders. It also adds Dai liquidity into the market. It also creates demand for Maker on the market. If we think about all these different points, a lot can be out there to incentivize or drive burning Maker. But it also can be an efficient way to reward holders, compared to dividends. It is one way to take a look at it, but another one is that it is believed to increase Maker value. Please chime in and provide some feedback for any of these points that I am making.

[11:08 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=668)

- Some of those points that you bring up are incentives for burning MKR. Burning MKR is believed to prop up the value. If the market cap is bigger, it is a better recapitalization source. It is believed to add more Dai liquidity to the market, which it does. 30,000 Dai at a time. But it is marginal compared to the big thing. It is good PR because of all those other supporting points. I am curious, what are the incentives or the reasons people laid out for not burning MKR?

[11:51 - Thomas Flitter](https://youtu.be/Lo7SlztoH6w?t=711)

- On the flip side, it can be bad PR. People would see the activity, see what is going on. If you are not burning it, what is going on? If we stop it completely, the community treats it like the protocol fails. Also, they are building up our Surplus Buffer, which may be more valuable. But from a risk perspective, too, burning Maker is less efficient than building up a capital buffer or Surplus Buffer, and Dai. So point-counterpoint, are you saying, and at least from the engagement standpoint, that it is bad PR people see what we are doing. We are not burning Maker. What are we doing in lieu of that? Any other thoughts about what an incentive could be for not burning Maker?

[12:53 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=773)

- I would love to hear your perspective on the whole capital battery and burn versus Surplus Buffer, Rema.

[13:07 - (Damma?)](https://youtu.be/Lo7SlztoH6w?t=787)

- I have different points to think that Surplus Buffer is better higher than lower. First, I would explain the primary function I represent here, the risk point of view. As Maker protocol will grow in time, so will issue debt and and collateralizing this debt. It is natural to expect that as protocol grows, so must the Surplus Buffer. The main reason is that the primary function of Surplus Buffer is to offset any potential bad debt. As we have more debt issued from volatile assets, which can produce bad debt, it is natural to expect Surplus Buffer to grow. In the risk team, we like to think about this like it is not a fixed value or a fixed percentage, but for example, based on the current state of Maker vaults and market conditions in regards to different collateral assets, we believe that the safe way to play this out would be to keep the Surplus Buffer somewhere around two to three, or more percent relative to the volatile debt. If we currently have about five billion debt from volatile assets, we would get roughly 150 million Dai in Surplus Buffer. It is strictly from the risk point of view. I also have some opinions regarding the efficiency of both surplus and debt auctions. You mentioned that people might say that if we are not burning Maker, the protocol is not producing value. I would argue that this is not the case because every Maker token holder can see that Surplus Buffer increases. We are producing positive cash flow. Then is a business decision, what will we do with this surplus? We can either pay out dividends, like in the traditional sense, or further invest in the protocol and increase its growth.
- When I mentioned the growth and how I see the potential growth from strictly higher Surplus Buffer than lower Surplus Buffer, there are three points. The first one is that, with a higher Surplus Buffer relative to the volatile debt in the system, the whole system and Dai, which I believe Dai holders are the core product of the whole system, are safer. If we have a safer Dai, it is much easier to sell somebody the idea to start using Dai or integrate it in their protocol or something like this. The second point about growth, which I think is relevant, is that when we add new systems or modules into the protocol, for example, as the recent Dai Direct Deposit Module in Ave, all of these things are, to some extent, experimental. If we have a higher Surplus Buffer, we can say that we can increase the DC in this module. If the Surplus Buffer is low, we are restricted on how aggressive we can be with these new modules. And then the third argument is that we can afford higher spending. We can invest more in people and different CUs. For example, we still do not have the marketing CU, which is important. If we have a higher buffer, we can afford to spend more.

[18:17 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=1097)

- Does that mean we can have more leeway to work with risk-related parameters for vaults with a higher buffer? Can we systematically do lower stability fees or indirectly related stuff like that if we have a bigger buffer?

[18:40 - (Ramma?)](https://youtu.be/Lo7SlztoH6w?t=1120)

- What would come to mind is that we can afford higher debt ceilings for some collateral assets, which are highly collateralized, but at the same time have thin market liquidity. For example, one of such collateral types is MANA. There is some interest in increasing the DC, but at the same time, the liquidity is relatively low. Currently, the situation with MANA is that all vaults in the system are highly collateralized because the price increased high. It still does not mean that somebody will issue debt, which has a low collateral issue. At the same time, we can say the current state is quite safe, but we do not know what future or new Dai issued and what kind of collaterallization it will have. It is fair to say that we can also have more loose parameters in different worlds like DC or CU stability fees with a higher Surplus Buffer.

[20:00 - Someone](https://youtu.be/Lo7SlztoH6w?t=1200)

- That is a great point. As the engagement lead and what we are working on, a lot of the information for stakeholder communications, we see a big growth going on, new CUs coming on, and that is exciting. You made a good point about the growth aspect. That is great feedback. Thank you very much for providing us with that insight.
- At last, we may have already addressed this, but is there a longer-term solution as an automated burning strategy? We talked about driving forces for and against, but this is manual. Surplus Buffer has an impact on the Maker burn. What about a longer-term solution?

[21:24 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=1284)

- I think Tim would like to post less signal requests about this.

[21:30 - UltraSchuppi](https://youtu.be/Lo7SlztoH6w?t=1289)

- It is quite a long list of signal requests. However, I can post them here. Technically we are on the level that the Surplus Buffer needs to be in relation to the amount of Dai from volatile essence. I think that is something we can agree on.
- David Utrobin: Is that around 2%?
- It is primarily a risk thing. I put up a pre-MIP. I am coming up with an Instant Access Module to avoid this governance overhead. So we do not have to vote on increasing it again manually. So we have it in relation to the amount of Dai that we have in the system. That could be a solution to how to move this forward. Looking back at how we are dealing with DC for ilks, it is the same, and we did that manually. At some point in time, we decided to go with an Instant Access Module, and we can apply the same mechanics.

## Surplus Buffer

[22:38 - Thomas Flitter](https://youtu.be/Lo7SlztoH6w?t=1358)

- I think that would be great. Segway into our second piece, which will focus on Surplus Buffer. What is the Surplus Buffer? What is this that we are talking about here? I will give a little background: the Surplus Buffer is a parameter that controls the maximum amount of Dai that can accrue to the protocol from stability fee revenue prior to a flap auction being triggered. As the stability fee comes in, the total amount of Dai inside the System Surplus increases until it reaches System Surplus Buffer and Surplus Lot Size. At that point, if a flap auction can be triggered, Dai is auctioned off for Maker. This purchase Maker is then burned. Also, the Maker protocol only has one Surplus Buffer. The stability fees from all vaults accrue to it. There has been much talk, much stuff going on for increasing the Surplus Buffer. Tim, thank you again for joining us. We have seen many signal requests. By the way, some of these links for the signal requests are in our call notes. Part of our research we pull from the forum, from the polls. It shows you some of the latest activity, especially with a Surplus Buffer which has just passed with the 90 million ceiling. We will get more into that, but for reference, I wanted to let you know that we have got those links to show that activity in those call notes. The Maker protocol has one Surplus Buffer. The current state of the Surplus Buffer, where are we at right now? As with Maker burn, very similar; it is manual. We come up with a signal request and ideas to push it forward. That is the latest that we have. But it is not, to the point of like the burn Maker, an automated process. It is coming up. We believe that this is the right thing to do. And Tim, you were talking about pushing the signal, the bot, the pole. David, did you want to add some more to that process or make a comment?

[25:43 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=1543)

- The Surplus Buffer's current state, making larger adjustments, is manual. But something interesting is that we do lerp any changes, although we have just set it from 60 million to 90 million. It is semi-automated because the way it currently works is that throughout the following X amount of days, every single day, the threshold will be adjusted, little by little. What is interesting about this solution is that it allows for burn to happen still. If the system makes more revenue than the rate at which these little bumps occur, you could raise the buffer by $100,000, but that day, the protocol could have earned $200,000. So you have this nice effect of hitting both birds with that stone of revenue. You get a bit of burn and save a little money as a protocol. I wanted to make that point that it is semi-automated, but the manual process is more of us deciding in governance, in the forums, spending our time thinking when the next one is. What is the size of the next increase? One big goal of the community, implied by the frustration that I read in the forums, is how do we make this not take up our time? How do we tie it to something, a metric that is a little bit more automatic, like that 2% figure that Rema mentioned? How do we go from there? At the moment, the bigger adjustment, 60 to 90, was a manual governance process that had to happen.

[27:43 - Thomas Flitter](https://youtu.be/Lo7SlztoH6w?t=1663)

- Just for point of reference, the buffer safeguards against high-risk events. The buffer was intended to do that.

[27:58 - David Utrobin](https://youtu.be/Lo7SlztoH6w?t=1678)

- Thomas, can I share a real-life story about when this came into play? As many of you know, and maybe some of you who are newer to the community do not. The Maker protocol went through quite the battle test, back when COVID first started hitting, when the markets got hit by COVID in March of 2020. There was a famous day called Black Thursday, in which the protocols suffered something like exploitation that involved the liquidation system of the protocol, where a bidder, essentially because of the gas environment, and everything, and there was only a single bidder, who was able to bid on liquidations that were happening at Maker, and they were bidding close to zero. They won something like $8 million worth of Ethereum at that base price (today's prices are probably ten times more than that). And the protocol, as a result, was not able to raise the money that it was supposed to raise from the liquidations to cover the bad debt that it was liquidating. We saw the Surplus Buffer go from positive 7 million at the time to negative 7 or 8 million. I forgot exactly the numbers, so take that with a grain of salt. However, as a result, the protocol did these not surplus auctions but debt auctions where MKR was minted for the first time. Previously, there was even less MKR. There was like 980k. But then Black Thursday happened, and an additional 15 000 MKR was minted and auctioned to cover the bad debt of the protocol. It happened. The system was battle-tested, and we lived to fight another day. The liquidation system was upgraded, and that scenario cannot happen if it would replay today. Ultimately, it shows how cool Maker concerns anti-fragility. I just wanted to share that real-life story of the Surplus Buffer burn and this whole mechanic that we are talking about in action.

[30:39 - UltraSchuppi](https://youtu.be/Lo7SlztoH6w?t=1839)

- UltraSchuppi: Just two things. Of course, liquidations 2.0 is a lot better than the one we had on this particular day. I'm confident that we are not going to see the situation again. However, it could turn out that at some point in time, we have such a significant market downturn that the liquidations will run at a loss for the protocol, and this is where the system surplus is for all the surplus profits. This is still something valuable in this situation.
- Just one addition to loading up the surplus buffer guarantees that the surplus buffer is increasing by the rate we are putting it into that. This does not guarantee how much we will put into incurring burning. If we face a large liquidation wave that is running goods for the protocol, or the liquidation penalties, turned into the system surplus as well, resulting in an over-spill over the social surplus buffer.
- We are going to have a lot more burning. With the current price point of Mkr, I will probably be happy if this is going to happen. Sometimes I think when was it, I think on Wednesday, we had something like; I don't know, a couple of millions of extra income.
- By the time we were already looking at the surplus buffer, many of us said that this would be an excellent opportunity to get ahead of our initial plan instead of burning. It's still quite a bit. I think it's still flaky the system we have right now. I think it's good from an overhead governance perspective. Because I mean, we have essentially six months now to make up a plan for proceeding because we are loading up over for two weeks. We will end up in the same situation at some point in time. Anyway.
- PRose11: It makes sense. The only part I wanted to add was this connection to expenses. It's not just for risk events. When we decide to fund something in the protocol, and if it's available in the surplus buffer, that will take the hit for us. A great example of this is the Oracles latest budget asking for 8 million. That simple expense would issue new MKR and sell if the surplus buffer is below that. That's a significant side too.

[33:34](https://youtu.be/Lo7SlztoH6w?t=2014)

- Thomas: I want to say something about this surplus buffer LARPing where I see that this can be problematic. If we have a situation where a lot of basically surplus increases come from the liquidation penalty, we will quickly result in a lot of surplus auctions. I think this is not something we want to see because if we have a lot of surplus auctions at once, blockchain, high gas fees, it can happen that some keepers will not be able to participate or something like this, and we can end up with something like really low bids for Dai. I don't know how complex this is technically, but the potential solution is that proceeds from the liquidation penalty would be storing it in a different account; we will avoid the sudden increase of the surplus buffer.
- David: I think that feeds into LongForWisdom's old idea of a surplus buffer distributor module where it's not just one big pool of capital are being relied upon for all of these different concerns. Then you could separate the concerns; your risk buffer acts as an actual risk buffer. Then, your protocol expense is kept on the side protected, etc.
- UltraSchuppi: The most sustainable solution to the situation that we have essentially not good running auctions on Mkr is not redistributing the liquidation penalty is to something different because it's good that people are on. Finally, come up with a liquidation 2.0 approach called the Clapper. That would be a lot better because this would have the same effect as we're having with both liquidations they were running that one year ago or two years ago. The same will probably happen with Mkr options as well. That's at least my bid.
- Unknown: I just wanted to sort two plus one, the flapper distributor idea. I think one of the more significant concerns for the surplus buffer is that it's one big pool, right? Whereas I mean, now granted, there isn't like a DAO model of this. In a traditional company, like you'd say that you separate your profits into which investments you'll use for cogs, etc. There have been chats about it, but it's more important now that we think through the protocol's mechanisms we want to prioritize. To other delegates, Tim's point, getting moved to liquidations, Gonzalo already has code for Clapper, which we posted somewhere on the forums; it's definitely on Discord would be one of the more important things to prioritize. We should start to signal out some plans to upgrade the surplus buffer. I think that's the sort of one takeaway I'd love for us to begin to experiment with, as a community is just recognizing that the burn combined with the buffer is great mechanics that have served us to get to this point, but they're not going to get us to the next issue we need to get to.
- I am coming from a product and engineering angle. What are the parameters we have now? What are the inputs and parameters we need in the future? Let's prioritize the most realistic ones. To Tim's point, like getting Clapper up? It makes more sense. And it's already semi-coded. From there, we need to figure out, okay, do we want to pursue a distributor so that it doesn't have one pool of capital that the bunch of different interests is pulling on? What does that look like? And actually, map that out from there? That's it.
- David: Tim, your point was that you hope as a result of this call, we will fall, or kind of all sync on what some next steps are and what you believe our next steps are upgrading our revenue management, essentially, right?
- Tim: yes, that summarizes it well.
- David Utrobin: I know, historically, it has been a community OGs that have been driving forward the next steps on a lot of stuff at Maker, especially Tim Schuperner, around the surplus buffer, votes. I'm curious to get a CoreUnit to pick this up and prioritize it. What has to happen? Who in the community should be putting forward these directional proposals? Should it be recognized delegates? Should it be anybody in the neighborhood? Should it be like CU facilitators and leaders themselves? I am curious about people's views there.
- Thomas: I was going to say there's sort of, I don't want to sound obstructionist. There is a tyranny of structurelessness. Suppose it's everyone's responsibility that no one does it. That's kind of why I was pushing to some wrap-up posts, where we have some level of takeaways. Some of us can say, I want to own this or work with a couple of other people to push these initiatives forward. This is not the kind of thing that gets solved in a month; this is two quarters, at least, of thinking and planning stuff, though; it's central to the whole system, right. It's going to need a lot of input and work. The entire point of these open calls is to stimulate the community to think through what ideas they want to bring forward. And then to think through and flush through the options, just like the governance and risk call, right. We think through the following steps; we don't make decisions on that call.
- Unknown: Tim, I thank you. I think you summed it up very well; that is the intent, to bring those issues for and lead us into our last topic today. Before we do that, we wanted to get anybody else who had any more thoughts or feedback to move on to our last piece here. Tim did already moved us forward, which is shaping future topics.
- As you pointed out, our intent, again, is to research the forum through the signal requests, through what is a pertinent topic, a timely topic, that we really should have an open discussion about bringing up points, the current state, where we're at where we want to go, and more importantly, being able to walk away saying, Okay, we've got a follow up a little plan of action here.
- From what I'm hearing today, it's been an excellent conversation that, with his extra buffers, triggered a lot of dialogue to identify our, what's this longer-term solution, who's going to be the responsible party, what should be a follow up to that? Given that, if you can think of a future topic, and we're, we want this to be your platform, we want this to be something that we look at for a future topic.
- We're just in that process for today's topic. Thank you, Tim, for your signal request and everything that helped us identify something that I think is very relevant to the company. What about the next one? We will aim for these to try to be at least monthly. We want your feedback. We're still looking at the most appropriate way to get that feedback. I want to end this section to ask everyone what their thoughts for shaping future topics are? I've given my sort of two cents is no wrong or correct answer. There is just an opportunity for us, and I will let David take it from here to help drive this a little further.
- David Utrobin: I want to frame a little bit. I want to give just some additional context. We also have our Thursday Governance and Risk call that we've recently transitioned to using as a more discussion-based call. We typically work with the mandated actors, every Tuesday, we have a meeting, and we pick through a list of current events and topics, and we decide what the most sort of pertinent issue that we can discuss this week is. Those discussions are great, and they're enough. The benefit of having this particular issue, discussion call series, is that we want to produce, and we are creating a lot more detailed, pre-call notes, contextual information; we want to have more committed buy-in for participation from particular stakeholders that are relevant to the issue. Even beyond suggesting topics for this specific call, I am curious what people in the community would like to see for how they can request discussions because, at the moment, they are driven by what we see on the forum as being the most important stuff, we don't have a vast amount of feedback from the general community about what once what discussion topics are relevant.
- Thomas: David, to that point, it's not necessarily an information session; it is a discussion about a topic that we want to try to move forward or talk about in more detail.
- What would be most helpful is to look at the tools you have necessary, assemble the information around the hot topics of the community or the ones that need unpacking. I'd greatly sympathize with your guys' job, essentially, because you essentially have to do all the legwork to come towards making a decision together as a community. Then making sure the community takes those next steps. It's not exactly an easy thing, but some ideas are different, definitely like leveraging, probably Discord. I know GovAlpha has this anonymous question box thing. Some level of pulling people together, trying to hold stages on Discord, or putting some community energy there, so it's easy and quick for people to put their opinions in, might be pretty helpful. You are then leaving some room for the Anonymous members of our community to continue pushing us forward and holding us to the fire to add their opinions. Again, that's just going to add a little more to your plate to have to source and put together everything and frame it into what actionable decisions we can make together? So those are two thoughts.
- UltraSchuppi: It is a bit selfish, probably. Because what I would think about or talk about and get information about is, we have delegation now, for two months, three months or something like that. Do we have a proper system of delegates? Are they approachable by the people who previously haven't voted or have voted and are started delegating it? Is this transparent enough? Do we have enough communication between delegates in the community? Do we need tools like town hall meetings? I'm going to run in my first office, our meeting tomorrow as a delegate, is that something helpful? I have no idea what we need here. We have an ideal situation because we have people who have voting power and are approachable. I don't think we leverage that enough. I don't know, maybe that would be something for an hour of talking with people who have ideas.
- Thomas: No, that's great. I can see you can DM us; you can shoot us information on it—everyone on the call. If you walk away from the call and you go, I should have mentioned, by all means, get in touch with us. We want to hear your thoughts because this is how we will build this into a robust discussion. I think today's meeting was very value-added. Certainly in terms of coming, walking away from it, and thinking about these longer-term solutions for the surplus buffer, especially. Any other thoughts, we're just being mindful of time; we have about five minutes left. I wanted to see if anybody had anything else to add.
- David Utrobin: Tim makes a great point in the chat. He says it also might be helpful to think through a longer-term sort of cadence for recurring or complex topics. For example: How is the delegate system working? This is something like a domain of Maker that is evolving. It just launched without compensation, and now it has compensation. Now, we have three delegates, maybe seven or eight. That's the case now, but it might be a different conversation six months from now. I like that whole concept of recurring discussions on ongoing matters like I don't know, issues there, because it's not an issue, like, delegation is like using delegation as an example. It's like working right; there's not an issue. The issue is how do we make it better?
- Thomas: That is an excellent thought to have because we're talking about surplus buffer today. We're not going to not talk about it anymore. I think that that's a great thing to consider as we continue to develop these is to revisit. We are talking about a long-term solution for surplus, surplus buffer, maybe over the summer, maybe there's something that we need to consider as a long-term discussion topic.
- Unknown: I think that's summarized up quite well. I think that would be an excellent service to the community. David's correct: there are no particular issues; there are complex topics with many stakeholders that all have opinions about how to move forward. We all want the same thing. Just aligning around some set of expectations and direction, I think would be the most helpful thing for those long term topics, say, by six months, we want to have X decision plus like Y variables on the surplus buffer, right, which sets up the next series of conversations, or it goes to PE to come back with their estimations. This is a very crude example because there's no way it will be that simple, but we might be surprised which ones turned out to be a little easier than we think. That's why I framed it that way.
- David Utrobin: I agree, and it's also a tool to refresh stagnant conversations that might still be important. They're just stagnant because it's like, okay, all of the views are shared; there's not much progress to be made. It's just a matter of timeline and next steps. Whoever is the actors who need to take action on execution have to do that—using these calls as refreshing old conversations or reassessment of aging but ongoing matters. Those are exciting perspectives.
- Thomas: Just as a reminder, if you've got anything else you want to add DMS or please give us a contact, we are now at 1259. I thank everybody for attending. Please keep your eyes peeled for January's issue discussion call. We'll be having that out here shortly. I thank my team for helping put all this together. We work together to try to bring the community together, be engaged. I think today's conversation was really good. A pertinent topic and I can't wait for the next call. I can't wait to follow up and see how this goes. But again, thank you all for your time. This is recorded. We are here to help and listen and hope you have a great rest of your day. Thank you all for joining.

## Credits

- Kunfu-po produced this summary.
- Andrea Suarez produced this summary.
- Artem Gordon produced this summary.
- Everyone who spoke and presented on the call, listed in the headers.