Try   HackMD

CREAM and Manifold Finance Omnibus

[!abstract] CREAM and Manifold Finance

[!info] Updates
Wed, 05 Apr 2023 05:50:38 -0700
2023-04-04T19:24:56-07:00


Overview

Validator Service Protocol

  • v1 - first centralized
  • v2 - decentralize to DVT
  • Two Tiers: Institutional and Retail (minimums with lockups)

CREAM Depositors Compensation

Proposed: ~30,000 FOLD for 3 Months. ~10,000 FOLD per month. @ $40[1]

$ 1,200,000 FOLD @ $40.00 USD

~1.2 mil in FOLD 30,000 FOLD. Distribution within is 1/3 to all, remaining 2/3 to those who decide to stay.

Assets under Management

As of 2023-04-03 00:00 there is 25185.99543686883 (creth2_deposited)

Deposits started on: 2020-11-18
Amount: 3107.8

Deposits stoped growing on: 2021-08-18
Amount: 25185.7040010815[1:1]


Roadmap: Tentative planning
Milestones: Achievement based points related to execution of the roadmap

Yield and Revenue

Types of Yields

Types of yields in mevETH:

  • Base yield ETH from validators 5% goes to sFOLD holders rest goes to stakers

  • MEV yield whatever ETH we make by using securerpc/openmev 50% goes to stakers 50% payout router

  • LayerZero transfer fees whenever mevETH is bridged around networks for integration/payment/whatever 1-2bps goes to MEV project treasury

  • Liquidity pool incentives from Balancer/Aura anyone pledging sFOLD need to provide BPT tokens (Balancer liquidity pool receipt) Manifold stake in into Aura to recuperate the tokens selling 50% and distributing to mevETH stakers while the other 50% is locked voting for additional (Must pass analysis)

  • Fees on the mevETH (similar to LDO)

  • MEV fees

    • Restaking (v2)
  • Crosschain transfer (a few bps / premium on gas sent)

  • sFOLD staking is a LP position stake and we keep the incentives. Tentative Plan A.

v2 - Tokens

Utility: Govern capital.

As the space trends towards efficiency, basically all tokens will trend towards 0. They will be re-rated for the risks that they underwrite or adjusted for EV of capital owned. If they aren’t owning capital or underwriting risk, then they are useless over
the macro.

Token Model and Fees

v2: Distributed via Utility/Governance Token (i.e LDO).

Fees distributed via 'Payout Router'
Payout Router distributes Fees based off of Protocol Version.
Protocol Version

Jupyter Notebook

https://gist.github.com/sambacha/9f00971ff91de35252eef65e4996dd68

Distribution

50% Unminted / Protocol Treasury held in multisig
25% CREAM Multisig
25% Manifold Finance MasterChef Contract/Multisig

Terms for selling Team Allocation Tokens

Right of first refusal to Treasury and Manifold and CREAM teams
30 days to shop around the offer for OTC
If sold by open market TWAP of 24-48 hours

Protocol Roadmap

The tentative plan is to launch a base v1 layer protocol, then add functionality to the protocol (v1.5) and then deploy parts for additional capabilities resulting in a 'v2'.

v2 functionality is targeted towards large depositors and their requirements.

[!info] Version 1
v1 - Execute and minimal changes from original design requirements.
- LDT/LST
- Lending Markets
- DeFi Intergrations

[!info] Version 1.5
v1.5 - Restaking
Restaking is switched on. Note that Restaking can come with v1, as its extra-protocol implementation.

[!info] Version 2
v2:
Institutional Staking
Liquid Receipts
L2 Support?
DVT (Obol Network)
LRT Token (Liquid Warehouse Receipt Token)

Transaction Support Services

TX pool for next Manifold block

✔︎ Allow users to subscribe to their validators to the SecureRpc Transaction Pool

✔︎ Users submit transactions to the pool for the next block proposed by a managed validator

✔︎ Transaction tips are paid back to the protocol via MEV smoothing pool

MEV Metrics and KPI's

  • searcher take = bundle MEV - bundle inclusion cost
  • builder take = block MEV - winning bid
  • builder exclusive order volume fraction
  • builder extraction efficiency
  • builder bidding efficiency
  • proposer delay
  • proposer efficiency (or other function of proposer connectedness)

Milestones

Due to the dynamic nature of the ever-evolving Ethereum roadmap, simplicity is favoured in the choice of milestones.

