QA Report

[c4-submissions]

See the markdown file with the details of this report here.

[bytes032]

3 r 10 nc

contracts

1 r

2 nc

3 nc

4 nc

5 bot

6 bot

7 r

8 r

system-contracts

1 nc

2 nc

3 nc

4 nc

5 nc

6 nc

era-zkevm_circuits

1 nc

[ustas-eth]

contracts

• 1 is a duplicate of https://github.com/code-423n4/2023-10-zksync-findings/issues/501

• 2 is a duplicate of https://github.com/code-423n4/2023-10-zksync-findings/issues/260 I argue differently in this one but point out the same functions in code. My issue is very similar to this one: https://github.com/code-423n4/2023-10-zksync-findings/issues/210:

  • updateDelay can be set to 0
  • updateSecurityCouncil() doesn't validate the address (can be set to the owner themself or 0) The centralization (and thus the possibility of misuse in case of a private keys theft) was also mentioned in my Analysis: https://github.com/code-423n4/2023-10-zksync-findings/issues/576 The need for validation of updateSecurityCouncil() was also mentioned in number 6 of this QA.

• 4 is a duplicate of Ladboy's QA report number 3: https://github.com/code-423n4/2023-10-zksync-findings/issues/984. In that report, it is considered a recommendation; in mine, it is considered a non-critical.

• 7 is a duplicate of https://github.com/code-423n4/2023-10-zksync-findings/issues/670 and https://github.com/code-423n4/2023-10-zksync-findings/issues/192

system-contracts

• 2 is a duplicate of L‑04 in https://github.com/code-423n4/2023-10-zksync-findings/issues/314. In that report, it is considered a low; in mine, it is considered a non-critical.

[nethoxa]

About your 2 regarding my submission, its point was that if either governor or the security council got compromised, the whole governance mechanism was broken, even when its purpose was to prevent exactly that. It's not about the misuse of their privileges to act untrustworthy, as it is what you talk about in your analysis and your QA like setting delay to 0 and bypass the timelock or doing shadow upgrades, which are gonna be used only to fix bugs in production. Those are different things. It's true that you say:

"Despite this arrangement, there remains a potential risk of organized manipulative actions or the theft of private keys from multiple members of these multisig wallets. As a result, the community must actively monitor these multisigs to promptly respond to any undesirable actions or events."

But you do not even mention anything about the flawed trust model, it's just a vague sentence regarding theft of keys. Moreover, the security council/delay being set to 0 at deployment can be easily checked via etherscan/cast and the community would notice that pretty fast, so it's not a real threat and via shadow upgrades is not possible, as security council can ask for the operation and check if its hash match the one that has been submitted by governance, so it is not possible to pass a "hidden payload" to trick the security council without them knowing.

[c4-judge]

GalloDaSballo marked the issue as grade-c

[c4-judge]

GalloDaSballo marked the issue as grade-b

[GalloDaSballo]

After reviewing 2.

I don't believe it is a duplicate

This finding asserts that the owner could change the council, but 260 acknowledges that this has a delay and that the council would cancel that

Am keeping as is

[c4-judge]

GalloDaSballo marked the issue as grade-a

[GalloDaSballo]

Given the penalty on 155, am raising this report to A due to high quality submissions