Technical Governance Overview
Sommelier Governance plays a core role in the continued deployment and support of newly-released Cellars. The "Roles & Permissions" section enumerates all operations available to governance: this section will contain guidelines around the usage of those operations.
- Governance should take extreme care when using the
setAddressfunction. Cellars are deployed expecting certain registry slots to fulfill certain interfaces (for instance, the assumption that the registry slot
2will fulfill the
PriceRouterinterface). Malicious addresses in slots that Cellars use can lead to unexpected behavior, up to and including loss of funds. In the case of honest updates, where
setAddressis used to update a protocol component to a contract version with new functionality, backwards compatibility must be maintained. Breaking changes that are not backwards-compatible can end up freezing previously-deployed Cellars that expect certain interfaces in certain registry slots.
- When using
trustAdaptorto add a new adaptor to the protocol, Governance should exercise due diligence in making sure that the given adaptor does not add risk to either the entire protocol, or Cellars which may use the adaptor. Before trusting an adaptor, governance should undertake proper due diligence, including reviewing code and audit reports.
- When using
trustPositionto enable new applications for a given adaptor (interaction with new tokens), governance should take care to undertake proper due diligence so that the
adaptorDatabeing associated with the position does not introduce any additional risk. For instance, if the
adaptorDatabytes specify particular tokens, those tokens should be checked for possible malicious or nonstandard behaviors. For example, positions should not be trusted if they are associated with fee-on-transfer tokens.
- When adding new assets to the Price Router, governance should always ensure that the assets being added derive pricing from robust sources and will not be subject to oracle manipulation attacks. Low-liquidity tokens should be avoided.
- Governance should ensure that the
addAssetis always in USD terms, even if that asset is not directly priced in USD (e.g. only ETH oracle available).
- When calling
setMinDelta, governance should analyze the new delta to ensure that an optimal balance between real-time pricing and gas overhead is reached. Deltas that are too small can waste gas for inconsequential pricing updates: deltas that are too large can lead to stale pricing and lagging TVL updates.
- Changing the automation registry via
setAutomationRegistryshould be done with extreme care. The automation registry is the only caller allowed to update virtual price bounds, and if malicious addresses are given this permission, they can cause a Cellar's TVL to be reported incorrectly.
- Governance has the ability to change allowed rebalance deviations with
allowedRebalanceDeviation. In general, the allowed deviations should be kept to the minimum amount that allows the cellar to perform normal operations without disruption. In some cases - for exotic strategies or high-reputation strategists - this deviation amount can be increased in order to enable specific use cases. When doing so, governance should ensure that the strategist is not in a position to abuse larger rebalance deviations. Hypothetical bugs and security issues in adaptors may have their value at risk bounded by the rebalance deviation: therefore governance should also consider that larger rebalance deviations decrease Cellar safety, and should only be used with robust and battle-tested sets of adaptors.
- Governance also has the ability to call
setShareLockingPeriodto change the initial deposit lock for new funds that are deposited into the cellar. Lower share lock periods reduce the opportunity cost of sandwiching Cellar operations (directing outsize profits to short-term depositors). However, they can also be more convenient for UX purposes. When lowering share lock periods, governance should take care to consider the sorts of adaptor calls the strategist makes, and if a lower share lock period might increase the risk of sandwich attacks and/or unfair distribution of profits.
- Governance should only use
initiateShutdownin extreme scenarios. Shutdowns disallow new deposits and adaptor calls, but do not block withdrawals. If using shutdowns to mitigate a security vulnerability, governance must carefully consider whether the vulnerability can still be exploited during shutdown, and should additionally be aware that calling
initiateShutdownmay further highlight the existence of the vulnerability to outside parties.