Sky

Rewards are distributed according to the impact the vulnerability could otherwise cause based on the Impacts in Scope table further below.

Reward Calculation for Critical Level Reports

For critical Smart Contract bugs, the reward amount is 10% of the funds directly affected up to a maximum of USD 10 000 000. The calculation of the amount of funds at risk is based on the time and date the bug report is submitted. However, a minimum reward of USD 150 000 is to be rewarded in order to incentivize security researchers against withholding a bug report.

Critical website and application bug reports will be rewarded with USD 100 000 only if the impact leads to a direct loss in funds involving an attack that does not require any user action at all. An impact of minting tokens on-chain beyond intended activity without requiring any user action would also be rewarded this amount due to the undesired dilution of existing circulating tokens. All other impacts that would be classified as Critical, or an impact resulting in a theft of funds that does not fall under this definition, will be rewarded USD 50 000. For the Protocol Insolvency impact, the amount considered at risk is the amount that lenders cannot receive back.

For the Critical impact “Prevention of governance participation despite design parameters providing participation rights”, it is downgraded to High if the total amount of SKY that is being staked is less than the average “hat” amount of all active proposals with their respective highest value over 24 hours preceding the bug report submission. If the amount is greater, then it follows the scaling system for Critical impacts with funds affected, but with 1% instead of 10%.

Repeatable Attack Limitations

In cases of repeatable attacks for smart contract bugs, the amount of funds at risk will be calculated with the first attack being at 100% of the funds that could be stolen and then a reduction of 25% from the amount of the first attack for every 300 blocks the attack needs for subsequent attacks from the first attack, rounded down. For avoidance of doubt, if a second attack would happen at 600 blocks and then a third at 900 blocks, the funds at risk would be counted at 50% and 25% of the reward from the first attack, respectively.

However, for smart contracts directly holding funds that cannot be paused, if a discovered vulnerability includes the temporary locking of funds that could otherwise be withdrawn and thus prevented from being stolen but still accessible to the exploiter to take the funds, the time is extended to the exact same time as temporary locking. Extensions of the temporary locking that introduce a gap where withdrawals can happen will not be considered.

Reward Calculation for High Level Reports

High smart contract impacts will be capped at up to 100% of the funds affected. In the event of temporary freezing, the reward doubles for every additional 300 blocks that the funds could be temporarily frozen, rounded down to the nearest multiple of 300, up to the hard cap of USD 100 000. However, if it is within the hard cap, there is a further hard cap of 1000% of the funds affected with the minimum reward of USD 5 000. However, a temporary freezing impact with less than 150 blocks will be downgraded to Medium.

Further restrictions are placed on impacts of temporary freezing of funds of an already liquidated position:

• For up to 50120 blocks (approximately 1 week) it is considered as out of scope
• For 50120 blocks to 200480 blocks (approximately 4 weeks) it would be downgraded to Medium or Low at the discretion of the Sky team

Restrictions on Security Researcher Eligibility

Security researchers who fall under any of the following are ineligible for a reward:

• Compensated team members of any Sky or MakerDAO affiliate
• Employees and team members of third-party suppliers to a Sky or MakerDAO affiliate that operate in a technical capacity and have assets covered in this bug bounty program
• Team members and third-party suppliers of businesses and organizations that are not a Sky or MakerDAO affiliate but have assets considered as critical infrastructure covered under the bug bounty program

Public Disclosure of Known Issues

Bug reports covering previously-discovered bugs acknowledged below are not eligible for any reward through the bug bounty program.

• Considering MCD_ETH - The asset steward is aware that the balance of the contract may be different than the total amount that is deposited if users send ETH directly to the contract. They do not believe this has a negative impact on the system and so unless a report can show how having a higher balance does have negative consequences we will consider reports on the actual balance being higher than the sum of balanceOf values out of scope.
• Considering all adapters - The asset steward is aware that the balance (ETH or token) of the contract may be different than the total amount that is joined through the contract if users send tokens or ETH directly to the contract. They do not believe this has a negative impact on the system and so unless a report can show how having a higher balance does have negative consequences they will consider reports on the actual balance being higher than the sum of tokens 'join'ed out of scope.
• Vote-delegate
  • The need for expiration logic is not considered important enough anymore, social arguments against that are considered out of scope.
