# 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 --- [TOC] ## 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]: This may be adjusted to reflect price action. $ 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]: It should be noted that nearly all the deposit balance was achieved in the first 3 months --- Roadmap: Tentative planning Milestones: Achievement based points related to execution of the roadmap ## Yield and Revenue > [!note] 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. >[!warning] 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