Skip to content

Make some of the contracts upgradable #102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ggonzalez94 opened this issue Apr 8, 2025 · 1 comment
Open

Make some of the contracts upgradable #102

ggonzalez94 opened this issue Apr 8, 2025 · 1 comment
Labels
deployment A change related to how we deploy the protocol contracts needs discussion This issue still needs discussion before implementing

Comments

@ggonzalez94
Copy link
Collaborator

This is a bit of a meta issue that requires some discussion before implementing:

  • Decide which contracts should be upgradable
  • What are the roles required for those contracts
  • We have a lot of immutable configurations, especially for contract references. We should decide between the following options:
    • For variables that will never change we are ok leaving them as immutable
    • For variables that we expect to have to change often(e.g. configuration parameters that are sensible to marke changes) they should be storage variables that can be updated by an owner(e.g. a DAO)
    • For variables that we expect to change very infrequently(e.g. a reference to another contract or a config parameter that is not expected to change) I believe the most optimal solution gas wise might be still making it a constant or an internal function that returns a hardcoded value and the way a permissioned actor can update it is by upgrading the contract
@ggonzalez94 ggonzalez94 added needs discussion This issue still needs discussion before implementing deployment A change related to how we deploy the protocol contracts labels Apr 8, 2025
@ggonzalez94
Copy link
Collaborator Author

Discussed this during a call yesterday and we have a strong preference towards immutables and internal functions that return a hardcoded value for gas efficiency reasons. Unless absolutely necessary, we should avoid storage variables for config parameters and will instead just upgrade the contract. One downside of this approach is that upgrades will likely have a long delay, while config changes could happen immediately or with shorter delays

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployment A change related to how we deploy the protocol contracts needs discussion This issue still needs discussion before implementing
Projects
None yet
Development

No branches or pull requests

1 participant