create SIP-390

content/sips/sip-390.md

@@ -0,0 +1,110 @@
+---
+sip: 390
+title: Delegate governance power from collateral token deposited in Synthetix
+network: Ethereum, Optimism, Base & Arbitrum
+status: Draft
+type: Governance
+author: GUNBOATs (@gunboatsss)
+created: 2024-05-31
+---
+
+<!--You can leave these HTML comments in your merged SIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+
+## Simple Summary
+
+<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->
+
+Enable Synthetix to delegate governance power from token deposited in the system to any address set by governance.
+
+## Abstract
+
+<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->
+
+Add `address delegatee` in `CollateralConfiguration.Data` field and a function call `delegate(address delegatee)` to token when `delegatee` is not set to `address(0)`
+
+## Motivation
+
+<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is inaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->
+
+As Arbitrum deployment is accepting ARB as collateral, there is an opportunity to use the governance power in the token to vote on proposals. This could be set to delegate to multisig of Ambassador Council multisig.
+
+## Specification
+
+<!--The specification should describe the syntax and semantics of any new feature, there are five sections
+1. Overview
+2. Rationale
+3. Technical Specification
+4. Test Cases
+5. Configurable Values
+-->
+
+### Overview
+
+<!--This is a high level overview of *how* the SIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->
+
+Add a call to delgate to token when address is not `address(0)`
+
+### Rationale
+
+<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+As collateral configuration is already exists, the delegation can be piggybacked on top in V3 system. Not all token has delegate function and calling it will revert. Those cases will just have `delegatee` set as `address(0)`. In case of giving up voting power, the governance can change the address into dead address.
+
+### Technical Specification
+
+<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.-->
+
+Add `IVotes` interface which is used by many governance token as following.
+
+```solidity
+interface IVotes {
+    function delegate(address delegatee) external;
+}
+```
+
+In `CollateralConfugration.Data` struct, add the following.
+```diff
+library CollateralConfiguration {
+    struct Data {
+        ...
++       address delegatee;
+    }
+}
+```
+
+In `set` function, add the following.
+```diff
+function set(Data memory config) internal {
+    ...
+    if (config.issuanceRatioD18 < config.liquidationRatioD18) {
+            revert ParameterError.InvalidParameter(
+                "issuanceRatioD18",
+                "must be greater than liquidationRatioD18"
+            );
+        }
+
++   if(config.delegatee != address(0)) {
++       IVotes(config.tokenAddress).delegate(config.delegatee);
++   }
+    ...
+    storedConfig.depositingEnabled = config.depositingEnabled;
++   storedConfig.delegatee = config.delegatee;
+}
+```
+### Test Cases
+
+<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->
+
+When `delegatee` is not `address(0)`  
+ * it should call `delegate(address)` with `delegatee` as parameter.
+ * otherwise do nothing.
+
+### Configurable Values (Via SCCP)
+
+<!--Please list all values configurable via SCCP under this implementation.-->
+
+`address delegatee` a address to delegate to.
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).