• Lockstake
  • Known issues mentioned here or in recursively linked material are considered out of scope - https://security.makerdao.com/liquidations-2.0
  • Delaying liquidations in the order of tens of minutes is assumed valid, there is already a big delay in Maker's oracle design.
  • wipeAll and wipe do not drip because it is actually not convenient for the user to do a drip call on wipping. Then, if we force the drip, we are incentivizing users to repay directly to the vat (which is possible) instead of using the engine for that. We are mimicking the old proxy actions behaviour, where we drip for drawing, as otherwise the user can lose money, but not forcing the drip on wiping so users actually use this function.
  • By the time lockstake goes live an OSM is assumed to be onboarded for MKR. Currently in Maker the MKR price is only used for the smart burn engine (dss-flappers), so doesn't yet need an OSM.
  • The issue of creating a large amount of auctions when the amount of DAI to raise would cause a partial liquidation (e.g small amount to reach hole or Hole ) is known already from dss and the existing clippers. It is known that carefully configuring dust, hole and Hole is important but is just a partial mitigation to this. In the context of lockstake it is known that it has additional implications such as delaying selectVoteDelegate (see Cantina audit's 3.3.2 informational issue), delaying re-farming, causing the exit fees not to be collected (as price might be lower due to many auctions), delaying the formal burning of system fees, and more. Also the fact that the locked MKR can not be used for governance operations is known (thus spells might not pass, governance decisions might be easier or harder to pass, etc..)
  • The formulas and calculations in the Readme's Exit Fee on Liquidation may not be accurate and are given for rough illustrative purposes.
  • On certain market conditions such as extreme price movements some of the exit fee may not be burned on liquidations. This is a known attribute of the system.
  • 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. Also the fact that the locked MKR can not be used for governance operations is known (thus spells might not pass, governance decisions might be easier or harder to pass, etc..)
  • Using the "stopped" states in the lockstake clipper is assumed to be used by wards in an extreme emergency. It is a known risk that some of the system attributes and functionality may not hold afterwards, including risking user and system funds. This also includes LSE special functionality (allowing exit of auctions leftover, not burning fees, delegating, staking, etc..).
  • As the Maker protocol has the ability to mint MKR and SKY tokens and also to migrate the Lockstake engine, any situation of locked user MKR/SKY should not be regarded as a high severity issue. It is assumed that a lockstake migrator/minter contract can be set up and go live within 5 days (including gov delay).
  • 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.
  • As with other collaterals, "tip" and "chip" are assumed to be chosen very carefully, while taking into account the dust parameter and with having in mind incentive farming risks.
• dss-flappers
  • Inefficiencies due to configurations or oracle frequencies/pricing are out of scope.
  • Slow/Unavoidable delay of withdrawing/redeeming the protocol funds in case of an emergency is known.
  • Possible sandwich attacks and MEV extraction scenarios are known issues. Maker's risk unit is assumed to be setting parameters while having these in mind.
  • The dss-flappers (SBE) solution assumes losing several percentages of funds by design during the Uniswap interactions due to slippage, MEV, sudden market movements, sandwich attacks, oracles imprecision and update resolution, etc. Obviously in this specific case the numbers mentioned in the severity definitions (e.g 0.5%) are irrelevant.
  • The fact that the SBE funds are not taken into account in protocol accounting or for flops auction triggering is known.
  • It is expected that governance sets parameters carefully during the module's life cycle, including maintaining splitter.hop as the same value as the farm's reward duration.
  • The combination of the governance configuration of vow.bump and splitter.hop is assumed to not allow spending more than 50K DAI per hour (in practice should be a much slower rate).
• endgame-toolkit
  • Any issue that exists in the original non-Maker Syntetix staking rewards contract is out of scope.

Previous Audits

Sky has provided these completed audit review reports for reference. Any unfixed vulnerability mentioned in these reports are not eligible for a reward.

• https://chainsecurity.com/security-audit/maker-protocol-liquidations-2-0/
• https://chainsecurity.com/security-audit/makerdao-g-uni-lp-oracle/ (narrowly scoped subsystem)
• https://chainsecurity.com/security-audit/makerdao-direct-deposit-module-d3m/
• https://chainsecurity.com/security-audit/makerdao-optimism-dai-bridge/
• StarkNet DAI Bridge audit
• StarkNet Teleport audit
• Direct Deposit V2 audit
• https://chainsecurity.com/security-audit/makerdao-dss-charter-smart-contracts/
• Lite PSM Audits
• https://github.com/makerdao/usds/blob/dev/audit/20231124-cantina-report-review-makerdao-nst.pdf
• https://github.com/makerdao/usds/blob/dev/audit/20240703-cantina-report-maker-nst.pdf
• https://github.com/makerdao/usds/blob/dev/audit/20240730-ChainSecurity_MakerDAO_NST_audit.pdf
• https://github.com/makerdao/sky/blob/dev/audit/ChainSecurity_MakerDAO_NGT_audit.pdf
• https://github.com/makerdao/sky/blob/dev/audit/ChainSecurity_MakerDAO_NGT_deployment_scripts_audit.pdf
• https://github.com/makerdao/sky/blob/dev/audit/cantina-report-review-makerdao-ngt.pdf
• https://github.com/makerdao/sdai/blob/susds/audit/20240703-cantina-report-maker-snst.pdf
• https://github.com/makerdao/sdai/blob/susds/audit/20240730-ChainSecurity_MakerDAO_Savings_NST_audit.pdf
• https://github.com/makerdao/endgame-toolkit/blob/master/audits/ChainSecurity_MakerDAO_Endgame_Toolkit_audit.pdf
• https://github.com/makerdao/endgame-toolkit/blob/master/audits/report-review-makerdao-endgametoolkit_final.pdf
• https://github.com/makerdao/lockstake/blob/dev/audit/20240626-cantina-report-maker-LSE.pdf
• https://github.com/makerdao/lockstake/blob/dev/audit/20240730-ChainSecurity_MakerDAO_Lockstake_audit.pdf
• https://github.com/makerdao/vote-delegate/blob/master/audits/ABDK-MakerDAO-Vote%20Delegate.pdf
• https://github.com/makerdao/vote-delegate/blob/v2/audit/20240703-cantina-report-maker-vote-delegate.pdf
• https://github.com/makerdao/vote-delegate/blob/v2/audit/20240730-ChainSecurity_MakerDAO_VoteDelegate_audit.pdf
• https://github.com/makerdao/dss-flappers/blob/master/audit/ChainSecurity_MakerDAO_FlapperUniV2SwapOnly_audit.pdf
• https://github.com/makerdao/dss-flappers/blob/master/audit/ChainSecurity_MakerDAO_FlapperUniV2_audit.pdf
• https://github.com/makerdao/dss-flappers/blob/dev/audit/20230606-ChainSecurity_MakerDAO_FlapperUniV2_audit.pdf
• https://github.com/makerdao/dss-flappers/blob/dev/audit/20230727-ChainSecurity_MakerDAO_FlapperUniV2SwapOnly_audit.pdf
• https://github.com/makerdao/dss-flappers/blob/dev/audit/20240904-ChainSecurity_MakerDAO_Dss_Flappers_audit.pdf
• https://github.com/makerdao/dss-flappers/blob/dev/audit/20240703-cantina-report-maker-flappers.pdf
• https://github.com/sherlock-protocol/sherlock-reports/blob/main/audits/2024.08.05%20-%20Final%20-%20MakerDAO%20Endgame%20Audit%20Report.pdf

Feasibility Limitations

Bug reports that require an attack that involve one or more other protocols (e.g. utilizing flash loans from a margin protocol or manipulating the spot prices on a DEX), either to make an attack more severe than it would be in isolation, or to achieve an attack that would otherwise be impossible or infeasible, would be out-of-scope. However, they will be considered as in-scope and categorized according to the program rules as long as all of the following are true:

• Losses or other negative effects of the attack are inflicted upon Sky ecosystem participants—MKR or SKY holders, DAI or USDS holders, Vault holders, or Keepers.
• The losses or other negative effects could be prevented via changes to the MCD smart contracts already included in the bounty scope.
• The additional protocols used must have enough liquidity in various assets to allow the attack to succeed at the time of bug report submission. For example: if an attack requires an ETH flash loan, but the amount is larger than all the ETH available for loan across the ecosystem

Proof of Concept (PoC) Requirements

• A PoC is required for all bug reports. All PoCs submitted must comply with the Immunefi-wide PoC Guidelines and Rules. Bug report submissions without a PoC when a PoC is required will not be provided with a reward.

Other Terms and Information

• Exceptions to the PoC requirement for smart contract bugs may be made in cases where the vulnerability is objectively evident from simply mentioning the vulnerability and where it exists. However, the bug reporter may be required to provide a PoC at any point in time.

• A manipulation of the votes or the voting result, as well as the modification of its display leading to a misrepresentation of the result or vote would also qualify for a reward of USD 100 000.

• Vulnerabilities that are exploitable in old versions of smart contracts and have since been mitigated (either deliberately or accidentally) in current versions (as demonstrated by the listing at https://chainlog.makerdao.com/) are not in-scope for the bug bounty program. In the event that a vulnerability exists on the GitHub file but not on the most recently deployed contract, this may be due to a “dark spell” to fix a vulnerability quietly. If your bug report is rejected as a known issue due to this, details will be provided to you.

• In order to be eligible for a reward, the vulnerability must exist in the deployed smart contract.

• https://chainlog.makerdao.com/ is designed to be easy to run locally. Hence, taking down the application/website is considered out-of-scope for this asset.

• All Medium and High level bug reports are not in-scope for the https://vote.makerdao.com/ asset. Only Critical severity reports are in-scope for this asset.

• Vote comments are stored in a database accessed by https://vote.makerdao.com/. The critical functionality of the site (e.g., voting) is in-scope, but non-critical voter comments are out-of-scope.

• If you discover a vulnerability with Critical impact on any deployed smart contract within the Sky codebase, you may submit it for consideration.

• The dai.js repo (https://github.com/makerdao/dai.js/ ) is NOT in scope even though it's a dependency of the Governance Portal (https://vote.makerdao.com/).

• With regards to the terms under “Feasibility Limitations”, consideration may be made if the first two bullet points are met but the third isn’t, pending confirmation from the asset steward.

• EIP incompatibilities may be considered as in-scope only for the critical impact “Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield”

• Issues where there is damage to the protocol/users but the net attack cost exceeds the damage caused by 50% or more are considered low severity. For avoidance of doubt, this means that if it costs USD 1500 to steal USD 1 000, then the bug report is downgraded to Low.

• Minor rounding errors leading to missing some fees, getting more fee share compared to someone else, or fees locked in the protocol are downgraded to Low. For the definition of "minor" we use 0.5%.

• Any user errors that lead to the loss of their own funds are not in scope

• Oracle value updates outside of the delta governance considered when choosing the parameters of the system are out of scope. This includes trivial issues in the main stable coin system, roughly speaking e.g. when an extreme price drop exceeds the collateral's liquidation ratio, so that a position would become unhealthy after the update and a liquidation wouldn’t raise sufficient funds leading to bad debt. Constructions describing how “loss of funds” (bad debt) could occur in such a scenario are out of scope. For example, if a collateral has a liquidation ratio of 200%, but the asset price suffers a 60% price drop, leading to a bad debt, it is considered a design decision.

• Governance related:

  • It is assumed that wards in all contracts are fully trusted, as well as other privileged roles.
  • Subdao proxies, facilitators and permissioned keepers are assumed fully trusted.
  • The option of avoiding future governance actions towards USDS and sUSDS holders by moving to vat.dai is known.
  • Grouping of specific governance actions if needed (or permissionless actions with governance ones), are assumed to be implemented in the spell or dss-exec-lib level.
  • Chainlog maintenance is assumed to be possible also after components have been added or removed. Therefore missing/extra/wrong/inconsistent Chainlog values are assumed a non-issue.
  • Certain models have Mom contracts to allow governance to perform actions without governance delay. Choosing which contracts or actions should have this ability is assumed to be done by the protocol and pointing out a lack of it for a certain module is out of scope.

• Any DoS attack that does not result in the freezing of funds or disruption of protocol functionality, but still allows for the withdrawal of funds, will be downgraded to low.

• A DoS attack that temporarily locks the funds of an already liquidated position for up to one week is considered a non-issue and will be OOS. If the lock extends from one to four weeks, it could be classified as a medium severity issue, depending on the nature of the attack and other relevant circumstances, but this would be categorized as a bonus by the Sky team and thus is under its full discretion.

• It is assumed that users and keepers are aware of the reserveHatch functionality for solving vote-delegate/lockstake related DoS issues. It is assumed that keepers run by 3rd-parties and Sky integrate it to their logic and that the need for using it is constantly monitored

Reward Payment Terms

Payouts are handled by Sky directly. Payments are denominated in USD. However, payouts are done in DAI or USDS, at the discretion of the Sky team, assuming a full 1:1 ratio with the USD. However, if the price of DAI or USDS deviates from the USD value by more than 1%, the amount of DAI or USDS will be adjusted. Upon confirmation, bug bounty payouts should be included in the next possible 'executive spell', which is a governance vote with an onchain payload attached to it. This would involve sending DAI or USDS directly from the protocol's buffer to the security researcher. As described in the Maker Atlas, for bug bounty rewards over USD 1 000 000, after the first million is paid out, the remaining amount is paid out over time with up to USD 1 000 000 per consecutive month until the determined amount for payout is reached.

Due to the limitations of the Sky governance process, payouts will have a delay of up to 1 calendar month after the date of validation of the bug report.