State of things: The new Road-map

aldoborrero commented 1 year ago

Introduction

0xBeans was in charge of the development of mevETH up until recently. He might not continue developing the mevETH smart contracts.

On 0xBeans' repository, there were a couple of PRs and fixes that were proposed in the repo whilst the development of mevETH-controller was being in place and also by @sandybradley, but as you might expect, those were there accumulating dust for the reason I stated above.

On Thursday 25th, I decided to jump in with the determination to move forward with the development of the Smart Contracts seeing the delivery date is approaching fast, and work was stalled for several weeks.

The things I've done have been:

Migrate away from 0xBeans repository and create our forked version controlled by Manifold org.
Merged lingering PRs like manifoldfinance/mevETH2#105, and manifoldfinance/mevETH2#106 and also the addition of a framework to develop among different people like manifoldfinance/mevETH2#107, manifoldfinance/mevETH2#108
Started with the planification, from the existing codebase, with existing issues and remaining tasks to do (you can see the issue list being filled; also, I've created a backlog that allows us to prioritize tasks).
Getting myself familiar with the point of being able to continue the development of the contracts with different standards (like ERC4626 or LayerZero).

I have Solidity experience, but I'm not claiming I'm a Solidity rockstar with contracts that will contain hundreds of millions of dollars. Hence, the critical importance here is I'm reaching for help and cooperation. For several of you, I've been in touch on Slack. Still, it's better to surface important critical matters to everybody, so all of us are aligned to delivering this ASAP and safely whilst still providing features that will attract users to use Manifold.

As far as I know, people that are actively involved in this effort are:

@ControlCplusControlV
@sambacha
@j4848
@IlluvatarEru
@sandybradley

On the backend and DevOps part, we have @mevpig and @mevr2.

To that extent, I've created a shared communication channel on Slack called meveth-contracts (feel free to join).

A brief summary (ELI5)

The current implementation of the codebase is the following:

mevETH is a Liquid Staking Token (or LST). The user stakes Ether, and in return, it receives mevETH, which represents ownership of the staked Ether. Rewards are obtained through validation duties performed by Manifold.
ManifoldLSD is an ERC4626 vault that receives stakes from users but also performs the allocation necessary to register new validators on the beacon chain, once the accumulated Ether is 32 or higher.
In the current codebase, other ancillary contracts are specific for the implementation performed by 0xBeans.

Current open questions

There are open questions that I think are important to discuss before continuing efforts (I've created separate issues):

[x] manifoldfinance/mevETH2#102
[x] manifoldfinance/mevETH2#80
[x] manifoldfinance/mevETH2#85
[x] manifoldfinance/mevETH2#43
[x] manifoldfinance/mevETH2#95
[x] manifoldfinance/mevETH2#94

Please, read those, and let's agree on them so development can continue. Then, I will coordinate the effort and ensure everybody is aligned on all fronts.

Also, from the discussions above, I will plan and prioritize the tasks necessary to reach the finish line (🥇).

How the repository is structured

Right now the repository is using standard Git practices:

develop contains the most up-to-date version of the code.
main should contain the most stable version of the code (for now, we don't have any, as there hasn't been any release yet).

The backlog, once I finish adding more relevant tasks, will be ready to pick tasks so each of us can start working on them with minimal interference. I'll update this issue once everything is ready to go.

What I don't want

I don't want hero devs. However, we will have tasks assigned and agreed upon previously, so the sum of each part will contribute to the total.
I don't want big refactors or big PRs that rewrite the whole universe unless it makes sense. We need to go incremental (that doesn't mean slow) to build confidence and allow other team members to build knowledge and reasoning about the codebase. I don't want silos of information where only one dev knows about the whole project and makes the rest guess what's going on. This increases uncertainty, introduces noise, and in the end, makes the delivery more difficult.

ghost commented 1 year ago

I've just been told that 0xBeans will be returning shortly. Until he's back let's keep pushing ahead according to @aldoborrero structure, and we'll get 0xBeans up to speed when he returns.

sambacha commented 1 year ago

I've just been told that 0xBeans will be returning shortly. Until he's back let's keep pushing ahead according to @aldoborrero structure, and we'll get 0xBeans up to speed when he returns.

What? No.

aldoborrero commented 1 year ago

@sambacha we need to coordinate the effort among everybody and to reach agreements between involved parties on the current outstanding tasks. That way we don't introduce delays, expand deadlines, and other sorts of issues.

sambacha commented 1 year ago

@sambacha we need to coordinate the effort among everybody and to reach agreements between involved parties on the current outstanding tasks. That way we don't introduce delays, expand deadlines, and other sorts of issues.

Spoke with James, we are not using 0xBeans for development.

0xBeans commented 1 year ago

Hi just popping in.

ERC4626: This is just a vault math standard, quite prevalent in many yield aggregators. The good thing about this one is that the balance doesn't rebase, all reward calcs are done in another func. Caveat, mint 1e18 share to the vault or burn some eth into the vault to prevent donation attacks.

Withdrawals: This should be done in v2 after protocol stabilizes, should be upgradable using standard UUPS proxy or the likes (see ERC1967). See implementations in solmate, or solady, or even OZ for battle tested solutions

Upgradeability policy: Seeing that this is a centralized solution, a rigid policy is not necessary as manifold controls everything. Please use ERC1967 or similar proxies for upgradeability. If not familiar with deploying proxies and upgrading manually (via foundry), hardhat offers automated solutions.

Auth Registry: There's a few ways to do this, for cleanliness, this should just be a simple contract that adds in roles for various addresses function addRole(address newAddress) onlyRoleAdderRole. Each function that requires a role should have a modifier onlyOracle onlyManifold etc. If this auth registry is a completely separate contract that is deployed by itself (not via inheritance), keep in mind external calls add about 2300 gas overhead per external call.

What is sFOLD: This was a business requirement where FOLD holders could stake and earn rewards through ETH (which are earned by MEV by manifold).

What is the staking pool contract: It is a modified version of Synthetix staking (that zefram optimized) that can handle dynamic rewards. For instance, manifold can freely push up rewards at any time interval and it will properly distribute rewards based on the time interval set, this was to be used together with sFOLD. For example, at time t, manifold pushes X eth in rewards, maybe in a week at time t + 1 week, manifold pushes Y rewards, the staking vault will auto handle distributions (currently its over 7 days). The validity of sFOLD and staking is up in the air as manifold would need to make decent profits via MEV (and propose/build a shit ton of blocks), but it was a requirement in the doc.

sandybradley commented 1 year ago

Update:

main branch contains re-factored version of mevETH
develop branch contains modified 0xBeans version of mevETH

@ControlCplusControlV is finishing the core contract design before we start more periphery help. Some design change notes:

LayerZero has been dropped for security concerns
sFold has been dropped
OperatorRegistry, ManifoldLSD and MevETH contracts have been consolidated into 1 contract: MevEth
Ownership transfer from Two step to single step
Auth roles abstracted to admin and operator
mevETH is rebased, compatible with yearn

sandybradley commented 1 year ago

Work that can be migrated over from develop to main

... feel free to add

aldoborrero commented 1 year ago

@sandybradley wouldn't be more secure to use Two-Step ownership transfer?

sandybradley commented 1 year ago

Yes, in my opinion.

aldoborrero commented 1 year ago

OK, with the latest news, I'll create/update new tasks to accommodate the upcoming changes.

Also develop branch will be renamed to 0xBeans to avoid confussions.

ControlCplusControlV commented 1 year ago

Closing as efforts are now organized and migration tasks are complete

manifoldfinance / mevETH2