Te first wave of credentials will be released when withdrawals are enabled. Subsequent waves are released over time on demand (for withdrawing).

  1. Release INITIAL_RELEASE validators at the time at which withdrawals from the beacon chain are enabled (WITHDRAWALS_ENABLED_TIME).
  2. for i, num_validators in enumerate(TIMED_RELEASES), release num_validators validators at time `WITHDRAWALS_ENABLED_TIME + (i + 1) * WITHDRAWL_QUEUE_DAYS

Validator Operations

Success metrics

Client/validator performance must consistently meet a set of success metrics to continue participation within the protocol.

The first NUM_PERFORMANCE validators of the deposited validators are tracked by operations to assess metrics. The last NUM_CANARIES validators of the deposited validators are free to be used by the protocol for attesting, building, restaking, etc.

Canary validators are not expected to constantly meet the success metrics on test net.

WIP

Metrics

Name Value Description
MIN_ACCEPTABLE_BALANCE 31.75 ETH Minimum acceptable balance of client validators
MIN_ATTESTATION_PERCENTAGE 95 percent Minimum acceptable percentage of attestations created by client validators
MIN_BLOCK_PERCENTAGE 95 percent Minimum acceptable percentage of blocks created by client validators

The following are the success metrics that operations must meet:

  • Client validators on average do not drop below MIN_ACCEPTABLE_BALANCE balance
  • Client validators have at least MIN_ATTESTATION_PERCENTAGE percentage of expected attestations included on chain over any METRICS_WINDOW epoch period
  • Client validators have at least MIN_BLOCK_PERCENTAGE percentage of expected blocks included on chain over any METRICS_WINDOW epoch period

Probation

If the Client drops below the success metrics, the Client’s incentivization status moves into probation. During a probationary period the Client has MAX_PROBATION_WINDOW epochs to get metrics back to successful standards, and during a probationary period the Client cannot have any validator credentials released. The amount of time spent in probation pushes back the release of any validator credentials by at least that amount of time.

If Client metrics remain in probationary status for more than MAX_PROBATION_WINDOW epochs, operations can at their discretion partially or fully remove the Client from the protocol and partially or fully exit the Client’s validators.

Slashing

In the event that one or more of a Client’s validators is slashed, such a validator is removed from the incentive protocol.

Note: Performance and canary validators are both subject to the slashing rules.

Consensus Layer Dependencies

While the Client is fully responsible to ensure that their operation is run in a performant and non-slashable way, we recognize that there is a limit to what execution layer teams can do to mitigate issues on the consensus layer (and vice-versa).

Specifically, this means we expect operations to adopt best practices with regards to running their validators, but will not penalize them in the case of a widespread consensus-layer issue. Best practices when running validators include:

  • Ensuring that the Client can interoperate with most/all major consensus clients, at least on canary validators;
  • Ensuring that the Client’s failures are decorrelated from the rest of the network, both by relying on diverse consensus layer clients and hosting setups;
  • Ideally ensuring that the Client’s validators are split across >1 consensus client in case of a consensus client-specific issue;
  • Ensuring that the Client has the ability to switch from one consensus client to another in the case of a consensus client-specific issue.

Terms

In general and especially in the event of exceptional and unforeseen scenarios concerning the client, the client team, the Ethereum roadmap, and/or the Ethereum mainnet, the operations team may adjust such procedures notwithstanding.,

Such exceptional scenarios include, but are not limited to, the following:

  • Client team ceasing the maintenance of a component (e.g. validator client) or the entirety of their software
  • Ethereum roadmap radically changing such that the milestones no longer reflect achievable goals
  • Ethereum mainnet has extended issues with stability, finality, or otherwise proper function
  • Ethereum mainnet undergoes a contentious hardfork

Business Operations

1. Relationship of the Parties

1.1 The parties agree to work together in good faith and to communicate openly and honestly with each other.

1.2 Neither party shall act in a way that would create a partnership or joint venture, nor will either party be authorized to act as an agent of the other, except as specifically set forth in this agreement.

2. Promotional Rights

2.1 Each party agrees to grant the other party the right to use its name and logo in connection with the promotion of the business relationship.

2.2 The parties agree to work together to promote the business relationship and to cooperate in any promotional activities.

3. No Conflicts

3.1 Each party represents and warrants that it is entitled to enter into this agreement and that its performance under this agreement will not violate any agreements or laws to which it is subject.

3.2 The parties agree to promptly notify each other of any potential or actual conflicts of interest that may arise during the business relationship.

3.3 The parties agree to work together in good faith to resolve any conflicts that may arise during the business relationship.

4. Compliance with Policies and Guidelines of other Institutions

4.1 Each party agrees to comply with all applicable laws, regulations, and policies of any governmental or regulatory authority having jurisdiction over its activities related to the business relationship.

4.2 Each party also agrees to comply with any policies or guidelines of any third-party institutions that are applicable to the business relationship.

Marketing and PR

Coordinate a consistent message between Manifold and CREAM communities, explaining why crETH2 holders are best served with Manifold Finance as the manager of this staked ETH, in order to best serve the interest of crETH2 holders.

Plan for April 10th/11th announcement from both Manifold and CREAM about the partnership, with the acquisition of the validator business. Value will be attributed to both CREAM and FOLD token holders.

Preliminary Plans

  • Roadshow
    • Interviews
    • Twitter Spaces

Blog Articles and Timeline

  1. Validator Overview
  2. mevETH Overview and crETH2
  3. ReStaking System
  4. Lending Markets/Protocol
  5. v1 to v2 Plan

Summary

TODO

Appendix

TODO


  1. It should be noted that nearly all the deposit balance was achieved in the first 3 months ↩︎ ↩︎