Technical Tasks Included in the October 29th Executive

The Protocol Engineering Core Unit is including the following technical smart contract tasks in this week’s executive spell. These help manage existing modules and the deployment of future modules and do not change any protocol risk parameters.

  1. LERP_FAB: A factory contract for deploying and managing linear interpolation modules. This allows Maker governance to set up a process that modifies system variables in a linear way over time. The factory contract also provides functions for the tracking and management of existing modules.

address constant LERP_FAB = 0x9175561733D138326FDeA86CdFdF53e92b588276;

  1. JOIN_FAB: A factory contract for deploying standardized Gem Join adapters using checkpointed code and compiler versions. This is a tool for collateral onboarding that complements existing tools such as the CLIP_FAB and CALC_FAB.

address constant JOIN_FAB = 0xf1738d22140783707Ca71CB3746e0dc7Bf2b0264;

5 Likes

Thanks @Derek for the update.

Can you clarify which permissions these modules need on the system?

2 Likes

To save Derek some time, I am pretty sure these modules have no authorization on the Maker Protocol. The reason they are in the spell is to be added the the onchain Chainlog, which can be seen here: spells-mainnet/DssSpell.sol at PE-718 · makerdao/spells-mainnet · GitHub

3 Likes

@lollike is correct :slight_smile: . I can confirm that these factories are just convenience tools being added to the Chainlog and do not have any system permissions.

4 Likes

That clarifies it, thanks.

In light of the structure we’re creating as a result from the Sandbox Project, I think it would be good to start explicitly listing the permissions that are needed to execute a spell action (in this case: adding an entry to chainlog), and the permissions that the module will get afterwards (in this case: none).

This will help people to develop the right mental model and it’s a good step to improve the auditability of the spells.

2 Likes

Do we have a syntax / naming convention for contract permissions? They are all all-or-nothing-per-contract, right?

1 Like

For now, yes. So we could document the contract name, indicate that the permission is full, and the function name that will actually be used.

Something like this:

  • Contract: DSS_VEST_SAS
  • Permission: MCD_VAT.*
  • Usage: MCD_VAT.suck()

Later this can be extended by adding restrictions that would be enforced by a gateway contract.

2 Likes

Three lines is pretty wordy. Would be nice to get it on a single line so I can list it below the relevant section in the copy (assuming this isn’t automated by @dux-core-unit)

1 Like

Yeah, I didn’t mean it as the literal way of displaying the info. Just indicating the elements that can be included.

And yes, manual process first and then having it as part of the UI would be wonderful.

4 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.