Skip to content

Latest commit

 

History

History
418 lines (408 loc) · 35.2 KB

spell-reviewer-mainnet-checklist.md

File metadata and controls

418 lines (408 loc) · 35.2 KB
Raw

Mainnet Executive Spell Review Checklist

Development Stage

  • Preparation
    • Exec Sheet for the specified date is found in the "Executive Vote Implementation Process" google sheet Insert URL to the specific sheet here
    • Using Exec Sheet URL from the above, read spell instructions from the Exec Sheet and list them below List all instructions announced in the Exec Sheet
  • Base checks
    • Current solc version 0.8.16
    • Office hours is true IF spell introduces a major change that can affect external parties (e.g.: keepers are affected in case of collateral offboarding) OTHERWISE explicitly set to false
    • Office hours value matches the Exec Sheet
    • 30 days spell expiry set in the constructor (block.timestamp + 30 days)
  • Spell description
    • Description follows the format TARGET_DATE MakerDAO Executive Spell | Hash: EXEC_DOC_HASH
    • TARGET_DATE in the description matches the target date
    • Accompanying comment above spell description follows the format // Hash: cast keccak -- "$(wget 'EXEC_DOC_URL' -q -O - 2>/dev/null)"
  • Comments inside the spell
    • Every Section text from the Exec Sheet is copied to the spell code as a comment surrounded by the set of dashes (E.g. // ----- Section text -----)
    • Every Instruction text from the Exec Sheet is copied to the spell code as // Instruction text
    • Every Instruction text have newline above it
    • IF an instruction can not be taken, it should have explanation under the instruction prefixed with // Note: (e.g.: // Note: Payments are skipped on goerli)
    • IF action in the spell doesn't have relevant instruction (e.g.: chainlog version bump), the necessity of it is explained in the comment above prefixed with // Note:
    • Every proof url from the Exec Sheet, such as Reasoning URL and Authority URL is present in the spell code under relevant section or instruction (depending on which row the url is present)
    • Every proof url from the Exec Sheet, such as Reasoning URL and Authority URL have prefix derived from the url itself
      • // Executive Vote: if URL starts with https://vote.makerdao.com/executive/
      • // Poll: if URL starts with https://vote.makerdao.com/polling/
      • // Forum: if URL starts with https://forum.makerdao.com/t/
      • // MIP: if URL starts with https://mips.makerdao.com/mips/details/
  • Dependency checks
    • Update Foundry by running foundryup
    • Reinstall libraries by running rm -rf ./lib && git submodule update --init --recursive 
      Insert checked out submodule paths here
    • IF submodule upgrades are present, make sure dss-exec-lib is synced as well
    • git submodule hash of dss-exec-lib (run git submodule status) matches the latest release version or newer
    • dss-interfaces library used inside lib/dss-exec-lib matches submodule used inside lib/dss-test
  • IF interfaces are present in the spell
    • Interfaces imported from dss-interfaces
      • No unused dss-interfaces
      • Only single import layout is used (e.g. import "dss-interfaces/dss/VatAbstract.sol";)
    • Static Interfaces
      • No unused static interfaces
      • Declared static interface not present in the dss-interfaces, OTHERWISE should be imported from there
      • Interface matches deployed contract using cast interface <contract_address> command
      • Interface naming style should match with Like suffix (e.g. VatLike)
      • Each static interface declare only functions actually used in the spell code
  • IF variable declarations are present in the spell
    • IF precision units are present
      • Precision units used in the spell match their defined values:
        • WAD = 10 ** 18
        • RAY = 10 ** 27
        • RAD = 10 ** 45
      • Precision units match with Numerical Ranges
      • Each variable visibility is declared as internal
      • Each variable state mutability is declared as constant
    • IF math units are present
      • Match their defined values:
        • HUNDRED = 10 ** 2
        • THOUSAND = 10 ** 3
        • MILLION = 10 ** 6
        • BILLION = 10 ** 9
      • Match with config
      • Each variable visibility is declared as internal
      • Each variable state mutability is declared as constant
    • IF rates are present
      • Rates match generated locally via make rates pct=<pct> (e.g. pct=0.75, for 0.75%)
      • Rates match IPFS document
      • Rate variable name conforms to X_PT_Y_Z_PCT_RATE (e.g. ZERO_PT_SEVEN_FIVE_PCT_RATE for 0.75%)
      • Rate variable visibility declared as internal
      • Rate variable state mutability declared as constant
    • IF timestamps are present
      • Comment above timestamp states full date including UTC timezone
      • Timestamp converts back to the correct date
      • Timestamp converts back to the UTC timezone
      • Variable naming matches MMM_DD_YYYY (e.g. JAN_01_2023 for 2023-01-01)
      • Time of day makes logical sense in the context of timestamp usage (i.e. 23:59:59 UTC for the final day of something, 00:00:00 UTC for the first day of something)
      • Each variable visibility is declared as internal
      • Each variable state mutability is declared as constant
  • IF new contract is present in the spell (not yet on chainlog or new to chainlog)
    • Source code is verified on etherscan
    • Compilation optimizations match deployment settings defined in the source code repo
    • GNU AGPLv3 license
    • Every maker-related constructor argument matches chainlog (e.g. vat, dai, dog, ...)
    • IF new contract have concept of wards or access control
      • Ensure PAUSE_PROXY address was relied (wards(PAUSE_PROXY) is 1)
      • Ensure that contract deployer address was denied (wards(deployer) is 0)
      • Ensure that there are no other Rely events except for PAUSE_PROXY (using a block explorer like etherscan)
    • Source code matches corresponding github source code (e.g. diffcheck via vscode code --diff etherscan.sol github.sol)
    • Deployer address is included into addresses_deployers.sol
  • IF core system parameter changes are present in the instructions
  • IF debt ceiling changes are present in the instructions
  • IF additional dependencies (i.e. ./src/dependencies/ directory) are present:
    • IF the dependencies contracts/libraries have been audited
      • Each contract/library exactly matches (i.e. diff check) the source code of the latest audited version
    • OTHERWISE obtain the permalink to the relevant repository from a trusted party (i.e. Gov Facilitators)
      • Each contract/library exactly matches (i.e. diff check) the source code from the permalink
  • IF onboarding is present
  • IF PSM migration, onboarding or offboarding is present:
  • IF D3M onboarding is present, insert and follow D3M Checklist
  • IF collateral offboarding is present in the spell
    • 1st stage collateral offboarding
      • Collateral type (ilk) is removed from AutoLine (MCD_IAM_AUTO_LINE) IF currently enabled
      • Collateral debt ceiling (vat.ilk.line) is set to 0
      • Global debt ceiling (vat.Line) decreased by the total amount of offboarded ilks
    • 2nd stage collateral offboarding
      • All actions from the 1st stage offboarding are previously taken (EITHER in the current or past spells – check the archive)
      • Collateral liquidation penalty (chop) is set to 0 IF requested by governance
      • Flat keeper incentive (tip) is set to 0 IF requested by governance
      • Relative keeper incentive (chip) is set to 0 IF requested by governance
      • Max liquidation amount (hole) is adjusted via DssExecLib.setIlkMaxLiquidationAmount(ilk, amount) IF requested by governance
      • Relevant clipper contract (MCD_CLIP_) is active (i.e. stopped is 0)
      • Liquidations are triggered via (depending on governance instruction):
        • EITHER liquidation ratio (spotter.ilk.mat) being set very high in the spell (using DssExecLib.setValue(DssExecLib.spotter(), ilk, "mat", ratio))
        • OR via enabling linear interpolation (DssExecLib.linearInterpolation(name, target, ilk, what, startTime, start, end, duration))
          • Ensure name format matches "XXX-X Offboarding"
          • Ensure target matches DssExecLib.spotter() address
          • Ensure ilk format matches collateral type (ilk) name ("XXX-X")
          • Ensure what matches string "mat"
          • Ensure startTime matches block.timestamp
          • Ensure start uses variable CURRENT_XXX_A_MAT
          • Ensure start matches current spotter.ilk.mat value
          • Ensure end uses variable TARGET_XXX_A_MAT
          • Ensure end value matches the instruction
          • Ensure end allows liquidation of all remaining vaults (end is bigger than collateral_type_collateralization_ratio * risk_multiplier_factor)
          • Ensure duration matches the instruction
      • Spotter price is updated via DssExecLib.updateCollateralPrice(ilk) IF collateral have no running oracle (i.e. relevant PIP_ contract have outdated zzz value)
      • Spotter price is updated after all other actions
      • Offboarding is tested at least via _checkIlkClipper helper
  • IF RWA updates are present
    • IF doc is updated
      • _updateDoc helper is copied one-to-one from the archive and defined above actions
      • _updateDoc(ilk, doc) is called in the spell
    • IF debt ceiling is updated
      • IF AutoLine update is requested by the Exec Sheet
      • IF regular debt ceiling (vat.ilk.line) update is requested by the Exec Sheet
      • Liquidation oracle price is bumped via RwaLiquidationOracleLike(MIP21_LIQUIDATION_ORACLE).bump(ilk, val) pattern
        • Comment above bump explains val computation via // Note: the formula is: "debt_ceiling * [ (1 + rwa_stability_fee ) ^ (minimum_deal_duration_in_years) ] * liquidation_ratio"
        • Comment above bump provides locally executable formula (e.g. // bc -l <<< 'scale=18; 50000000 * e(l(1.07) * (3342/365)) * 1.00' | cast --to-wei)
          • The formula matches the example provided above
          • debt_ceiling in the executable formula matches new debt ceiling set in the spell or the maximum possible debt ceiling in case of the enabled AutoLine
          • rwa_stability_fee in the executable formula matches stability fee of the specified RWA found on chain
          • minimum_deal_duration_in_years in the executable formula matches number found in the Exec Sheet of the spell containing relevant RWA onboarding
          • liquidation_ratio in the executable formula matches liquidation ratio of the specified RWA found on chain
          • Executing formula locally provides integer number that matches the val in the spell
        • val makes sense in context of the rate mechanism
      • IF multiple RWA ilks are being combined into one, val calculation is done once per ilk and added to make the total, with separate executable formulas provided in comments. The existing val value can be retrieved by calling read() on PIP_RWAXX and converting the result into decimal
      • Oracle price is updated via DssExecLib.updateCollateralPrice(ilk)
      • IF soft liquidation explicitly requested to be triggered (via .tell(ilk)) AND debt ceiling is 0 (OR is being set to 0 in the current spell)
        • RwaLiquidationOracle.tell(ilk) call is present
        • IF RWAXX_A_INPUT_CONDUIT is an instance of TinlakeMgr (it is a Centrifuge integration), additional TinlakeMgr.tell() call is present (in order to prevent further TIN redemptions in the Centrifuge pool)
  • IF payments are present in the spell
    • IF MKR transfers are present
      • Recipient address in the instruction is in the checksummed format
      • Recipient address matches Exec Sheet
      • Recipient address variable name matches one found in addresses_wallets.sol
      • Transfer amount matches Exec Sheet
      • Transfer amount is specified with (at least) 2 decimals using ether keyword
      • IF ether keyword is used, comment is present on the same line // Note: ether is a keyword helper, only MKR is transferred here
      • The transfers are tested via testMKRPayments test
      • Sum of all MKR transfers tested in testMKRPayments matches number in the Exec Sheet
    • IF DAI surplus buffer transfers are present
      • Recipient address in the instruction is in the checksummed format
      • Recipient address matches Exec Sheet
      • Recipient address variable name matches one found in addresses_wallets.sol
      • Transfer amount matches Exec Sheet
      • The transfers are tested via testDAIPayments test
      • Sum of all DAI transfers tested in testDAIPayments matches number in the Exec Sheet
    • IF MKR or DAI streams (DssVest) are created
      • VestAbstract interface is imported from dss-interfaces/dss/VestAbstract.sol
      • restrict is used for each stream, UNLESS otherwise explicitly stated in the Exec Sheet
      • usr (Vest recipient address) matches Exec Sheet
      • usr address in the instruction is in the checksummed format
      • usr address variable name match one found in addresses_wallets.sol
      • tot (Total stream amount) matches Exec Sheet
      • IF ether keyword is used, comment is present on the same line // Note: ether is a keyword helper, only MKR is transferred here
      • IF vest amount is expressed in 'per year' or similar in the Exec Sheet, account for leap days
      • bgn (Vest start timestamp) matches Exec Sheet
      • tau is expressed as bgn - fin (i.e. MONTH_DD_YYYY - MONTH_DD_YYYY)
      • fin (Vest end timestamp) matches Exec Sheet
      • eta (Vest cliff duration) matches the following logic
        • IF eta is explicitly specified in the Exec Sheet, then the values match
        • IF eta and clf (Cliff end timestamp) are not specified in the Exec Sheet, then eta is 0
        • IF clf is specified, but clf <= bgn, then eta is 0
        • IF clf is specified and clf > bgn, eta is expressed as clf - bgn (i.e. MONTH_DD_YYYY - MONTH_DD_YYYY)
      • IF mgr (Vest manager address) is specified in the Exec Sheet, matches the value, OTHERWISE matches address(0)
      • Ensure that max vesting rate (cap) is enough for the new streams
        • The maximum vesting rate (tot divided by tau) <= the maximum vest streaming rate (cap)
        • The maximum vesting rate (tot divided by tau) > the maximum vest streaming rate (cap)
        • Calculate new cap value equal to 10% greater than the new maximum vesting rate, then round new cap up with 2 significant figure precision (i.e. 2446 becomes 2500)
      • IF max vesting rate (cap) is changed in the spell
        • Governance facilitators were notified
        • Exec Sheet contain explicit instruction
        • Exec Sheet contain explicit instruction
      • IF MKR stream (DssVestTransferrable) is present
        • Vest contract's MKR allowance increased by the cumulative total (the sum of all tot values)
        • Ensure allowance increase follows archive patterns
      • Tested via testVestDAI or testVestMKR
    • IF MKR or DAI vest termination (Yank) is present
      • Yanked stream ID matches Exec Sheet
      • MCD_VEST_MKR_TREASURY chainlog address is used for MKR stream yank
      • MCD_VEST_DAI chainlog address is used for DAI stream yank
      • Tested via testYankDAI or testYankMKR
  • IF SubDAO-related content is present
    • IF SubDAO provides SubProxy spell address
      • SubDAO spell address matches Exec Sheet
      • Executed via ProxyLike(SUBDAO_PROXY).exec(SUBDAO_SPELL, abi.encodeWithSignature("execute()"));
      • Execution is NOT delegate call
      • IF SubDAO spell deployer is a smart contract (e.g. multisig or factory), ensure the deployer address is in addresses_deployers.sol as an entry
      • Ensure that SubDAO spell have enough gas and does not revert with "out of gas" error inside simulation. Note: low level call gas estimation is not done by our scripts
    • IF SubDAO provides instructions to be executed by the main spell (i.e. that will operate within Pause Proxy DelegateCall context)
      • No SubDAO contract being interacted with is authed on a core contract like vat, etc. (Check comprehensively where the risk is high)
      • SubDAO contract licensing and optimizations generally do not matter (except where they pose a security risk)
      • SubDAO contracts and all libraries / dependencies have verified source code (Blocking)
      • Upgradable SubDAO contracts
        • Upgradable contracts have the PAUSE_PROXY as their admin (i.e. the party that can upgrade)
        • Any upgradable SubDAO contracts with an admin that is not PAUSE_PROXY are not authed on any core contracts (Blocking)
      • All SubDAO content addresses (i.e. provided contract addresses or EOAs) present in the Maker Core spell are present in the Exec Sheet and are correct. SubDAO addresses being authed or given any permissions MUST be in the Exec Sheet. SubDAO addresses being called must be confirmed by the SubDAO spell team.
      • IF addresses not PR'ed in by the SubDAO team (use git blame for example), SubDAO content addresses all have inline comment for provenance or source being OKed by SubDAO
      • SubDAO actions match Exec Sheet (only where inline with main spell code) and do not affect core contracts
      • Core contract knock-on actions (such as offboarding or setting DC to 0) are present in the exec and match the code
      • External calls for SubDAO content are NOT delegate call
      • Code does not have untoward behavior within the scope of Maker Core Contracts (e.g. up to the SubDAO proxy)
  • IF external contracts calls are present (Not SubDAOs, e.g. Starknet)
    • Target Contract doesn't block spell execution
    • External call is NOT delegatecall
    • Target Contract doesn't have permissions on the Vat
    • Target Contract doesn't do anything untoward (e.g. interacting with unsafe contracts)
    • Contracts deployed via CREATE2 (e.g. if it looks like a vanity address) do not have selfdestruct in their code
    • MCD Pause Proxy doesn't give any approvals
    • All possible actions of the Target Contract are documented
    • Target contract is not upgradable
    • Target Contract is included in the ChainLog
    • Test Coverage is comprehensive
  • IF spell interacts with ChainLog
    • ChainLog version is incremented based on update type
      • Major -> New Vat (++.0.0)
      • Minor -> Core Module (DSS) Update (e.g. Flapper) (0.++.0)
      • Patch -> Collateral addition or addition/modification (0.0.++)
    • New addresses are added to the addresses_mainnet.sol
    • Changes are tested via testChainlogIntegrity and testChainlogValues
  • Ensure every spell variable is declared as public/internal
  • Ensure immutable visibility is only used when fetching addresses from the ChainLog via DssExecLib.getChangelogAddress(key) and constant is used instead for static addresses
    • Fetch addresses as type address and wrap with Like suffix interfaces inline (when making calls), UNLESS archive patterns permit otherwise (Such as MKR)
    • Use the DssExecLib Core Address Helpers where possible (e.g. DssExecLib.vat())
    • Where addresses are fetched from the ChainLog, the variable name must match the value of the ChainLog key for that address (e.g. MCD_VAT rather than vat), except where the archive pattern differs from this pattern (e.g. MKR)
  • Tests
    • Ensure that the DssExecLib.address file is not being modified by the spell PR
    • Check all CI tests are passing as at the latest commit Insert most recent commit hash where CI was passing
    • Ensure every test function is declared as public
      • IF the test needs to run, it MUST NOT have the skipped modifier; OTHERWISE, it MUST have the skipped modifier
    • Ensure each spell action has sufficient test coverage List actions for which coverage was checked here
    • Ensure that any other env variable does not affect execution of the tests (for example, by inspecting the output of printenv | grep "FOUNDRY_\|DAPP_")
    • Check all tests are passing locally using make test
      • Ensure every test listed in the coverage item above is present in the logs and with the [PASS] prefix.
_Insert your local test logs here_

Pre-Deployment Stage

  • Wait till the Exec Doc is merged
  • Exec Doc checks
    • Exec Doc for the specified date is found in the makerdao/community GitHub repo
    • Exec Doc file name follows the format Executive vote - Month DD, YYYY.md
    • Extract permanent URL to the raw markdown file and paste it below Insert your Raw Exec Doc URL here
    • Ensure the URL uses commit hash that introduced last change to the Exec Doc, NOT merge commit
      • IF there is no local copy of makerdao/community GitHub repo), run: 
        git clone https://github.com/makerdao/community
      • OTHERWISE, ensure it is pointing to the latest commit on master: 
        git switch master && git pull origin master
      • Get the latest commit hash for the exec doc: 
        git log --pretty=oneline -1 -- "<LOCAL_PATH_TO_EXEC_DOC>"
    • Using Exec Doc URL from the above and the TARGET_DATE, generate Exec Doc Hash via make exec-hash date=$TARGET_DATE $URL Insert your Exec Doc Hash here
    • Using Exec Doc URL from the above, generate Exec Doc Hash via cast keccak -- "$(curl '$URL' -o - 2>/dev/null)" Insert your Exec Doc Hash here
    • Make sure that hash above doesn't match keccak hash of the empty string (0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470)
    • Using Exec Doc URL from the above, read spell instructions from the Exec Doc and list them below List all instructions announced in the Exec Doc
    • Office hours value in the Exec Doc matches the spell
    • Sum of all payments in the Exec Doc matches the tests
    • Exec Doc URL in the spell comment matches your Raw Exec Doc URL above
    • Exec Doc URL in the spell comment refers to the https://github.com/makerdao/community repository
    • Every action present in the spell code is present in the Exec Doc
    • Every action in the Exec Doc is present in the spell code
  • IF new commits are present in the spell
    • Copy relevant checklist items from the above and redo them
    • Ensure newly added code is covered by tests
    • Check if chainlog needs to be updated
    • Copy over and redo "Tests" section from the above
  • IF all checks pass, make sure to include explicit "Good to deploy" comment

Deployed Stage

  • Source code settings
    • Deployed spell is verified on etherscan
    • Optimization enabled: false UNLESS the contract size is too big AND all mitigation strategies (i.e.: removing revert strings) have failed
    • Default evmVersion
    • GNU AGPLv3 license
  • Source code validity
    • Deployed spell code matches source on github. (can be checked via make diff-deployed-spell or manually)
    • No new changes are made after previously given "good to deploy"
  • Deployed spell Etherscan checks
    • Automated checks via make check-deployed-spell
      • Verified
      • Valid license
      • Version matches
      • Optimizations are disabled
      • dss-exec-lib library address used (under 'Libraries Used') matches the hardcoded local DssExecLib.address file
      • deployed_spell_created matches deployment timestamp
      • deployed_spell_block matches deployment block number
    • Manual checks
      • Ensure make deploy-info tx=<tx> matches config
        • deployed_spell_created timestamp
        • deployed_spell_block block number
      • Check again that the PR did not modify the DssExecLib.address file (e.g. look under the 'Files Changed' PR tab, etc.)
      • Ensure Etherscan Libraries Used matches DssExecLib Latest Release
      • (For your tests to be accurate) git submodule hash matches dss-exec-lib latest release's tag commit and inspect diffs if doesn't match to ensure expected behaviour (Currently Non-Critical pending the next DssExecLib release, double check that the ExecLib used by the contract matches the latest release)
  • Tenderly Testnet checks
    • A testnet with the name matching spell description is found at maker dashboard
    • The testnet name is unique (previous testnets does not have the same name)
    • Cast transaction is set to the correct "receiver" (matches deployed spell address)
    • All actions are executed in the transaction trace
    • No reverts are present that block execution
    • No out-of-gas errors are present
  • Archive checks
    • make diff-archive-spell for current date or make diff-archive-spell date="YYYY-MM-DD"
    • Ensure date corresponds to target Exec Doc date
  • Tests
    • Ensure that the DssExecLib.address file is not being modified by the spell PR
    • Check all CI tests are passing as at the latest commit Insert most recent commit hash where CI was passing
    • Ensure that any other env variable does not affect execution of the tests (for example, by inspecting the output of printenv | grep "FOUNDRY_\|DAPP_")
    • Check all tests are passing locally using make test
_Insert your local test logs here_

Handover and Merge Stage

  • Check that the spell address posted by the crafter in new-spells is correct
  • Confirm the address in the new-spells channel (via a separate "reply to" message, restating the address to avoid edits)
    • Wait until responsible governance facilitator confirms handover in new-spells
  • Ensure that no changes were made to the code since the spell was deployed and archived
  • Approve spell PR for merge via 'Approve' review option