Rubicon contest - throttle's results

Duplicate of #316

Duplicate of #125

Duplicate of #21

I believe this argument is the same as #110

Yeap, duplicate of #110. The case for loss of funds is gray; a user putting up an offer that is worse than the market rate would be under the classification of "user-error" bugs that typically see a medium severity.

Company centralization is an acknowledged risk in the system in v1. See the future works section of our white paper ;)

It's great that wardens raise up rugpull vector concerns so that the sponsor is at least aware of it. I've deliberated much over how to best group these issues regarding centralization and owner privilege risks, and would like to explain my rationale and thought process.

Background

A precedent has been set from a previous contest finding where all issues were grouped together. Meanwhile, some wardens have pointed to the Insure contest where multiple high severity findings stem from the fact that a compromised owner is able to rug user funds through various means.

In this case, we have 2 groups of privileged access controls: the admin and the strategist(s). As it stands currently, the team is the sole strategist (stated in the future works section of the whitepaper), keeping the risk level the same as the admin. Different wardens have showcased how the admin and strategist is able to cause the loss of funds in multiple ways.

The README stated that "BathHouse has an admin that is the EOA administrator of the entire protocol in v1.", which in my opinion, favours the wardens' POV of the likelihood of rugpulling should the wallet be compromised. It is unclear if the admin and strategist shares the same EOA. In practice, I hope that they aren't.

I note that the strategists can potentially be increased in size, so the likelihood and risk of a malicious attack is greater in that regard.

On the other hand, the README stated the following:

Note that the Bath Token looks to both the Bath House (via onlyBathHouse) and the Bath Pair/strategists (via onlyPair) as permissioned actors. The Bath House admins key storage variables while strategists access funds and manage liquidity positions

The (weak) implication is that there is an acceptable trust assumption we can make about the admin and strategist(s). I am therefore in favour of keeping the medium severity rating for the issues raised.

Classification and thought process

The issues raised about rugpull vulnerabilities via centralisation risks can be broadly classified into 2 categories:

1. Those that can be mitigated with contract modifications. Examples include:

• ensuring upper / lower proper bounds on key variables (fees not exceeding max threshold, for instance)
• adding safeguards and conditional checks (require statements)

2. Those that can't be strictly enforced

• Use multisig, put admin under timelock

While the premise is the same (assume strategist / admin is compromised), there is a spectrum in the write-up quality of issues. Some are generic in nature and are of low value, while others have written POCs and explained the potential impact in great detail.

It would be ideal and fair to reward wardens who provide meaningful context and details more than those who don't. Hence, in this regard, it makes sense to split up the issues based on the various attack vectors described by different ones.

Yet, there may be those who did spot these rugpull vulnerabilities, but chose not to mention them because of the privileged access and assumed that the risk was acceptable. I would like to encourage those who fall in this category (me being 1 of them :p) to raise these issues nonetheless, unless explicitly told otherwise / stated in the README that it is a trust assumption by the protocol / out of scope. Better to have your issue looked at and invalidated than not at all!

Verdict

Category 1 can be separated into the various attack vectors and actors (admin / strategist), as the mitigation is more tangible in nature. This way, the recommended fixes can also be easily identified and adopted. A warden that grouped multiple attack vectors together will have their issue made the primary issue; the rest will be marked as duplicates of it. Examples: #249 and #157

Regarding category 2, for issues that are generic "put admin under timelock" without explaining how and why a compromised owner / strategist can rug, as per the rulebook ruling and judges' general consensus, I will downgrade their severity to QA. Those that explained the impact and vulnerability in detail will be grouped together with medium severity because there isn't much that can be done about it.

This issue falls under cat 2 - generic timelock recommendation. Downgrading to QA