With Enso V2 going live this week, we are transferring ownership of the contracts fully into the dedicated Enso Defender Multisig in decentralizing the Enso protocol prior to token governance coming into effect.

Enso Defender Participants

These participants have been particularly chosen as they are familiar with the Enso codebase through peer reviews, recommendations, or discussions, resulting in an extremely high knowledge base of participants in relation to the codebase at hand.

Multisig - 0x5725fa6810df693fc6249b74d3c7ec2e61188738
Threshold - 5/8

Nick
Twitter: https://twitter.com/nicksdjohnson
Current: Lead dev at ENS
Address: 0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5
Signature: https://etherscan.io/verifySig/17060

Violet
Twitter: https://twitter.com/alpeh_v
Current: Lead dev at delv_tech
Address: 0xDfe6610c2357a0BfECF788e52697554aF5F35174
Signature: https://etherscan.io/verifySig/17058

Mick
Twitter: https://twitter.com/MickdeG010
Current: Dev at Euler and Merit
Address: 0xC73F1771cFe83d64901eE88f6B4c0801fa11DDdA
Signature: https://etherscan.io/verifySig/17062

Johannes
Twitter: https://twitter.com/0xJohannes
Current: Lead dev at BarnBridge
Address: 0x10Df24A6ca55AB2a9f45b446a1fE94073Ec984bf
Signature: https://etherscan.io/verifySig/17061

ApeDev
Twitter: https://twitter.com/_apedev
Current: MEV
Address: 0x6b8144d2e7a5958d7ab28271842c8cd72886de81
Signature: https://etherscan.io/verifySig/17059

Dantop
Twitter: https://twitter.com/dantop114
Current: Dev at Dialectic
Address: 0xC644bb02F7156E50809115e40eB909FcE85721ab
Signature: cast call --rpc-url [<https://eth.llamarpc.com>](<https://eth.llamarpc.com/>) 0xC644bb02F7156E50809115e40eB909FcE85721ab "isValidSignature(bytes,bytes)" 0x456e736f323032332d64 0x

Michele
Twitter: https://twitter.com/ps1dr3x
Current: Security at sig9
Address: 0x3FF0B0906b158826B261C871219e8859E3C71107
Signature: https://etherscan.io/verifySig/17057

Chris
Twitter: https://twitter.com/cdudley_ost
Current: Security at 162
Address: 0xC3939Ee43171cD67100E41B0F32c49237345d3E8
Signature: https://etherscan.io/verifySig/17056

Upgradeability Background

There are 2 types of upgradeabilities: fallback emergency and core upgradeability.

1. Fallback emergency
   1. This is a fallback method that the Enso team can initiate. The implementation contract can only be upgraded to the implementation initially set at deployment. This implementation address cannot be changed by the same multisig and must be changed by the Core upgradeability holders if need be.
   2. This emergency fallback upgrades to a minimal contract that only allows withdrawals of ERC20s, ERC721s, ERC1155s etc… and revoking approvals. No interactions can be done apart from withdrawals.
   3. This upgradeability function is used in the unlikely case of a key vulnerability the Enso Smart Contracts that requires immediate action which cannot await the full process of the Core Upgradeability.
2. Core upgradeability → Enso Defender
   1. Only Enso Defenders have access to this upgradeability function. The upgradeability will be setting a new implementation contract if there are any new features that will be added, or in response to upgrade that is needed after a vulnerability has been found. Depending upon the severity of the vulnerability, i.e. if critical then Fallback Emergency will come into effect, then the Core Upgradeability will come into effect thereafter upgrading the implementation to make Enso functional again.
   2. The Enso Defender multisig will transition to a formal governance process utilizing the Enso token when live.

Audits

Enso has underwent 5 audits thus far from Chainsecurity, Abdk and Mixbytes. The full audit reports can be viewed here → https://github.com/EnsoFinance/enso-audits

Transfer Full Ownership

Below are the steps for transferring full ownership of the Enso protocol to the Enso Defender multisig in preparation for public usage. Only Enso developers have been interacting with these contracts so far.

1) Update the factory address on the beacon
Why: The factory is not set on deployment because both contracts reference each other and one must be deployed first. The beacon was deployed first and now needs to know the factory address. As the owner of the factory the beacon can update the factory at the same time as upgrading the wallets so both contracts remain in sync, but it needs to know the address it is upgrading.
Function call: setFactory()
Args: { newFactory: 0x7fEA6786D291A87fC4C98aFCCc5A5d3cFC36bc7b }
Transaction: https://etherscan.io/tx/0xcc1cb3bdc21701069be8bd3e894abc9802f71ea6db5df58bfbec92cd12187115

2) Update the delegate
Why: The delegate has the ability to immediately switch to a fallback implementation. That power should rest with the Enso team's contracts multisig.
Function call: transferDelegation()
Args: { newDelegate: 0xca702d224D61ae6980c8c7d4D98042E22b40FFdB }
Transaction: https://etherscan.io/tx/0x1febf2a93c4d5518762c91ac3b3362f8d1e78864636b841b55dc557a31b40447

3) Update delay →
Why: The delay provides time between a new implementation is set by the admin and the activation of the new implementation on-chain.
Function call: updateDelay()
Args: { newDelay: 86400 }
Transaction: https://etherscan.io/tx/0x2b74e63235c4b9565b21ffe8bd0db093c29324cd223e62049ff2e0d97d7dd5d6

4) Finalize delay

Why: Changes to the delay must respect the old delay. After the delay period has passed, the new delay may be finalized.
Function call: finalizeDelay()
Args: {}
Transaction: https://etherscan.io/tx/0xd5cc91090fccb66d4f4c3ebe815975b08af533ca338ea622ba88b7efd1d9c936

5) Transfer admin
Why: The implementations are controlled by the Admin. This control must be passed to a trusted multisig.
Function call: transferAdministration()
Args: { newAdmin: 0x5725fA6810df693Fc6249b74D3c7EC2E61188738}
Transaction: https://etherscan.io/tx/0x5bbf9213b77150f4b8661e30f7d115b9a5148f5c57d04668eff6f4572490f77b

Accept Ownership

Transferring roles is a two-part process. First the current admin calls transferAdministration or transferDelegation, the account that is to become the new admin or delegate must call acceptAdministration or acceptDelegation respectively. This provides an extra layer of security where a transfer cannot be made to an invalid account.

1) Accept delegation
Why: The delegate (Enso Contract Multisig — 0xca702d224D61ae6980c8c7d4D98042E22b40FFdB) must accept the delegate role.
Function call: acceptDelegation()
Args: {}
Transaction: https://etherscan.io/tx/0x964ed063063f41520facaa30095008973a3ca1221b72a443e2f1b88cfc81acc0

2) Accept administration
Why: The admin (Enso Defenders Multisig — 0x5725fA6810df693Fc6249b74D3c7EC2E61188738) must accept the admin role.
Function call: acceptAdministration()
Args: {}
Transaction: https://etherscan.io/tx/0xf282104684dc5c36b53e18267abe307a3e9e391a66a565e48b968280a1027208

Future

All proposals of upgrades will go through the Enso forum.

LEGAL DISCLAIMER

This article is neither an offer of nor marketing material for financial instruments or financial services. Enso Finance is not regulated under any financial market laws in any jurisdiction. It is only the developer and provider of the ENSO protocol. Due to its decentralized nature, the ENSO protocol is neither controlled nor operated by Enso Finance. Enso Finance is neither providing financial services nor offering financial instruments.

Any liability is excluded to the extent permitted by applicable law.