[SWIP-35] Allow 100% osETH Minting in the Stake Page MetaVaults

Executive summary

In this proposal, we ask for community approval to grant the recently deployed MetaVaults 100% LTV capability, consistent with the 100% LTV capabilities of their constituents (sub-Vaults) - namely, Genesis Vault, Chorus One - MEV Max Vault, and NodeSet Vault. This assignment is a technicality and does not grant 100% LTV capabilities to new sub-Vaults; it only establishes 100% LTV minting at the MetaVault layer above the existing 100% LTV sub-Vaults.

We also request MetaVault ownership to be assigned to the Liquidity Committee’s multisig wallet 0x2685C0e39EEAAd383fB71ec3F493991d532A87ae to simplify consequent operations. This change is requested for MetaVaults on both Ethereum and Gnosis Chain.

Motivation

The upcoming release of the new MetaVault structure allows creating de-facto routers for ETH deposits, whereby interacting with one contract allows a staker to deploy funds into multiple Vaults according to the chosen MetaVault’s distribution schema.

For example, users depositing ETH on the Stake page within the StakeWise dApp will be interacting with the new MetaVault that distributes assets equally between the Genesis Vault, Chorus One - MEV Max Vault, and NodeSet Vault, all of which have 100% LTV capability enabled. Within the MetaVault structure, they’re the so-called sub-Vaults.

MetaVaults will serve as a layer that adds more flexibility to Vault owners and StakeWise itself in how stake is distributed across Vaults and on what terms.

In this proposal, we seek to update the LTV of the MetaVaults used on the Stake page to 100% to reflect the LTV of the underlying sub-Vaults. We also seek to grant the Liquidity Committee multisig (0x2685C0e39EEAAd383fB71ec3F493991d532A87ae) an Admin role for this MetaVault to allow the team to flexibly update the distribution of assets across these and potentially other Vaults in StakeWise.

This change does not create new Vaults with 100% LTV - it merely updates the LTV of the MetaVault to remain consistent with the LTV of its constituents.

This change is sought for both Ethereum and Gnosis Chain instances of the StakeWise protocol.

Specification

Ethereum

[
{
“to”: “0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5”,
“operation”: “0”,
“value”: “0.0”,
“data”: “0x8a76984d0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002e516d644c6d314e6f44654361446b7359415a70715456744e697657523661456a3256546a457a5378335039544858000000000000000000000000000000000000”,
“method”: “updateConfig(string)”,
“params”: [
“QmdLm1NoDeCaDksYAZpqTVtNivWR6aEj2VTjEzSx3P9THX”
]
},
{
“to”: “0x287d1e2A8dE183A8bf8f2b09Fa1340fBd766eb59”,
“operation”: “0”,
“value”: “0.0”,
“data”: “0x95f1fd4a00000000000000000000000015639e82d2072fa510e5d2b5f0db361c823bcad30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff0000000000000000000000000000000000000000000000000de05bc096e9c000”,
“method”: “updateConfig(address,(uint128,uint64,uint64))”
},
{
“to”: “0x287d1e2A8dE183A8bf8f2b09Fa1340fBd766eb59”,
“operation”: “0”,
“value”: “0.0”,
“data”: “0x95f1fd4a00000000000000000000000034284c27a2304132af751b0dec5bba2cf98ed0390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff0000000000000000000000000000000000000000000000000de05bc096e9c000”,
“method”: “updateConfig(address,(uint128,uint64,uint64))”
}
]

Gnosis Chain

[
{
“to”: “0xcAC0e3E35d3BA271cd2aaBE688ac9DB1898C26aa”,
“operation”: “0”,
“value”: “0.0”,
“data”: “0x8a76984d0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002e516d5743646b705469667367653674324e5477796238395043584458464e6b6665653954355a6374456672444477000000000000000000000000000000000000”,
“method”: “updateConfig(string)”,
“params”: [
“QmWCdkpTifsge6t2NTwyb89PCXDXFNkfee9T5ZctEfrDDw”
]
},
{
“to”: “0xd6672fbE1D28877db598DC0ac2559A15745FC3ec”,
“operation”: “0”,
“value”: “0.0”,
“data”: “0x95f1fd4a00000000000000000000000015639e82d2072fa510e5d2b5f0db361c823bcad30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff0000000000000000000000000000000000000000000000000ddfd353fe326000”,
“method”: “updateConfig(address,(uint128,uint64,uint64))”
},
{
“to”: “0xd6672fbE1D28877db598DC0ac2559A15745FC3ec”,
“operation”: “0”,
“value”: “0.0”,
“data”: “0x95f1fd4a00000000000000000000000034284c27a2304132af751b0dec5bba2cf98ed0390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff0000000000000000000000000000000000000000000000000ddfd353fe326000”,
“method”: “updateConfig(address,(uint128,uint64,uint64))”
}
]

Considerations

This is a variable update that does not introduce new functionality into the protocol and hence has not been audited; it should simply work as expected, based on the MetaVault functionality previously audited by ABDK.

Discussion & voting

Please support this proposal on Snapshot: Snapshot

We welcome any questions & feedback regarding this proposal below - don’t hesitate to raise them.

2 Likes