hash - Leftover dust debt can cause liquidation auction to occur at significantly lowered price

[sherlock-admin3]

hash

Medium

Leftover dust debt can cause liquidation auction to occur at significantly lowered price

Summary

Using frob to refund the gem inside onRemove can disallow liquidations due to dust check

Vulnerability Detail

When an auction is removed (on completetion) from the clipper, the leftover amount of the auction if any, is refunded back to the user by calling the onRemove method

gh link

    function take(
        uint256 id,           // Auction id
        uint256 amt,          // Upper limit on amount of collateral to buy  [wad]
        uint256 max,          // Maximum acceptable price (DAI / collateral) [ray]
        address who,          // Receiver of collateral and external call address
        bytes calldata data   // Data to pass in external call; if length 0, no call is done
    ) external lock isStopped(3) {

        .....

        } else if (tab == 0) {
            uint256 tot = sales[id].tot;
            vat.slip(ilk, address(this), -int256(lot));
=>          engine.onRemove(usr, tot - lot, lot);
            _remove(id);
        } else {

After burning the associated fees, the remaining amount is credited to the urn by invoking vat.slip and vat.frob gh link

    function onRemove(address urn, uint256 sold, uint256 left) external auth {
        uint256 burn;
        uint256 refund;
        if (left > 0) {
            burn = _min(sold * fee / (WAD - fee), left);
            mkr.burn(address(this), burn);
            unchecked { refund = left - burn; }
            if (refund > 0) {
                // The following is ensured by the dog and clip but we still prefer to be explicit
                require(refund <= uint256(type(int256).max), "LockstakeEngine/overflow");
                vat.slip(ilk, urn, int256(refund));
=>              vat.frob(ilk, urn, urn, address(0), int256(refund), 0);
                lsmkr.mint(urn, refund);
            }
        }
        urnAuctions[urn]--;
        emit OnRemove(urn, sold, burn, refund);

But incase the urn's current debt is less than debt, the frob call will revert gh link

    function frob(bytes32 i, address u, address v, address w, int dink, int dart) external {

        ....

        require(either(urn.art == 0, tab >= ilk.dust), "Vat/dust");

This will cause the complete liquidation to not happen till there is no leftover amount which would occur at a significantly low price from the expected/market price. The condition of tab >= ilk.dust can occur due to an increase in the dust value of the ilk by the admin

Example: initial dust 10k, mat 1.5, user debt 20k, user collateral worth 30k liquidation of 10k debt happens and dust was increased to 11k now the 15k worth collateral will only be sold when there will be 0 leftover (since else the onRemove function will revert) assuming exit fee and liquidation penalty == 15% in case there was no issue, user would've got ~(15k - 11.5k liquidation penalty included - 2k exit fee == 1.5k) back, but here they will get 0 back so loss ~= 1.5k/30k ~= 5%

POC

Apply the following diff and run forge test --mt testHash_liquidationFail

diff --git a/lockstake/test/LockstakeEngine.t.sol b/lockstake/test/LockstakeEngine.t.sol
index 83fa75d..0bbb3fa 100644
--- a/lockstake/test/LockstakeEngine.t.sol
+++ b/lockstake/test/LockstakeEngine.t.sol
@@ -86,6 +86,7 @@ contract LockstakeEngineTest is DssTest {

     function setUp() public {
         vm.createSelectFork(vm.envString("ETH_RPC_URL"));
+        vm.rollFork(20407096);

         dss = MCD.loadFromChainlog(LOG);

@@ -999,6 +1000,66 @@ contract LockstakeEngineTest is DssTest {
         }
     }

+    function testHash_liquidationFail() public {
+        // config original dust == 9k, update dust == 11k, remaining hole == 30k, user debt == 40k
+        // liquidate 30k, 10k remaining, update dust to 11k, and increase the asset price/increase the ink of user ie. preventing further liquidation
+        // now the clipper auction cannot be fulfilled 
+        vm.startPrank(pauseProxy);
+
+        dss.vat.file(cfg.ilk, "dust", 9_000 * 10**45);
+        dss.dog.file(cfg.ilk, "hole", 30_000 * 10**45);
+
+        vm.stopPrank();
+        
+        address urn = engine.open(0);
+
+        // setting mkr price == 1 for ease
+        vm.store(address(pip), bytes32(uint256(1)), bytes32(uint256(1 * 10**18)));
+        // mkr price == 1 and mat = 3, so 40k borrow => 120k mkr
+        deal(address(mkr), address(this), 120_000 * 10**18, true);
+        mkr.approve(address(engine), 120_000 * 10**18);
+        engine.lock(urn, 120_000 * 10**18, 5);
+        engine.draw(urn, address(this), 40_000 * 10**18);
+
+        uint auctionId;
+       {
+        // liquidate 30k
+        vm.store(address(pip), bytes32(uint256(1)), bytes32(uint256(0.98 * 10**18))); // Force liquidation
+        dss.spotter.poke(ilk);
+        assertEq(clip.kicks(), 0);
+        assertEq(engine.urnAuctions(urn), 0);
+        auctionId=dss.dog.bark(ilk, address(urn), address(this));
+        assertEq(clip.kicks(), 1);
+        assertEq(engine.urnAuctions(urn), 1);
+       }
+
+       // bring price back up (or increase the ink) to avoid liquidation of remaining position
+       {
+        vm.store(address(pip), bytes32(uint256(1)), bytes32(uint256(1.2 * 10**18)));
+       }
+
+        // update dust
+        vm.startPrank(pauseProxy);
+
+        dss.vat.file(cfg.ilk, "dust", 11_000 * 10**45);
+
+        vm.stopPrank();
+
+        // attempt to fill the auction completely will fail now till left becomes zero
+        assert(_art(cfg.ilk,urn) == uint(10_000*10**18));
+        
+        address buyer = address(888);
+        vm.prank(pauseProxy); dss.vat.suck(address(0), buyer, 30_000 * 10**45);
+        vm.prank(buyer); dss.vat.hope(address(clip));
+        assertEq(mkr.balanceOf(buyer), 0);
+        // attempt to take the entire auction. will fail due to frob reverting
+
+        vm.prank(buyer); 
+        vm.expectRevert("Vat/dust");
+        clip.take(auctionId, 100_000 * 10**18, type(uint256).max, buyer, "");
+    }
+
+
     function _forceLiquidation(address urn) internal returns (uint256 id) {
         vm.store(address(pip), bytes32(uint256(1)), bytes32(uint256(0.05 * 10**18))); // Force liquidation
         dss.spotter.poke(ilk);

Impact

Even in an efficient liquidation market, a liquidated user's assets will be sold at a significantly lower price causing loss for the user. If there are extremely favourable conditions like control of validators for block ranges/inefficient liquidation market, then a user can self liquidate oneself to retain the collateral while evading fees/at a lowered dai price (for this the attacker will have to be the person who takes the auction once it becomes takeable). Also the setup Arbitrage Bots will loose gas fees by invoking the take function

Code Snippet

https://github.com/sherlock-audit/2024-06-makerdao-endgame/blob/dba30d7a676c20dfed3bda8c52fd6702e2e85bb1/lockstake/src/LockstakeEngine.sol#L438-L454

Tool used

Manual Review

Recommendation

Use grab instead of frob to update the gem balance

[z3s]

The protocol team comments:

Indeed this function should be using grab instead of frob as it is the natural way to do it (we will fix it). Unfortunately frob has the dust limitation even when adding collateral and there is existing debt (which was not really needed). We can also agree if this get to occur it could be considered as a medium impact, however the likelihood of this happening is extremely low.

The conditions that need to be met in order to be triggered is that the liquidated urn took place as a partial one and before completing the dust value went higher than the part not being liquidated. The other option is that it was a full liquidation, but before it finished the user added a new position and then the dust got higher than that position (before completing the auction). Increasing dust value is not a common thing, liquidations neither (and even less partial ones). So all of this happening in the exact order to trigger this issue makes the scenario a very rare case.

It could be argued that if the owner of the urn itself is the one willing to trigger this situation it would be more feasible. However making your own urn to liquidate and block the auction to happen is not really in benefit of the user excepting the user is trying to rebuy the collateral by the minimum price which is a risky move as it could be front run and the whole situation will still leave the user with a loss to the prev condition before being liquidated (due to penalty and exit fees).

Although the likelihood of this happening is extremely low, but from Sherlock judging rules:

How to identify a medium issue: Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The losses must exceed small, finite amount of funds, and any amount relevant based on the precision or significance of the loss.

[panprog]

Escalate

This is a great finding which I think is medium under normal Sherlock contest rules (breaks core functionality). However, in this contest the rules require only loss of funds. Breaking down different parties who can lose funds from this issue:

1. Protocol. No funds loss, because due to exit fee, the auction will succeed once the price allows for the exit fee to equal or exceed remaining collateral, meaning all debt will be repaid with remainder of collateral burned as an exit fee.
2. User. Once liquidated, he is not guaranteed a fair auction price or any return of collateral at all. Liquidation is to be avoided and is a measure to protect the protocol, so any leftover collateral in case of liquidation is a benefit for the user, but not an expectation. The same can happen during network congestion, which doesn't make it a valid issue. So, basing user's loss off "expected" amount is wrong as there is no expected amount, user can expect to lose all collateral after liquidation.
3. Liquidators. They should simulate transactions offchain and not execute on-chain when there is a 100% revert happening. So they should not lose funds at all. But they should notice this so that governance can react and fix the issue.

As there is no real loss of funds, the issue should be low using this contest rules.

[sherlock-admin3]

Escalate

This is a great finding which I think is medium under normal Sherlock contest rules (breaks core functionality). However, in this contest the rules require only loss of funds. Breaking down different parties who can lose funds from this issue:

1. Protocol. No funds loss, because due to exit fee, the auction will succeed once the price allows for the exit fee to equal or exceed remaining collateral, meaning all debt will be repaid with remainder of collateral burned as an exit fee.
2. User. Once liquidated, he is not guaranteed a fair auction price or any return of collateral at all. Liquidation is to be avoided and is a measure to protect the protocol, so any leftover collateral in case of liquidation is a benefit for the user, but not an expectation. The same can happen during network congestion, which doesn't make it a valid issue. So, basing user's loss off "expected" amount is wrong as there is no expected amount, user can expect to lose all collateral after liquidation.
3. Liquidators. They should simulate transactions offchain and not execute on-chain when there is a 100% revert happening. So they should not lose funds at all. But they should notice this so that governance can react and fix the issue.

As there is no real loss of funds, the issue should be low using this contest rules.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[bb22ff]

In addition to no loss of funds, this also relies on an admin mistake.

As mentioned in the findings, an increase of the dust value during the auction is a precondition, however it can only be done by an admin , and doesn't increase on its own.

Therefore, doing this during liquidation auctions for the same ilk makes it an admin mistake. Which is not a valid finding according to Sherlock rules:

5. Admin Input/call validation:

   2. An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue.

The rule applies here exactly, with assumptions broken by the admin's actions.

[xiaoming9090]

For this particular contest, there are additional rules to consider beyond the existing Sherlock medium issue criteria that the lead judge cited in his comment here. Although the lead judge acknowledged that the likelihood of this event occurring is extremely low, the lead judge still proceeded to mark the issue as Medium without fully considering the constraints and likelihood.

Below are the contest rules extracted from the contest’s README. As mentioned, whether an issue qualifies as Medium also depends on the constraints.

Any loss smaller than 0.5% can never be Medium. Any loss between 0.5% and 5% can be Medium at most. Any issue larger than 5% can be Medium or High (depending on constraints).

In one of my clarifications with the sponsor during the audit period, it was mentioned that meeting certain requirements for a Medium rating does not automatically confer a Medium risk rating. The existing constraints should be evaluated and taken into consideration (which is aligned with the contest rule above)

As the sponsor commented here, various rare and uncommon conditions need to be satisfied to trigger the issue, and the likelihood of this happening is extremely low. Given these constraints, it clearly does not meet the sponsor’s expectation of a Medium issue. Additionally, since the constraints are part of the equation for severity classification in this contest, the low probability of the triggering conditions leads to a lower classification.

Lastly, the issue mentioned in this report concerns liquidation auctions occurring at a lower-than-expected price if the issue is triggered under rare circumstances. This scenario is closer to the concept of opportunity loss, which Sherlock does not consider a loss of funds, according to the judging rule:

Opportunity Loss is not considered a loss of funds by Sherlock.

Given these points, the issue should be Low.

[cducrest]

I may misunderstand some things, but if the ilk.dust amount defines the urn debt floor as the low amount of debt the protocol does not care about tracking/considering, then shouldn't the user losing an amount of funds lower than this value be considered a low issue? (i.e. user loses a negligible amount of funds).

[10xhash]

User. Once liquidated, he is not guaranteed a fair auction price or any return of collateral at all. Liquidation is to be avoided and is a measure to protect the protocol, so any leftover collateral in case of liquidation is a benefit for the user, but not an expectation. The same can happen during network congestion, which doesn't make it a valid issue. So, basing user's loss off "expected" amount is wrong as there is no expected amount, user can expect to lose all collateral after liquidation.

2. Not having a guaranteed price is the very nature of auctions but being unable to execute the auction in price ranges were it is supposed to be executable is a bug that leads to loss of funds. Let the market price of an item be 900, I start an auction at 1000 and there are active bidder's for the auction. For any auction the two conditions mentioned in the argument ie. no guaranteed price and low price in case of no bids, are expected/intended behavior of the auction. But if even when there are bidder's wanting to bid at 900-850 but due to a mistake in how the auction is implemented it cannot be executed for the price ranges 1000-100, effectively making the auction start at a reduced price of 99, then it is clearly an issue that causes loss of funds. Here the existence of the bug mentioned in the report makes the auction non-executable in price ranges where it is supposed to be executable

[sunbreak1211]

In our opinion, this is not part of an admin (governance) mistake, as it can not ensure that there won't be liquidations when a dust increment is being added to a spell (there is a time to vote for the spell + a timelock to actually execute it). Also, it is true that there is not a guaranteed auction price, but the system intent is to actually get closer to that. In this case, a bug is blocking (in a specific situation) to work normally.

[WangSecurity]

I agree with @10xhash and @sunbreak1211 here. I believe this issue indeed causes loss of funds as evidenced in the report and this comments. Also, I agree that it's not an admin mistake to increment dust. I see that the constraints are extreme, but still the issue is possible under special conditions which qualifies for medium severity. Hence, I believe this issue was judged correctly, planning to reject the escalation and leave the issue as it is.

[IllIllI000]

@WangSecurity

VII. List of Issue categories that are not considered valid:
...
2. An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue.

https://github.com/sherlock-protocol/sherlock-v2-docs/blob/e7dc89270b05f8d2fcee69dc4204c7a2b8fb4cf9/audits/judging/judging/README.md?plain=1#L97

Nowhere does the current rule allow for a non-README-excluded admin action to be a Medium. I understand that the sponsor after the fact is saying that they don't consider it an admin 'mistake', but the rule doesn't say anything about mistakes - it only covers admin actions, because we can't know intent ahead of time. Further, the readme says Governance configurations are assumed to be set with extreme care, and this is a governance-set parameter. The sponsor answered "No" to all of the admin-input-related questions, and there was no update 24h prior to the end of the contest.

[nobodytrue]

That appears to be a rather narrow interpretation of the README.md

If one were to adopt your approach to interpreting the README.md, it would be impossible to identify any valid issues, as each potential issue involves interaction with a state variable that is either initialized during construction by the admin(an admin action) or set by the admin after construction(an admin action). Consequently, any potential finding could be considered (directly or indirectly) a result of an administrative action and thus should be deemed invalid based on your interpretation.

[panprog]

Here the existence of the bug mentioned in the report makes the auction non-executable in price ranges where it is supposed to be executable

Also, it is true that there is not a guaranteed auction price, but the system intent is to actually get closer to that. In this case, a bug is blocking (in a specific situation) to work normally.

I agree with both statements, but the impact of this is core function not working in a specific case, not loss of funds. Quoting README:

Breaking any kind of functionality is not a medium or high severity issue for this competition, only loss of funds

So this issue indeed causes breakage of the functionality, but as I've shown in initial escalation, neither party loses funds due to this, thus can not be medium or high. The system intent to get a price close to market price is just an intent, not a guarantee. An execution price much lower than market is breakage of this intent (functionality), not a loss of funds.

Additionally, user understands that there are certain limitations during the liquidation, quoting README:

As getting liquidated is considered a state that should generally be avoided, it is expected that in such cases the urn owner becomes limited in various ways. For example, it cannot delegate or stake during liquidations and in some situations, it can take more time than the urn owner expects due to more liquidations or liquidations taking a lot of time. Other limitations may apply and are not considered an issue unless significant funds are lost permanently.

So this one falls under "it can take more time than the urn owner expects", so README specifically mentions that user can expect longer liquidation time (which implies smaller price) in some situations, meaning that user receiving 0 after liquidation is not a loss of funds, but something user is warned about beforehand (thus can't qualify as a loss of funds - allowing the liquidation is user's mistake in such case).

[JeffCX]

This is not a medium / high severity issue.

from original report

The condition of tab >= ilk.dust can occur due to an increase in the dust value of the ilk by the admin

from the original sponsor comments

The conditions that need to be met in order to be triggered is that the liquidated urn took place as a partial one and before completing the dust value went higher than the part not being liquidated.

The other option is that it was a full liquidation, but before it finished the user added a new position and then the dust got higher than that position (before completing the auction).

Increasing dust value is not a common thing, liquidations neither (and even less partial ones). So all of this happening in the exact order to trigger this issue makes the scenario a very rare case.

[WangSecurity]

About the admin actions. As I understand, it's a completely viable action to increase the dust amount. I see it's assumed not to be a common thing, still, it's a viable action by the admin. But, this step doesn't lead to any loss of funds. As I understand, the tab amount can decrease over time. Hence, the admin could set dust to sum value X, when tab was >X, but with time tab decreased to <X, leading to this issue.

Hence, I believe that the admin actions rule or the governance setting the values with extreme care is not applicable here.

So this issue indeed causes breakage of the functionality, but as I've shown in initial escalation, neither party loses funds due to this, thus can not be medium or high. The system intent to get a price close to market price is just an intent, not a guarantee. An execution price much lower than market is breakage of this intent (functionality), not a loss of funds

Yeah, I see how your escalation comment elaborates that none of the parties lose funds here. But, I believe this comment answers your claims. There is not guarantee of the price, but there's the expected range and this issue leads to the price leaving this price range. Hence, I believe it's indeed a loss of funds. But, please correct me if I'm wrong here and the comment is incorrect. Until then, I believe this qualifies as medium-severity, the decision remains to reject the escalation and leave the issue as it is.

[IllIllI000]

The admin action rule has this example, which matches the logic that you've outlined: Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue. see the inline replacements I've made below:

As I understand, it's a completely viable action to increase the dust amount pause the protocol. I see it's assumed not to be a common thing, still, it's a viable action by the admin. But, this step doesn't lead to any loss of funds. As I understand, the tab amount value of the collateral can decrease over time. Hence, the admin could set dust to sum value X to paused, when tab the collateral value was >X, but with time tab the collateral value decreased to <X, leading to this issue.

@WangSecurity can you explain how is this any different?

This is about following the rules of the contest. Sherlock makes a big deal about not having watsons waste time finding lows, and so if the rules say something is low, we're not going to look there. It's not fair to suddenly change your mind about an existing rule, just because after the fact you see a case where the rule was sub-optimal. When that happens, the remedy is to introduce a SJIP and fix it for the future, NOT to penalize all the other watsons that followed the rules, by taking points and rewards from them. The Sherlock rules mark this as a low, and the sponsor readme comment reinforces the rule. The sponsor could have easily said after the fact instead, the spell that changes the dust will always do so when there are no ongoing auctions - that's part of what extreme care means, and there wouldn't have been any question about whether it's low or not. The point of the rule is to NOT rely on what the sponsor says - to rely ONLY on the rules and the readme.

[panprog]

As I understand, the tab amount can decrease over time. Hence, the admin could set dust to sum value X, when tab was >X, but with time tab decreased to <X, leading to this issue.

No, this is not possible. tab is a debt taken against the collateral. The debt can only increase, never decrease (borrower thus pays stability fees). So the only way for the issue to happen is when dust value is increased by admin while the debt is above previous dust, but below new dust. All actions which bring tab below dust (and non-zero) will revert, so no other way to achieve it.

This means that admin should increase dust value only if there are no active users with unfinished liquidation and debt above previous dust but below the newly set dust. If there are such users (extremely unlikely event), admin should wait until the liquidation finishes.

Also, if user's debt is between old and new dust values - this is problematic by itself even without the issue from this report. Googling makerdao dust increase or similar shows multiple discussions on funds being stuck due to dust increase. For example, this discussion talks about user being unable to add or remove ETH due to his debt being below the new dust. So before dust is increased, users should be warned that having their debt below new dust value can cause different issues, including the one described here. And then it's a user's mistake to keep his debt in this range despite the warning.

So if admin indeed takes extreme care when increasing the dust, the issue described here should not happen (either admin will wait until liquidation finishes or all such users will be warned of the problems due to such debt amount).

There is not guarantee of the price, but there's the expected range and this issue leads to the price leaving this price range.

There are no exact values of "expected range". Here is the example from the issue description:

initial dust 10k, mat 1.5, user debt 20k, user collateral worth 30k liquidation of 10k debt happens and dust was increased to 11k now the 15k worth collateral will only be sold when there will be 0 leftover (since else the onRemove function will revert) assuming exit fee and liquidation penalty == 15% in case there was no issue, user would've got ~(15k - 11.5k liquidation penalty included - 2k exit fee == 1.5k) back, but here they will get 0 back so loss ~= 1.5k/30k ~= 5%

For simplicity let's consider collateral market price to be exactly 1. As can be seen from example, if liquidation auction was held at a market price of 1, user gets back 1.5k. But due to this issue, the real auction price is ~0.88 (so that user liquidation with penalty is 10k/0.88*1.15=13k, 15k-13k-2k = 0). So who can say if the price of 0.88 is within the expected range or not? What if gas prices were high and it was unprofitable to finish liquidation auction, so it takes longer and reaches the same (or lower) price. Yes, the issue does prevent normal auction execution even in normal market conditions, but the impact is comparable to that of network congestion, while the likelihood is a lot less than that of high gas prices, meaning this is still within expected price range, even if for different reasons.

[MiloTruck]

Reading this in passing, but:

Hence, I believe that the admin actions rule or the governance setting the values with extreme care is not applicable here.

Since when could the HOJ just override the rules as and when he sees fit?

An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue.

This issue is literally about an admin action (ie. increasing dust) breaking certain assumptions about the functioning of the code (ie. tab >= dust).

[10xhash]

There is no assumption that the tab will always be greater than the dust. If you are increasing the dust, it will lead to all positions that are currently below the new dust to be below the new dust as trivial as it is. This is expected, has already happened and no assumption is broken here. There are intended consequences in this state too like one can't withdraw their collateral unless the debt is cleared or brought back over the dust value(even if the health ratio is maintained). But the mistake mentioned in the report causes the liquidations to happen incorrectly in the scenario. The arguments flip the mistake to be the assumption and the valid action to override a non-existing assumption

An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue

And the mentioned rule doesn't state to invalidate all issues that has an admin action as a precondition

[IllIllI000]

There is no assumption that the tab will always be greater than the dust.

tab >= ilk.dust is the line from the report whose assumption is being broken when the admin changes the dust amount.

The arguments flip the mistake to be the assumption and the valid action to override a non-existing assumption

The 'mistake' is the assumption, or else how can the rule ever be applied?

And the mentioned rule doesn't state to invalidate all issues that has an admin action as a precondition

Yes it does. An admin action [can|is allowed to] break [certain|any subset of] assumptions about the functioning of the code. Having it be an admin action, plus answering "No" to the restriction questions is equivalent to the TRUSTED rule that was previously there:

The SJIP introduces impactful changes to the QA questions and the judging guidelines, shifting the focus to specific parameter values in access-restricted functions rather than broad protocol roles.

This change will provide watsons with the utmost clarity regarding what values they can use to identify a valid attack path.

Sherlock will be more responsible for guiding the protocol well in answering these QA questions.

https://github.com/sherlock-protocol/governance-and-discussion/discussions/9

[WangSecurity]

My understanding of the tab, i.e. debt value was incorrect. As explained in this comment it can only increase, so the situation where tab becomes less than dust is possible only when the admin/governance sets dust above the tab value.

To explain why I thought the admin actions rule was not applicable. Increasing dust is completely viable and there's no limitation on its value. This issue is possible with any dust value besides 0 and when it's above the tab value. My incorrect understanding was that tab can decrease so it becomes less than dust, i.e. admin set dust less than tab, action doesn't break anything, and then tab becomes less than dust.

But, I see that for this issue to occur, an admin has to set dust above tab. Hence, I agree that it's an admin action that would cause a loss of funds, i.e. the following rule applies:

An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue

Also, as was correctly pointed out, this line from the contest README applies as well:

Governance configurations are assumed to be set with extreme care

Excuse me for the previous confusion. I believe it has to be invalid, planning to accept the escalation and invalidate the issue.

[10xhash]

Admin action as a precondition? yes

But

I agree that it's an admin action that would cause a loss of funds

omits the most important details. The correct line would be:

• it's an admin action
• and an essential feature (increasing the dust) that has been present in the MakerDAO system since inception and have been/is supposed to be used
• that can result (not cause) in a loss of funds, only due to the above bug (this is the cause) being introduced in the new codebase(lockstake)`

And it is not a specific action (setting to value A etc. an example for which would be setting the loan-to-collateral value to large values) but the full feature itself (dust increase) which is essential, has been present in the MakerDAO system since inception and is expected to be used. The current contracts are getting added to this already existing system. Wherever the new contracts makes explicit-problematic assumptions about the already existing system it is clearly mentioned by the team too under the design decisions made/known issues and explicitly state the acceptable risks for each known issue section. For eg:

Emergency or planned shutdown is assumed to not happen Using yank() in the lockstake clipper is assumed to only happen as part of a shutdown procedure. Since this is out of scope, it is assumed not to happen

An admin action can break certain assumptions about the functioning of the code As I said previously, no assumption is being broken here. The protocol never assumes that positions having debt below dust will not exist. The condition of tab >= ilk.dust is an enforcement kept on the frob functionality but not an assumption of the protocol. If it helps to differentiate b/w enforcements of functionality and underlying assumptions, similar check exists in the frob functionality for the liquidation ratio/health of the position, that doesn't mean that the protocol assumes that no position in the protocol will have bad health. The enforcement is to prevent such positions from being created via the frob functionality.
The issue here is not of any assumption breaking, but the new implementation of liquidation functionality overlooking the dust limitation even when adding collateral and there is existing debt (which was not really needed), as stated by the protocol team, of the already existing frob functionality. The correct method to use ie. grab is already being used in the end contract of the existing system where a similar requirement of bypassing frob enforcements arise

Governance configurations are assumed to be set with extreme care Yes it means the values will be set with well done analysis w.r.t to its intended usage and it doesn't mean the protocol will be dropping an essential feature or should be covering up for an existing bug in the codebase by explicitly limiting the feature/values solely due to the bug, even when the actual analysis for the ideal configuration/value determines a value that would cause issues due to the bug

[WangSecurity]

And it is not a specific action (setting to value A etc. an example for which would be setting the loan-to-collateral value to large values) but the full feature itself (dust increase) which is essential, has been present in the MakerDAO system since inception and is expected to be used. The current contracts are getting added to this already existing system. Wherever the new contracts makes explicit-problematic assumptions about the already existing system it is clearly mentioned by the team too under the design decisions made/known issues and explicitly state the acceptable risks for each known issue section.

Excuse me, it seems there was confusion from my comment. I didn't imply that the problem is in the entire feature of increasing the dust value and that it won't be used. I agree that it's a viable scenario where the governance would increase the dust value.

As I said previously, no assumption is being broken here. The protocol never assumes that positions having debt below dust will not exist. The condition of tab >= ilk.dust is an enforcement kept on the frob functionality but not an assumption of the protocol. If it helps to differentiate b/w enforcements of functionality and underlying assumptions, similar check exists in the frob functionality for the liquidation ratio/health of the position, that doesn't mean that the protocol assumes that no position in the protocol will have bad health. The enforcement is to prevent such positions from being created via the frob functionality.

And I believe here's the place where we have the misunderstanding. I believe the assumption from your comment here is broken, i.e. But if even when there are bidder's wanting to bid at 900-850 but due to a mistake in how the auction is implemented it cannot be executed for the price ranges 1000-100, effectively making the auction start at a reduced price of 99, then it is clearly an issue that causes loss of funds. Here the existence of the bug mentioned in the report makes the auction non-executable in price ranges where it is supposed to be executable. The broken assumption is that the auction has to be executable in its price ranges, but due to the governance setting dust value above the tab (or debt) value, the auction will be executed out of range causing a loss of funds. To quickly clarify, but it seems we all agree, I believe we should treat governance as the admin here. Hence, I believe it's the admin action (setting dust above tab) which breaks a certain assumption about the functioning of the code (auctions are executed out of their ranges) causing loss of funds.

Yes it means the values will be set with well done analysis w.r.t to its intended usage and it doesn't mean the protocol will be dropping an essential feature or should be covering up for an existing bug in the codebase by explicitly limiting the feature/values solely due to the bug, even when the actual analysis for the ideal configuration/value determines a value that would cause issues due to the bug

Again, excuse me, I didn't mean to say this feature won't be used at all. But, what I see now is that this line about governance configurations is similar to our previous trusted admin rules and we have to assume that the admin (in this case governance) will do their best to not cause any issues. Hence, in that case, I agree that this feature would be used, but in a way to not cause any issues to users (e.g. increase, then decrease if needed and return).

Hence, my decision remains, accept the escalation and invalidate the issue.

[10xhash]

1. "..... executable in its price ranges, but due to the governance setting ......"

It is not due to the governance doing xyz, that is only a precondition. What causes the auctions to not be executable is the bug mentioned above, ie. incorrect method (ie. frob) is used to refund the excess which will cause a revert. If this bug is fixed, governance increasing the dust will not have any such impact on the auction. So the sentence would be like if the governance increases dust, due to the bug in the contract ....

2. "..... it's the admin action (setting dust above tab) ......"

I believe you are associating the admin action as need to set above tab rather than seeing this as a normal usage of the dust increase feature. If the earlier dust was 10, there will be positions created across all values of tab starting from 10 to xyz. If the admin has to ever use the dust increase feature, let us say to 15, there will inevitably be positions that are below 15. And if you are under the assumption (unlikely but just to clarify) that dust is set targeted at a per position level, it is not and it is a global setting.

3. "I believe it's the admin action (setting dust above tab) which breaks a certain assumption about the functioning of the code (auctions are executed out of their ranges) causing loss of funds"

As I said earlier the admin action is only a precondition. The rule in discussion states An admin action can break certain assumptions about the functioning of the code and not All issues that has an admin action as a precondition is invalid, which are 2 different things and the certain part of the rule is of importance. The intent of the above rule is to not consider as valid those issues where an admin consciously accepts a deviation from the normal behavior, often in-spite of some negative consequences for the sake of overall good. I am attaching the screenshots of the comments provided by the previous head of judging regarding the same.

https://discord.com/channels/812037309376495636/881726370370158592/1219227167104434218

This is vastly different from a functionality that is bugged, but requires an admin action to be triggered. Here the admin is not considering the effects of the bug to be acceptable (team comment: ....but the system intent is to actually get closer to that. In this case, a bug is blocking (in a specific situation) to work normally....) while in the scenario covered by the rule, admin consciously performs actions that results in a suboptimal but intended state in which certain assumptions about the usual working of the protocol may be broken. Rather than bringing overall good, the bug here causes losses to the protocol too (looses the exit fee) and not just the user

Scenario covered by the rule:

• no bug is present in the codebase
• admin accepting a suboptimal situation where certain assumptions about the usual working of the protocol are broken. this is intended behavior after the admin action
• won't fix because there is nothing to fix and post the admin action the contract is supposed to behave like that

Scenario in discussion:

• bug in the contract
• admin performing an action will trigger the bug in the codebase and the arising scenario is not intended/expected by the admin
• will fix because there is an actual bug

Situations covered by the above rule exist in the codebase, an example for which would be, on a dust increase one cannot withdraw collateral even if their position maintains good health (a general assumption might be that user's are able to withdraw how-much-ever collateral they want if they maintain their health ratio. Here there is no bug, it is unusual but is the intended way on how the contract should work after the admin increases dust) etc.

I am putting an example contract here to showcase the difference if it helps. The bug in the below contract is that when reading the prizeAmount from storage, the entire slot is read and no cleaning is performed. Since the pauseParticipation variable also shares the same slot as the prizeAmount, setting pauseParticipation to true will result in the contract incorrectly interpreting the prizeAmount to be above 2**127 and award all the tokens as a reward. But for this to happen, a precondition is that the admin has to set the pauseParticipation to true for which the intent of the admin is to just disable new participation and not change the prizeAmount in any way. Similar to the issue in the report, this is an actual bug and cannot be argued to fall under admin action is breaking certain assumptions of the functioning of the code ie. admin setting pauseParticipation will break the assumption that prizes are distributed correctly because it is caused by the bug present and not an accepted behavior following the admin action

contract AdminAction {

    // both variables will be stored in the same slot since combined doesn't overflow 32bytes
    uint128 prizeAmount;
    bool pauseParticipation;

    // admin action, pause new participation for some time
    function toggleParticipation() public onlyAdmin {
        pauseParticipation = !pauseParticipation;
    }

    // protocol will set a value higher than 2**127 as a wildcard to reward all the balance of this contract
    function setPrizeAmount(uint128 _prizeAmount) public {
        prizeAmount = _prizeAmount;
    }

   function claimPrize() public {
        require(msg.sender == winner);

        uint prizeAmount_;
        assembly {
            prizeAmount_ := sload(prizeAmount.slot)
        }

        if(prizeAmount_ >= 2**127){
            prizeAmount_ = address(this).balance;
        }

        payable(winner).transfer(prizeAmount_);
        delete winner;
    }

    // ------------rest dont matter for explanation, just shows that pauseParticipation is intended to merely pause the participation 
    address winner;
    uint minDepositAmountForEligibity = 1 ether;

    event NewParticipant(address user);

    function takePart() public payable {
        require(!pauseParticipation);

        if(msg.value >= minDepositAmountForEligibity){
            emit NewParticipant(msg.sender); 
        }
    }

    function setWinner(address _winner) public {
        winner = _winner;
    }
}

Regarding admin configuration, admin is always TRUSTED here and as said in my earlier comment, they are expected to set the value after doing the required analysis correctly.

"Hence, in that case, I agree that this feature would be used, but in a way to not cause any issues to users (e.g. increase, then decrease if needed and return)."

Using this feature will cause the above issue. I don't understand what you mean by (e.g. increase, then decrease if needed and return) but if you mean some kind of method to avoid the occurence of this bug (by incorporating weird methodologies that a TRUSTED admin would not be using inorder to perform the action unless the bug was present), then it would be a workaround of the bug and not a scenario of TRUSTED admin or governance setting value with care, because setting any value (higher than earlier ie. increasing dust feature) can result in the above issue

[IllIllI000]

Prior rulings are not sources of truth, esp from prior heads of judging and earlier versions of rules, but even if they were, this finding is very similar to the current one (bug when admin changes the value), and was ruled to be invalid because we assume that the sponsor knows about the unclear behavior, unless there is explicit proof that it's not the case. If you read through the bug and discussion, you'll see it's the same sort of issue as here. The "intended to be used mid-operation" here would be during an ongoing liquidation, and the readme would have explicitly mentioned that use case

[panprog]

Agree with @IllIllI000 We can say that admin dust increase action is not intended to be used during ongoing MKR liquidations. If admin increases dust only when there are no active liquidations, the issue described here can not happen. Yes, this is not mentioned anywhere in the docs, but admin is assumed to know consequences of admin actions, and this is one of them. Maybe the issue is then informational, so that admin knows better about consequences of dust increase, but by Sherlock rules this is still not Medium.

[escalation-lawyer]

The LSWs are trying their absolute best to downgrade the issue. But there seems to be a very big hole in all their arguments.

Let's examine the sponsor response carefully again:

In our opinion, this is not part of an admin (governance) mistake, as it can not ensure that there won't be liquidations when a dust increment is being added to a spell (there is a time to vote for the spell + a timelock to actually execute it).

There is a very big difference between an admin action that is executed during ongoing liquidations and an admin action that takes some time to execute and coincides with an ongoing liquidation. As the sponsor mentions, the admin has no control over the latter, therefore this report does not fall under admin mistake.

[panprog]

There is a very big difference between an admin action that is executed during ongoing liquidations and an admin action that takes some time to execute and coincides with an ongoing liquidation. As the sponsor mentions, the admin has no control over the latter, therefore this report does not fall under admin mistake.

This is not true. The spell can include a check that LockstakeClipper.count() returns 0 (the number of active MKR liquidation auctions). This means that the spell will revert until all auctions are finished, so it can only be executed when it's safe to increase dust.

[escalation-lawyer]

Yes, what you are saying is that the admin should include this line of code LockstakeClipper.count() in the spell,, but they can only include it if they know about the bug in this particular report.

We can also say the admin can choose not to deploy any of the contracts to avoid all the bugs, then there will be no longer any valid bugs in any Sherlock contest 😂

[panprog]

Yes, what you are saying is that the admin should include this line of code LockstakeClipper.count() in the spell,, but they can only include it if they know about the bug in this particular report.

I think nobody challenges the validity of the issue - it is obviously a valid issue/bug. It might be medium in the other platforms. But according to Sherlock rules this is not a valid medium. Here are some excerpt from the Sherlock rules regarding the trusted roles:

III. 5. (External) Admin trust assumptions: When a function is access restricted, only values for specific function variables mentioned in the README can be taken into account when identifying an attack path. If no values are provided, the (external) admin is trusted to use values that will not cause any issues. Note: if the attack path is possible with any possible value, it will be a valid issue. ... VII. 5. Admin Input/call validation:

1. Admin could have an incorrect call order. Example: If an Admin forgets to setWithdrawAddress() before calling withdrawAll() This is not a valid issue.
2. An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue.

Admin is assumed to know different consequences of his actions and is trusted to either let them be (point 2 above, then it's not valid even if causes loss of funds) or to only call these actions with certain values or in certain correct order (points 1 and III.5 above). Correct call order also implies that each admin function can only be called in certain conditions known by admin, regardless of whether all these conditions are described anywhere in the readme/docs.

This issue falls under these rules: the correct order/condition for the admin would then be to check LockstakeClipper.count() == 0 and only then increase dust. Note: this condition is not mentioned anywhere and might not be obvious and we don't know if admin is aware of it, but none of this is required by the rule: if nothing is listed in the README in the values set by admin, then admin is trusted to set it not to cause any issues. And since README says "No / N/A" to all admin/permissioned function questions, this is exactly the case.

[escalation-lawyer]

Ladies and gentleman of the jury, I hope it is now crystal clear what the LSWs are trying to do. They are not interested in trying to offer any concrete arguments, instead they are now trying to throw out convoluted arguments in an attempt to confuse the judge and twist the following Sherlock rule to their favour:

An admin action can break certain assumptions about the functioning of the code. Example: Pausing a collateral causes some users to be unfairly liquidated or any other action causing loss of funds. This is not considered a valid issue

They are trying to claim now that the admins are somehow supposed to know that this bug exists before this report was submitted, and that they can workaround this bug by including an extra line of code in the spell (AKA governance proposal), therefore making this bug invalid. This is circular reasoning.

And here is the thing, if the sponsors already knew about this bug, then in the first place this bug would not have existed. It would have been fixed in the vat (using grab instead of frob) rather than the spell. Thus the existence of this bug contradicts what they are claiming.

Next, I must also warn everyone what happens when such type of reasoning gets accepted on Sherlock. If we accept this now, then anyone can claim that the admin action of initializing and deploying any contract is an admin action that allows it to be exploitable to any bug, therefore any bug submitted on Sherlock is now not valid.

It is imperative that such reasoning be rejected and thrown out.

[WangSecurity]

@nobodytrue @1-million-dollar-lawyer (some of) your comments were hidden/deleted because they don't add any value to the escalation and the report and are off-topic.

I agree with @panprog and @IllIllI000 here. This issue still arises if and after the admin makes an action. Moreover, as was mentioned above there can be a correct way to make spells to update (increase) dust and not cause any issues/losses for the users.

I see the argument that the scenario described here is not an intended one, rather than the one expressed in the rule example. But, I still believe it’s the admin action (increasing the dust value above tab) breaking certain assumptions about functioning of the code (the liquidation auctions are not executed in the appropriate range).

Also, about the admin mistake, excuse me if my comments seemed to imply it, they didn’t. About the argument “admin not knowing the bug”, I believe it’s not a viable argument, and it was never treated as such, since it’s very subjective. Moreover, as I understand there's no concrete argument from the time of the contest that would show the admin wouldn't use LockstakeClipper.count() == 0 in spells, besides the information provided after the contest. Moreover, @panprog is correct that if we don't have anything flagging such behaviour during the contest, then we have to assume the admin (in this case governance) would do everything they can to not cause any issues.

The decision remains the same, accept the escalation and invalidate the report.

[10xhash]

@WangSecurity

Using LockstakeClipper.count() == 0 is fundamentally flawed as this disables the entire dust increase feature forever incase there occurs a bad auction ie. one which is not going to be completed due to it resulting in a loss for a filler unless the filler themselves are ready to accept the loss. And it is outrageous that such methods are accepted as imaginary-intended working of the protocol inorder to invalidate this issue when you can clearly see that increasing dust should be totally independent of the liquidations. The dust increase feature and liquidations have both been part of makerdao since inception with the lockstake clipper following their implementations as mentioned in readme. And you can check the already undergone spells to note that liquidations are of no relevance when making a dust increase nor does it logically make any sense for the feature of dust increase (and governance - because dust increase occurs in voted spells) to be DOS'd by an active liquidation which is a problem in itself

On the point of quoting certain rules to support some decisions. The rules are fine in itself and doesn't state to invalidate this issue in any way. But rules rely on sensible interpretations. The gist of all rules that are being put up is that admin should not mess up themselves or admin can knowingly accept negative consequences for greater good. It is the flawed interpretation of the rules likely fueled/misguided by the escalation comments that is resulting in you reaching a flawed conclusion. To see that your thinking is flawed and that there are mistakes made in interpreting the rules along the way, you can just take a look at the eventual result of the same: Sherlock doesn't incentivise users to find such issues which means that after an audit, clients are expected to have bugs in their codebase and lose funds even when admin makes absolutely 0 mistake. Because according to your interpretation neither I nor any other watson should submit this or any similar issue

To clearly know of all the assumptions that you are making and how you interpret the rules before reaching the decision, I want to have clarity on certain things

Do you agree that the argument being provided above is a work around for the bug that the admins were unaware of? Or do you think that the contracts are supposed to be like this and that the admins were intending to make spells with the liquidation count check before every dust update?

---

Sidenote: You tagged the wrong llll in the comment

[llll]

Hey guys yeah you tagged the wrong person but good luck with the project 😂

[WangSecurity]

@nobodytrue your comments are deleted for being inappropriate and off-topic.

Using LockstakeClipper.count() == 0 is fundamentally flawed as this disables the entire dust increase feature forever incase there occurs a bad auction ie. one which is not going to be completed due to it resulting in a loss for a filler unless the filler themselves are ready to accept the loss. And it is outrageous that such methods are accepted as imaginary-intended working of the protocol inorder to invalidate this issue when you can clearly see that increasing dust should be totally independent of the liquidations. The dust increase feature and liquidations have both been part of makerdao since inception with the lockstake clipper following their implementations as mentioned in readme. And you can check the already undergone spells to note that liquidations are of no relevance when making a dust increase nor does it logically make any sense for the feature of dust increase (and governance - because dust increase occurs in voted spells) to be DOS'd by an active liquidation which is a problem in itself

I understand, and I want to make sure it's not the main argument that I use. It was mentioned in the discussion above by @panprog as the way for admins to not use any issues and I only highlighted that, in fact, increasing dust in this manner won't cause an issue (as I understand, but if it's incorrect please correct me). Still, it's not my main argument and the sole reason to invalidate this issue.

On the point of quoting certain rules to support some decisions. The rules are fine in itself and doesn't state to invalidate this issue in any way. But rules rely on sensible interpretations. The gist of all rules that are being put up is that admin should not mess up themselves or admin can knowingly accept negative consequences for greater good. It is the flawed interpretation of the rules likely fueled/misguided by the escalation comments that is resulting in you reaching a flawed conclusion. To see that your thinking is flawed and that there are mistakes made in interpreting the rules along the way, you can just take a look at the eventual result of the same: Sherlock doesn't incentivise users to find such issues which means that after an audit, clients are expected to have bugs in their codebase and lose funds even when admin makes absolutely 0 mistake. Because according to your interpretation neither I nor any other watson should submit this or any similar issue

I think it aligns with my paragraph above. I agree that in this issue the admin mistake is controversial and as you remember from the start of this escalation, I agreed it wouldn't be a mistake for this to occur. But, my main concern here is not admin mistake and admin knowing/not knowing the bug. My decision is based on the admin actions rule as explained in the previous comments.

Do you agree that the argument being provided above is a work around for the bug that the admins were unaware of?

As I understand, the work around introduced by @panprog indeed allows the admin to prevent the issue, but as I understand, it's a completely viable for the admin to not to do so, as I understand from the link you provided.

Or do you think that the contracts are supposed to be like this and that the admins were intending to make spells with the liquidation count check before every dust update?

Again, as I understand, it's a completely viable situation that the dust would be increased mid-liquidations.

But, my decision still remains based on the rule of admin actions: admin action (increasing dust above tab) can break certain assumptions about the functioning of the code (liquidations are executed out of the price range) as expressed in the previous comments. Excuse me if my previous comment seemed that I refrain from this argument and claim this to be an admin mistake. My main argument remains the same and I only highlighted that @panprog was correct in their assumption that this issue could be prevented by adding LockstakeClipper.count() == 0, while I also agree you've got a fair argument this is not intended, based on the undergone spells.

Still my decision remains the same based on the admin actions rule. Planning to accept the escalation and invalidate the issue.

[10xhash]

@WangSecurity

I want a base to start off inorder to prove that the mentioned rules (including the admin action rule) are not applicable (or that certain unacceptable assumptions/incorrect interpretations are made) as else invalid/circular reasoning as mentioned by @1-million-dollar-lawyer in the now hidden-comment here will creep in. Hence why I asked you to determine which of the two mutually exclusive sides were you picking when making the decision. Rather than staying in vague about the exact details and the presumptions that are in place when a rule is being applied we can inspect each rule getting applied in the exact scenario so that there is full clarity on the rationale behind the decision making

Hence why I re-request you to pick the side based on which you are making the decision

1. Admins are unaware of the bug
2. Contracts are supposed to be like this and admins are aware of the bug

[panprog]

Another thing to consider for this issue is core reason. While the issue says it's the usage of frob instead of grab, if we dig deeper, it's actually the fact that frob reverts even for healthy accounts if debt is below dust even for collateral change actions. This is confirmed by sponsor:

Unfortunately frob has the dust limitation even when adding collateral and there is existing debt (which was not really needed).

@10xhash also mentions it:

There are intended consequences in this state too like one can't withdraw their collateral unless the debt is cleared or brought back over the dust value(even if the health ratio is maintained). But the mistake mentioned in the report causes the liquidations to happen incorrectly in the scenario.

So the issue with liquidation happens exactly because of this (known) issue in frob. The usage of grab instead of frob is just a workaround not to fix vat contract. Yes, such workaround fix is also possible, but a better fix, for real core issue fix, is to fix vat.frob function, which is out of scope according to README.

I'm not sure what are the rules in such case (known issue in out of scope code causing a different impact issue in the in-scope code, but it's also possible to fix it in the in-scope code). Intuitively, I think this should be out of scope, because if the frob issue is fixed, this issue won't exists. I realize the decision is already to invalidate based on a different rule, but still something to consider.

[nobodytrue]

I'm quite concerned about the judging process I've observed in this contest. It appears that the judge is heavily relying on the input of Lead Senior Watsons (LSWs) without conducting substantial independent research. Every invalidated issue in this contest seems to stem from LSW input rather than the judge's own analysis.

The reasoning used to invalidate this particular issue seems to involve complex justifications that don't fully address the core concerns raised by the original submitter. It's worrying to see arguments from certain LSWs, being accepted at face value without critical examination.

This approach to judging raises questions about the fairness and thoroughness of the review process. A more balanced evaluation that considers all perspectives and involves independent investigation by the judge would inspire greater confidence in the outcomes.

Now, go ahead and remove this comment since Sherlock does not allow any criticism.

[WangSecurity]

@nobodytrue this is discussion about escalated issues, not about giving feedback, especially, not constructive and subjective one. If you have feedback you should address it in Sherlock's discord and you're more than welcome to. I've warned you many times that your comments are off-topic and don't provide any value to the discussion.

@10xhash my decision is based on the admin actions rule which I believe to be applicable here and it doesn't imply admins knowing/not knowing the bug. The question about admin knowing/not knowing the bug applies to your and @panprog comments here and here.

I see that in messages from the previous HoJ you've sent here said that the admin actions rule means the admins should be aware of consequences of their actions and I believe it applies here. As I've said earlier I still believe this issue fits the admin actions rule and I stand by this.

The decision remains the same, accept the escalation and invalidate the report.

[10xhash]

@WangSecurity

my decision is based on the admin actions rule which I believe to be applicable here and it doesn't imply admins knowing/not knowing the bug

I see that in messages from the previous HoJ you've sent here said that the admin actions rule means the admins should be aware of consequences of their actions and I believe it applies here

This is pure contradiction if you say that admins not knowing the bug has no implications on the admin actions rule. Because the clarification from the previous HOJ which you align with literally says that admins should be aware of the negative consequences and still be executing such actions for greater good. So this issue cannot be attempted to be classified under admin actions rule until you take the side of "Contracts are supposed to be like this and admins are aware of the bug"

An admin should be aware of the negative consequences of their action and may still want to execute those actions for a greater good, for example prevention of bad debt in the above example

[WangSecurity]

I see where the misunderstanding comes from, sorry for poor phrasing. I believe it's a completely viable scenario that the admin/governance would increase the dust amount during the ongoing liquidation, that's what I meant the admin mistake is no applied here. But, I believe in this case the admin should be aware of this consequence when they increase dust during liquidations, unless there's a concrete argument from the time of the contest that the admin is not aware of this consequence of liquidation auction going out of the price range. That's why I think the rule is applicable and the admin should be aware of this situation. Again, excuse me for the confusion, hope this clarifies your concern. The decision remains, accept the escalation and invalidate the issue.

[escalation-lawyer]

But, I believe in this case the admin should be aware of this consequence when they increase dust during liquidations, unless there's a concrete argument from the time of the contest that the admin is not aware of this consequence of liquidation auction going out of the price range.

The admin need not be aware of this consequence. I have already explained why but to reiterate:

As the sponsor already mentions here: https://github.com/sherlock-audit/2024-06-makerdao-endgame-judging/issues/107#issuecomment-2296491358

In our opinion, this is not part of an admin (governance) mistake, as it can not ensure that there won't be liquidations when a dust increment is being added to a spell (there is a time to vote for the spell + a timelock to actually execute it).

The admin (governance) action of increasing the dust will takes some time to execute before coinciding with an ongoing liquidation. Therefore, what is happening here is not

increase dust during liquidations

It is instead:

a proposal (spell) that will take some time to execute to increase dust during liquidations

Which is a very big difference.

[WangSecurity]

@1-million-dollar-lawyer I understand, thank you for re-iterating over this again, but I still stand by my previous decision. Planning to accept the escalation and invalidate the issue.

[escalation-lawyer]

I honestly do not understand, you are asking for a concrete argument to:

But, I believe in this case the admin should be aware of this consequence when they increase dust during liquidations

And I already have explain why the admin need not be aware, because they have no control on whether there will be any ongoing liquidations when the spell executes and yet you are still remaining firm on your decision?

[10xhash]

I see where the misunderstanding comes from, sorry for poor phrasing. I believe it's a completely viable scenario that the admin/governance would increase the dust amount during the ongoing liquidation, that's what I meant the admin mistake is no applied here. But, I believe in this case the admin should be aware of this consequence when they increase dust during liquidations, unless there's a concrete argument from the time of the contest that the admin is not aware of this consequence of liquidation auction going out of the price range. That's why I think the rule is applicable and the admin should be aware of this situation. Again, excuse me for the confusion, hope this clarifies your concern. The decision remains, accept the escalation and invalidate the issue.

@WangSecurity

You can see the following contextual evidence to verify that the team is unaware of the above consequence of a dust increase:

• the consequence itself is that both the user and the protocol will lose assets which is trivially not intended by any admin
• if the protocol has the ability to acheive the same intended end result (ie. increasing the dust parameter) without incurring a loss for the protocol and its user's, solely by not using an incorrect way to move assets (ie. frob) they would be obviously correcting that (if they are aware of the bug)
• when an auction finshes, the intent inside onRemove function is to simply return back the leftover collateral from the auction and it doesn't make sense to keep the enforcements present in frob for this, which is what turns out to be problematic
• there is no fundamental reason on why liquidations should be made to revert after a dust update. any debt protocol targets to finish off their liquidations at the best possible prices earliest
• not mentioned in any accepted risks/known issues

[WangSecurity]

@escalation-lawyer I see that there might be no liquidations during voting for increasing the dust, but they might appear when it’s time to execute the spell, it doesn’t make the admin/governance less aware of the negative consequences.

@10xhash Thank you for these arguments. About the first two, the rule doesn’t imply that protocol’s loss of funds cannot lose funds. The example in the rule and the screenshots about it you’ve sent show that if the protocol pauses the protocol to prevent bad debt, can make the debt even greater cause other users cannot repay their collateral. About the third, I believe it’s within the scope of the rule that the admin would break the assumptions of functioning of the code with their actions. About the fourth, I agree it’s the intent of the liquidations generally, but that doesn’t make the admin less aware of the issue and it’s within the rule of the admin actions breaking the assumptions of functioning of the code. About the last, I believe that’s one of the intentions of the rule to cover these cases when they’re not specified as known issues, but caused by admins.

Hence, the decision remains the same, accept the escalation and invalidate the issue.

[10xhash]

@WangSecurity

point 2 : So you are saying that here the team is indeed intending to lose the protocol funds and the user's funds by invoking an incorrect method to move assets / Before the contest itself the team knew that increasing dust will result in a loss of funds for protocol and users and it is intended?

[WangSecurity]

point 2 : So you are saying that here the team is indeed intending to lose the protocol funds and the user's funds by invoking an incorrect method to move assets / Before the contest itself the team knew that increasing dust will result in a loss of funds for protocol and users and it is intended?

I didn't say it's intended, I've said that the rule doesn't imply that it's only about users losing funds, but may also result in protocol losing funds, as the example in the rule. The rule is about breaking the certain assumptions of the functioning of the code, i.e. making the protocol work in unintended way. I agree that losing funds, either protocol's or users' is not intended, but the rule is about breaking the intended behaviour with admin actions. I've said the admins should be aware of the consequences of their actions which I believe is the case.

The decision remains the same, accept the escalation and invalidate the issue.

[10xhash]

@WangSecurity

Since you are tying my previous message with the intended word, i am rephrasing the same question by using the aware word:

So you are saying that here the team was indeed aware that it will lose the protocol funds and the user's funds by invoking an incorrect method to move assets and still decided to do so / Before the contest itself the team knew that increasing dust will result in a loss of funds for protocol and users and still decided to do so?

I think this sentence from your reply means that your answer to the above question is YES? If not can you please give a YES/NO answer to the above question?

I've said the admins should be aware of the consequences of their actions which I believe is the case

[nobodytrue]

For what reason is the judge disregarding the arguments presented by the Watsons? The justification provided for dismissing this matter is fundamentally flawed.

[WangSecurity]

So you are saying that here the team was indeed aware that it will lose the protocol funds and the user's funds by invoking an incorrect method to move assets and still decided to do so

No, I wouldn't say the team was aware of using the incorrect method to move funds

Before the contest itself the team knew that increasing dust will result in a loss of funds for protocol and users and still decided to do so?

My answer is between yes and no, I wouldn't say that the team was aware it 100% will result in a loss of funds, but since there's explicit check that the debt amount has to be less than dust amount, I believe the admin should be aware that admin increasing dust may result in loss of funds. If my response is still unclear, ask what needs to be clarified.

The decision remains, planning to accept the escalation and invalidate the issue as it is.