Skip to content

Stop importing MCD.sol from dss-test in spells #476

@amusingaxl

Description

@amusingaxl

Problem

Whenever we have spells with custom script dependencies in src/dependencies/, they usually depend on MCD.sol. As a result, a lot of files are brought to scope, making the list of files in verification untenable.

See the spell from 2025-05-29 for instance:
https://etherscan.io/address/0x86F5A13C95ecf7263634b6e14E483d05D7d4aA0B#code#F79#L1

The issue is that MCD.sol depends on GodMode.sol, which in its turn depends on forge-std/Vm.sol. Also all interfaces from dss-interfaces are brought in, even long deprecated, unused ones.

The current verify.py script that removes unused methods from DssExecLib cannot help here, as it was not designed to deal with this structure of nested dependencies. In fact, it actually doesn't work when spells have an src/dependencies/ directory, forcing us to verify the script using standard tooling (i.e.: forge verify-contract) or an updated version of the script (see #469).

Possible solutions

1. Drop-in Replacement

Create a runtime version of MCD.sol (i.e.: MCDRuntime.sol) which does not have the utilities for testing and import only the required interfaces. Then we change whatever reference we have to MCD.sol to this new file.

The main advantage is that we don't need to get the agreement of every technical team working with the Sky Protocol to use something new.

The drawback is that the code onboarded in the spell would diverge from the audited one.

2. Separate Runtime-Ready Library

Create a runtime version of MCD.sol same way as above, but in a different repo (i.e.: mcd-runtime). Then any script that is expected to be run from a spell should import from that new module instead of dss-test.

The main advantage is that this is a cleaner and more explicit approach, and we can keep the audited code ipsis litteris.

The drawbacks are that we require the buy in of every tech team working with the core Sky Protocol, and we'll need to update the dependencies and the code of modules that have already been audited and re-audit them.

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions