Closed aldoborrero closed 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.
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.
@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 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.
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.
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 concernssFold
has been droppedOperatorRegistry
, ManifoldLSD
and MevETH
contracts have been consolidated into 1 contract: MevEth
mevETH
is rebased, compatible with yearnWork that can be migrated over from develop
to main
... feel free to add
@sandybradley wouldn't be more secure to use Two-Step ownership transfer?
Yes, in my opinion.
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.
Closing as efforts are now organized and migration tasks are complete
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:
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:
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:
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.Current open questions
There are open questions that I think are important to discuss before continuing efforts (I've created separate issues):
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