Ahh, gotcha, it would just be a simple ethereum contract call - very minimal gas fee. No Dai or MKR required.
Going to just read through and leave feedback. Super excited about this one! Thanks for taking the time to write up the proposal.
So I’m going to go out on a limb and say that it maybe should. It appears to be a more autonomous version of the same thing. Setting up polls and executives each week takes a reasonable chunk of my time each week, and I know it takes up the smart contracts team’s time as well. If we can minimize the time-cost of governing debt ceilings, that leaves us able to focus on other, more valuable items of work.
From a governance perspective reducing the number of repetitive votes is also a clear win for voters in my eyes.
Can we be more specific here? Technically in the future we may have multiple teams, I can see a path where this becomes confusing down the line.
This field is supposed to MIPs that are being replaced, not just random things. I would just change this to N/A.
If we need a MIP that defines the process to control this/these modules, I suggest we write a MIP specifically with that aim, rather than trying to make MIP17 that MIP. Although it’s related, it wasn’t quite written with MIP27 in mind.
I would actually reverse this as I’ve suggested above. Let’s sign-off the use of DC-IAM’s in principle (in the form of this MIP), then we can craft a MIP that fits the functionality we have available.
Incredibly minor formatting thing. In almost all the other MIPs these are written as MIP27c1: Definitions. (Added colon.)
When you say this is determined by governance, do you mean that the IAM supports both and we can use either interchangably, or that we need to decide once in advance whether we want absolute or relative values for all DC-IAM’s, or that we can decide per
To clarify, is there one module that controls all
ilks or one module per
Did you mean ‘update’ rather than ‘upgrade’?
Is there planned to be a UI for this module? Or is it thought that this interaction will take place using direct contract interaction on Etherscan?
How do these changes affect the global protocol
I’m not sure I understand the utility of the defensive debt ceiling. Can you maybe elaborate as to why this exists in the MIP?
Does the individual enter new values manually? Or does the system just have an ‘update’ method which calculates everything and requires no parametrized input?
Pretty sure I understand this, but assuming the DC-IAM is proved out, is it possible to activate it in the same executive as a new collateral is onboarded?
Apologies, I realise the above questions didn’t get answered. In advance of the Smart Contract Team formalising this MIP, I have provided some quick responses below;
- Agree, it feels like this MIP will render MIP17 redundant. Note that the additional UI frontend work will however take more time to implement.
- Re: author specificity - yes, the Smart Contract Mandated Actors are proposing this enhancement.
- Re: percentages or absolute values. This should be updated to an absolute value only. Debt ceiling parameters will be set per
ilk. Depending on the frontend design it may be possible to batch DC changes in a single transaction for efficiency through a proxy contract (TBD).
- Agree, that the process for changing parameters will need to be a new sub-MIP dependent on the UI frontend designed for this purpose.
- There is one module that controls all
ilks based on what exists in the
- The intention is to build a UI specifically for this module in order to reduce the weekly voting burden. The UI should self calculate the possible change for the user to then action a transaction. Note, no frontend work has been defined yet so this may change.
ilkDC raises will also increase the global
- It will be possible to use the DC-IAM for an
ilkin the same executive that it is onboarded (because that collateral will then exist in the
What are the implications of MIP27 with MIP21? I understand why this is needed when we have an unknown number of users that might cause DAI minting. However, it is not clear to me if this is truly needed for Real World Assets or actually how it would impact operational off-chain lending.
Good question! So, the DC-IAM needs to be authorised per collateral type, therefore, Governance would need to approve it’s use for RWA (for example). Due to the different risk/collateral parameters being proposed in MIP21 I do not think we would want to activate this module for real world assets - at least not initially.
I’ve officially moved this MIP from RFC to Formal Submission for the November governance cycle. @charlesstlouis
Hello Derek–you mention that Anybody can increase/decrease the DC via the IAM without the need of holding/owning MKR/DAI–I would imaging the Team has discussed how an actor could use the DC IAM to trigger a Flash Loan? Was there consideration that perhaps only MKR holders that lock their MKR in the DSChief (or DssGov) should be allow to use/trigger the DC IAM? Just thinking out loud…
This is correct. For RWA, governance would leave this module off.
Hi @ElProgreso , correct, the idea is that anyone can make a transaction as long as the rules for a debt ceiling change are met - namely that the current Dai supply for a collateral type is within a defined range of the debt ceiling but still below the upper limit, and that the time (ttl) to make a change has elaspsed.
Initial discussion did consider limiting the IAM only to those that hold MKR (e.g. using an IOU token to control such functionality), however because of the rules that are in place, such as; time limits preventing immediate subsequent DC increases as well as limits to how much the DC can be increased or decreased, meant that authorising the DC-IAM to operate within these bounds becomes possible without restricting it to MKR holders. It also helps democratise the IAM capability to those that may be vault holders but not necessarily MKR holders - although it is always MKR holders that determine, through Governance the risk parameters that define the system.
With regards to flashloans…hmm, I don’t think they would be relevant here…but let’s keep the idea alive for a bit…so, a standard ethereum transaction is all that is needed to implement a DC change. So let’s say a DC is raised - in the same way as it is today when we raise the DC, there’s nothing stopping any vault from maxing out the limit - for example this is what we saw earlier this year with the Nexo vault that I think maxxed out WBTC. In such a scenario, all we can do is monitor and make sure that the parameters we have in place - amount of the increase, the time to new increase and relevant SF’s and Liq ratios, are sufficient enough for the risk that the protocol is taking on. But I’d be keen to hear if anyone has any thoughts around how flashloans could be of influence here.
Hi everyone, thank you for the positive DC-IAM feedback on the G&R calls, R/C and forum. The overall function of this module remains as initially outlined in the above MIP, however the Smart Contracts Team have renamed one of the contract functions, specifically:
top has been renamed to
gap and is defined as an absolute value. It is worth noting that the
gap will also function as a minimum debt ceiling. As a result, it is high time for the community to work with the risk team (@Primoz) to determine the following four values;
- Which collateral types (
ilks) will the DC-IAM support?
- What is the maximum debt ceiling (
line) allowed per collateral type?
- What distance (
gap) do we want between existing debt (Dai supply) and the debt ceiling?
- What amount of time (
ttl) do we want to enforce between debt ceiling changes?
Let’s dive into each of these in a little more detail to provide a reference point from which to begin:
ilk : Which collateral types will be authorised to use the DC-IAM and what will be their initial debt ceilings?
- The Smart Contracts Team is comfortable for all collateral types to be authorised to use this module. This statement is made with the awareness that the module is limited to controlling only the debt ceiling within parameters defined by governance. Therefore is the rest of the community comfortable with all collateral types having this capability or do we want to trial-run this with a limited number of ILK’s?
line : What is the maximum debt ceiling allowed per collateral type?
- The maximum debt ceiling limit can always be increased or decreased through a governance action. The maximum debt ceiling is a hard limit that prevents any further incremental debt ceiling increases through the module. As an example, this value should be sufficiently high enough to not require adjustment for the following 3-4 months (otherwise it defeats the purpose of having an IAM).
gap : What absolute number should be the distance between the current debt (Dai supply) and the debt ceiling?
- The Smart Contracts Team recommends looking at existing Dai mint amounts to ensure that these can be supported within the proposed
gap. Governance often observes the creation of large Dai generating vaults which ideally should not be hindered.
- It is worth noting that the maximum borrow amount of Dai may be slightly higher in the event that there is an immediate supply decrease which hasn’t yet triggered a debt ceiling decrease.
ttl : What amount of time is required to pass before a new adjustment to the debt ceiling can be made?
- The value chosen should require at least one OSM update so the module reflects an accurate market price. For example, a
ttlof 2 hours, with a maximum 10m increase, would allow users to increase the debt ceiling by +100m in a single day, which is similar to what we have today when passing an executive vote. Note, the
ttlis not required when reducing the debt ceiling.
These values should be agreed upon in the following format for the Smart Contract Mandated Actors to code and implement:
|ILK (Collateral Type)||Participate in the DC-IAM (Yes/No)||LINE (Max Debt Ceiling)||GAP(Distance between Debt and Ceiling)||TTL (Time between DC changes)|
Initially this contract can be called through etherscan by any user familiar with the contract write capability . In time the expectation is to provide a user interface that visually illustrates the debt ceiling per ILK with the ability to call the contract through the UI.
The intention is to agree upon the above values with the community and mandated Risk Team in time to launch the DC-IAM as part of the December 11th executive.
Are you expecting the community to post signal requests to determine these parameters or is the risk team going to propose starting parameters?
Thanks @Derek. Since we have only this week to discuss this topic and have parameters proposed I would personally prefer trial-run implementation for vault types that will see most benefits using this, especially during the holidays when executive voting will be limited.
Therefore I suggest we implement DC IAM for ETH-A, ETH-B and WBTC-A. Potentially also for YFI-A where DC is maxed out, but we need to agree on higher SF, which as I mentioned in the other forum thread, could go to double digit numbers. Plus, we almost had a single YFI-A vault liquidated last week with 9m debt exposure.
I personally think DC IAM is mostly beneficial for ETH-B vaults, because it helps us protect against OSM attacks.
Also, I think DC IAM can not be very efficient until we decrease GSM delay, currently set to 3 days. The idea is to have a
line (max DC) set higher than what current debt ceiling is, but at the same time we need to be able to lower it if something goes wrong. If GSM delay is set to 3 days, maximum debt ceiling could be already reached, unless we have a very low
gap or high
ttl. But this can become very limiting and efficiency of IAM DC becomes questionable.
Nevertheless, we can still implement it for all collateral types if the community prefers. We spent some time already to calculate max DC figures for each collateral type, which are based on certain estimates of risk tolerance (mostly based on CEX+DEX volumes).
Sounds good. Are you planning to present on this in the next G&R call or here? What are the next steps?
We are planning to post some suggested parameters for these three vault types here very soon. I was only waiting for community if someone thinks we should implement it for all vault types next week.
After analyzing parameters needed for IAM DC and right before proposing them here we did another analysis of user behaviour under IAM DC. Unfortunately we found a bug that makes IAM DC very ineffective and limiting if particular actors were to be performing certain actions.
Below is a scenario where an actor could perform a larger repay and consecutive equal amount of mint and in between lower actual DC. Since lowering DC is not limited by
ttl it means DC could in theory be maxed out all the time if such actions were to be performed in a timely manner by certain actors.
| ttl = 6 | gap = 25 | | | | | | |---------|----------|-------------|-----|--------------|------|------------------------------------------------------------------| | | activity | actual debt | gap | debt ceiling | line | | | t - 1 | / | 40 | 25 | 65 | 100 | | | t | 10 mint | 50 | 25 | 75 | 100 | debt ceiling is increased, 6 hour ttl time clock starts | | t + 1 | 25 repay | 25 | 25 | 50 | 100 | debt ceiling is reduced, no timelock | | t + 1 | 25 mint | 50 | 25 | 50 | 100 | debt ceiling fully utilized and can not be increased for 5 hours |
I hope @Smart-Contracts an find a solution to this issue. I was thinking we could have
ttl applied also for DC decreases, but I think the same attack could be performed, the only difference is that it can be performed only once
ttl time lock is reset.
We can post our analysis on parameters proposed, but I think it doesn’t make much sense until current implementation is fixed. I was also thinking such attack doesn’t really make any economic benefits to anyone so maybe we could still try it out for ETH-B vault type, where benefits of IAM DC are highest due to potential OSM attacks. Note however that in the worst case someone can make ETH-B DC constantly fully utilized. Preferably of course different solution needs to be found.
Feedback welcome, particularly from @Smart-Contracts as we may have also missed something here.
Does this mean that MIP27 can’t be deployed until a new implementation is developed to work around this problem? Where do we go from here?
dss-auto-line griefing attack
The current implementation of the dss-auto-line contains a potential griefing vulnerability.
The essential function of the auto-line is to allow public users to increase or decrease a collateral
line value by some amount
gap, which results in a new
line value that is the existing debt balance plus the
gap. The line will not increase if the last increase happened less than
ttl seconds ago. The line will decrease regardless of how many seconds have elapsed since the last change.
The motivation for adding the delay between increases is to mitigate the risk that the price of a collateral is read higher than the current market price.
In the worst case, the oracle price is higher than market price by more than the collateralization ratio buffer, which would allow one to fill a Vault and generate the maximum amount of Dai against the collateral, thus causing the Vault to be under 100% CR in the next oracle update. If the
ttl is too short, anyone could increase the
line multiple times before the oracle price matches the market price, which would cause the protocol to take on excess amounts of bad debt. Mitigating against this risk is the reason we have debt ceilings in the first place, and also the reason the
ttl should not be too short.
Decreasing the debt ceiling carries no such risk, and is in fact desirable if the oracle price for an asset is considerably higher than the market price. For this reason, there is no
ttl before decreasing the debt. It’s this lack of a
ttl before decreasing the debt that creates the potential for a griefing attack.
This griefing attack would allow a user with a large vault to prevent the
line from increasing after the
ttl. There could be a financial incentive to perform this attack in a Dai liquidity crunch, which would allow the vaultholder to corner the Dai market and prevent supply over a critical period. While the protocol has, and will create more, Vaults that are available in a liquidity crunch, it’s still worth considering this attack vector for an asset.
Hypothetical scenario is as follows
- auto-line is configured with a
gapof 5,000,000 and a
ttlof 1 hour.
- malicious vaultholder has $10,000,000 (or more) worth of collateral in
WBTC-Aand 5,000,000 Dai in debt.
WBTC-Aline is 160,000,000,
WBTC-Atotal debt is 160,000,000
- malicious vaultholder calls
- malicious vaultholder flash borrows 5,000,000 Dai and repays all or a portion of their debt. Total debt is now 155,000,000
- malicious vaultholder immediately calls
lineto starting value of 160,000,000
- malicious vaultholder generates 5,000,000 Dai and repays flash loan
linevalue remains at 160,000,000 for the next hour
- legitimate vaultholder is unable to generate more Dai for the remaining
- This problem is compounded if malicious vaultholder repeats the attack hourly.
- A shorter
ttlwould make this attack more operationally expensive, but it also reduces the effectiveness against oracle attacks.
- A larger
gapwould require an actor with more resources, however this sort of assumption might not work in a world of flash loans.
ttlfor DC decreases. This would prevent us from being able to cap the DC to
gapif the market price was lower than the oracle price, and doesn’t prevent the griefing attack, it just pushes it to the end of the new
- We’ve removed the ability for flash loans to be used to execute this attack here.
The smart contracts domain team as limited the griefing attack to actors with extremely large positions. We believe this reduces the risk of griefing the debt ceiling significantly, enough that the other benefits of this module may be realized. Nevertheless, we suggest deploying this with just ETH-B for now. This allows domain teams and governance to get used to the functionality of the module, and if the griefing attack proves to be a problem, ETH-A is always available for additional debt.
Some future notes about when we consider this module for other collateral types.
- By removing the flash loan capability in conjunction with this module, it would mean an attacker would have to have the capital to fill the
gapin order to execute a griefing attack. Under the mitigation section, we discussed making the
gaplarger in order to make this attack less available.
- Make sure certain collateral types like USDC-B, or perhaps those managed by any future implementation of a PSM are not managed by this module.
NOTE: While we think the risk is low, it would still be helpful if the community could think about various motivations for this attack, other than those mentioned above. What would an attacker gain by griefing one, many, or all, of the collaterals that use this module?
@brianmcmakerdao for the initial discovery and writeup of this attack.
@Primoz et al. for discovering this independently in a risk review. Great work!
@galabasquer implementing the DC IAM, and the flash loan mitigation.
If I understand correctly,
At the end of the day, once the flash loan risk is removed, we currently have a same risk. If I recall it has already happen with USDC or ETH when we had 0%. someone filled up the vault to push governance to increase then remove the loan.
Except that with the MIP27 it is 5h instead of one week.
The other option, but I guess you have already thought about it and there is an issue somewhere that I can’t see.
We save the previous line and allow people to go back to it with out ttl. If it is with in the previous ttl.
Good stuff Mooney! Took me a bit to fully understand it–I have read about griefing on Minecraft and insufficient gas griefing, but never about a main dish of collateral shortfall/DC disruption/griefing with a side dish of Flash Loans haha
Hey @yaronvel wanted to circle you into this thread and ask if you can help the community think of any other attacks that would motivate a malicious vaultholder to increase
line with other collateral types outside of ETH, such as WBTC-A and perhaps the proposed/talked about WBTC-B collateral type? Your thoughts would be helpful!
I am not sure i fully understand, but wouldn’t an attacker without extra capital would be able to perform same attack simply by temporarily decreasing his position?
E.g., I withdraw the DAI to supply liquidity to uniswap, and now I use the ETH/DAI LP as a collateral to borrow more dai, and then i repay some of my DAI debt.
Or I withdraw DAI to supply liquidity to curvfi, and now i use it as a collateral at cream to borrow DAI.
Or even simpler, just take my current ETH collateral to a minimum, put it in another vault, and mint DAI.
But more generally why only capital-less (aka flash-loan) attack is the issue?
It seems only whales could apply it anw, so assuming they have few millions on the side, on alternatively that they could decrease their debt by few millions using their extra collateral, is not unlikely.