Ethereum

The token contracts used in each repository are known in advance and there is no use of arbitrary tokens in any of the contest modules:

• In the nst module, apart from the NST token itself only DAI is used (in the DaiNst converter).
• In the ngt module, apart from the NGT token itself, only MKR is used (in the MkrNgt converter).
• In the snst module, apart from the SNST token, only NST is used (as the deposit token).
• In the vote-delegate module only MKR and the existing Chief's IOU tokens are used.
• In endgame-toolkit the farm types to be used through different deployment phases are (using rewards/stake notation): NGT/NST, SDAO/NST, NGT/SDAO, NST/LSMKR and SDAO/LSMKR (the last two types are only for lockstake).
• In the lockstake module only MKR, NGT, NST and LSMKR are used (plus the two farms types mentioned above).

Issues stemming from potential different future implementations of NST and SNST (due to their upgradeability) are out of scope.

All the above means that there is no need to analyze potential use/integration of any other token code (which could potentially have weird behaviour) in any of the modules.

No

No

N/A

Optionally Compliant
ERC20: NST, NGT and SNST tokens.
ERC4626: SNST

Public Keeper Bots
Endgame Toolkit: VestedRewardsDistribution.distribute()

• No input data needed
  Smart Burn Engine: vow.flap() -> Splitter.kick()
• No input data needed

Arbitrage Bots
LockStake Engine: LockstakeClipper.take()

• Input parameters are Auction id, collateral, and bid amounts. This information can be found in the event emitted by kick- Kick(id, top, tab, lot, usr, kpr, coin)

None

Not deployed to L2.

No

Please refer to https://github.com/makerdao/sherlock-contest/blob/9a01337e8f82acdf699a5c1c54233636c640ca89/README.md, and the documentation present in the codebases.

Please refer to https://github.com/makerdao/sherlock-contest/blob/9a01337e8f82acdf699a5c1c54233636c640ca89/README.md, and the documentation present in the codebases for a list of known issues and general disclaimers for this contest.

No

https://github.com/makerdao/nst/tree/sherlock-contest/audit
https://github.com/makerdao/ngt/tree/sherlock-contest/audit
https://github.com/makerdao/sdai/tree/sherlock-contest/audit
https://github.com/makerdao/endgame-toolkit/tree/sherlock-contest/audits
https://github.com/makerdao/dss-flappers/tree/sherlock-contest/audit
https://github.com/makerdao/univ2-pool-migrator/tree/sherlock-contest/audit
https://github.com/makerdao/vote-delegate/tree/sherlock-contest/audit
https://github.com/makerdao/lockstake/tree/sherlock-contest/audit

Please find additional information about the codebases here: https://www.notion.so/jetstreamgg/Maker-Endgame-Launch-Sherlock-Audit-Contest-Scope-641baee4028548ccbb3783f2278c3215

Severity Definitions:
We are building on top of the current Sherlock severity definitions apart from changes explicitly mentioned (for example see about functionality breaking). However, we are giving guidance to the words that describe loss.

Sherlock's Medium definition:

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.

"a loss is highly constrained". As a guideline for this contest, a highly constrained loss is a loss of up to 5% of the affected party (both protocol and user).

"The losses must exceed small, finite amount of funds". As a guideline for this contest, small, finite amount of funds are 0.5% of the affected party (both protocol and user).

With this clarification

Any loss smaller than 0.5% can never be Medium
Any loss between 0.5% and 5% loss can be Medium at most
Any issue larger than 5% can be Medium or High (depending on constraints)
If a single attack can cause a 0.01% loss but can be replayed indefinitely (assuming little to no costs), it will be perceived as a 100% loss. Note that in most modules governance can step in within hours (aka Mom contracts), or otherwise if needed plus the governance pause delay to halt the system. This should be taken into account when determining if replaying indefinitely is possible. For the contest we assume 2 hours from the point an exploit starts until a delay-bypass Mom contract executes and 50 hours for a fix that requires governance delay (including the delay).
For protocol losses, it must be demonstrated that the losses exceed the above percentage assuming protocol reserves of 100m+. For user losses, it must demonstrate those losses with the user's 10k+ of value locked/vulnerable as part of the attack.

In the lockstake case, the maximal locked MKR is assumed at $250m and the maximal line is assumed as 100m dai. A user in the lockstake case is a single urn.

For the SNST case, the maximal locked NST amount is assumed as 1B DAI.

Rules:
The protocol chooses to override at least the following from https://docs.sherlock.xyz/audits/judging/judging. Other changes may also be communicated through the competition website or elsewhere.

"Breaks core contract functionality, rendering the contract useless or leading to loss of funds." Breaking any kind of functionality is not a medium or high severity issue for this competition, only loss of funds.

"The protocol team can use the README (and only the README) to define language that indicates the codebase's restrictions and/or expected functionality." Any public material should be valid as known issues for this competition.

"Issues that break these statements, irrespective of whether the impact is low/unknown, will be assigned Medium severity." Even if an intended functionality is broken but there is no material loss of funds then it is not a medium or high issue for this competition.

"Example: The README states "Admin can only call XYZ function once" but the code allows the Admin to call XYZ function twice; this is a valid Medium" This shouldn't be a valid medium if there is no loss of funds.

"EIP Compliance: For issues related to EIP compliance, the protocol & codebase must show that there are important external integrations that would require strong compliance with the EIP's implemented in the code. The EIP must be in regular use or in the final state for EIP implementation issues to be considered valid" There is no commitment with regards to EIP compliance. On top of that, any loss of funds incurred in an integrating contract is out of scope.

"User input validation: User input validation to prevent user mistakes is not considered a valid issue. However, if a user input could result in a major protocol malfunction or significant loss of funds could be a valid high." Any user mistakes resulting in their own funds being lost is out of scope.

Please refer to https://github.com/makerdao/sherlock-contest/blob/9a01337e8f82acdf699a5c1c54233636c640ca89/README.md, and the documentation present in the codebases for a list of known issues and general disclaimers for this contest.

Also see https://hackmd.io/@h3li0s/rk3x9uFw0