Fractionalised DV prototype 1

Problem to be solved

We want to explore the idea of fractionalising DVs, and also making them partially fungible. However, considering we are already in the business of spreading risk across operators, we do not want to spread risk across clusters too, as that could cause contagion and is a bit of a legal bad idea too.

So we want to explore partial fungibility and fractionalisation of DVs over the coming weeks, and we will user test these two concepts, and see which there is more demand for, and which makes more sense on a gas optimastion front too.

Proposed solution

This ticket is to use EIP 4626 to make a fractionalisation mechanism for a single cluster of operators.

How I think this will work is:

• We create an Operator Auth role. During contract deployment we pass an array of eth addresses that get this Operator role.
• These operators can add Deposit Data details to the DepositRegistry. This is an array of unactivated validator deposit files. We verify that the withdrawalAddress for this deposit is this contract (see this for exact formatting of withdrawal credentials field)
• We expose a method called deposit
  • It checks that this.balance > 32
  • It checks that DepositRegistry.length > 1
  • If both checks pass, it takes the deposit object, removes it from the DepositRegistry and sends the data in the object with a message.value 0f 32 eth to this contract function (the official deposit contract)

The above is just the activation logic, next we need to do the user facing accounting logic, this is where ERC4626 comes in.

Firstly, it is based on ERC20s, so we will need to import the Weth10 contract and will need to unwrap weth to deposit.

When someone sends us Weth, we issue them LP tokens. Later, we will implement withdrawals, and burning of LP tokens, but there is no code for that yet. We can start to test that functionality with forge's prank command, which allows arbitrary balance modifications.

Not yet outlined

How fees to operators and Obol are taken out. Likely we will depend on an 0xSplits contract that takes like 2%, half to the operators half to obol, but TBC

Start by reading the linked EIP-4626 reference and Solidity deposit contract, then review the proposed DepositRegistry, Operator Auth, deposit, and Weth10 integration entry points. The prototype is done when the single-cluster activation flow and initial Weth-to-LP accounting described here can be exercised with forge prank; withdrawals and fee handling are explicitly not yet outlined.