SecureRpc Relay v1.0 is being planned, here are some of the major points.
Proposed new RPC Methods
Planned for production support, working
eth_multicall
eth_estimateGasBundle
eth_submitRawBlock
Proposed, pending specification finalization and requirements
eth_watchCall
tx_simulateSwap
trace_replayTransactions
Relay and Builder
Track expired block submission rate
Track rejected block submission rate
Track ephemeral datasets
Track custom metrics
Network Improvements
Transaction Status and Error reporting issues, visability tracing
New API to expose fetching these requests
Attnet Peering Improvements
Fee Monitoring and collection
Ware provisioning discofees.eth / discofees.com for tracking validator profits and fees coming to us from the relay and builder processes.
Transaction Receipts
We are planning on taking this with the Network Improvements: Tx Status improvements and providing a new block explorer that will be brandable by wallets and Dapps involved with OpenMEV.
Other updates
Sushiswap frontend release this week, expect the router to go live afterwards!
A new update to the router will include support for sourcing liquidity from other markets, this is part of ‘Switchboard’. We will be using it to offer better trading execution for FOLD token (this means better pricing and cheaper costs!)
We are exploring integrating with a 3rd party to provide block building optimizations, more details soon!
Staking V2 technical preview before the end of the month
Items for community consideration
Searchers and FOLD: allocate a % of tokens to searchers interested in workin together with us. Either same terms as currently offered in the funding round or offer specific terms only to searchers.
Graffiti message, wat do?
Platform fees: How should fees be distributed? How much of a cut should builders, proposers, relays and validators split? What about DApps?
Please discuss these 3 items in this thread or opening a new thread!
Does this mean exclusivity (not sure how that would work in practice) or something else? If the goal is to incentivize more profitable blocks you could potentially have some type of rebate mechanism using the token (searcher payment as ‘x’ and rebate as some % of ‘y’) and have emissions taper down over time.
Lol no idea
Relay: 0% or something very close to cost
Dapp / wallet OF: suppose it would depend based on the wallet or app in question. Should be up to community and/or BD people (if any) to decide based on an outline or proposal from either manifold contributors or the dapp/wallet in question
Builder/searchers: should be up to market forces to determine and optimize against 1) health of ethereum the protocol and 2) long-term token value accrual
Proposer/validators: same answer as “builders/searchers”
Im gonna mainly focus on this… It makes 0 sense to underprice other relays… thats a race to 0… theres a lot of MEV to be extracted, no rush into underpricing it.
Also… do it for free? tbh I dont understand why are this even options… some people could think its “good” but it will suck for fold holders, why? cause we expect to benefit from this, not doing it in a charitable way lol
Fee cartel should be the way to move forward, as I said theres A LOT of MEV to be extracted and manifold could be greatly benefited without having to underprice = profit decaying over time cause other relays would start doing the same thing.
These issues all seem very pertinent and important, but I don’t really feel able to make decisions on them when it feels there are a number of fundamental things we don’t know, such as:
• Has block-building begun? How is it progressing and is it expected to ramp up?
• Are we still relaying to FlashBots? What’s the timeline for discontinuing that?
• What have we learned since the merge, in terms of metrics?
• Are there currently substantial technical improvements that need to be made to current implementations, or are we in a “monitor-and-tweak” situation?
• Are discussions with large stakers (like pools) proceeding, and should we anticipate that our share of connected validators will continue to increase steeply?
Without having insight into these and other questions—of which the community certainly has many—I’m not sure if we can contribute productively to decision making.
Planned for production support, working
Proposed, pending specification finalization and requirements