# cross-client builder submission support > thanks to @lightclient for helpful discussions right now, most of the mev-boost ecosystem relies on the [flashbots/builder](https://github.com/flashbots/builder) software to validate block submissions at the mev-boost relay. this software is a fork of geth and this fact implies 1. overhead of maintaining the fork - especially an issue when tracking changes around devnets for hard forks, etc 2. lack of client diversity - exaggerated by the volume of mainnet blocks going through this software we can improve the situation on both counts by refactoring the builder submission flow so that it can be supported by any of the execution clients and not just geth. ## requirements to validate builder submissions, the relay must maintain a view of the beacon chain and execution chain. a given block submission must be for a tip of the chain the relay knows about and match the expected consensus parameters for the expected slot and proposer. the submitted execution payload is simulated on the tip of this chain to ensure it is a valid execution payload. most relays rely on a consensus client for the consensus parameters and then call out to the `builder` software for the execution verification. This verification is currently exposed via a JSON-RPC endpoint with method name `flashbots_validateBuilderSubmissionV2`. this RPC endpoint does the following: 1. verify the execution payload's header 2. verify the execution of the block 3. verify the gas limit matches the validator's registered preference 4. verify payment was made to the validator in line with the bid value ## proposal ### block validation functions (1) and (2) can be supported by a cross-client JSON-RPC endpoint that validates blocks: `eth_validatePayload`: - inputs: ExecutionPayload - outputs: receipts resulting from execution, or error if something failed ### proposer gas validation function (3) can be done without the support of an execution client, and this logic can simply remain w/ the builder or even relay code assuming the gas limit was valid with respect to the protocol from the prior API call, then we just have to check that the block gas limit was either the validator's registered limit or as close as it could be within the allowed protocol tolerance of +/- 1/1024 (i.e. [`GasLimitBoundDivisor` here](https://github.com/flashbots/builder/blob/main/core/utils/gas_limit.go#L5)) ### proposer payment validation function (4) would also benefit from some cross-client method to verify the payment. the current `builder` software uses the last transaction in the block, but there is an ongoing effort to support more payment methods. one option for the current scheme is to: 1. get last receipt from `eth_validatePayload` suggested above and ensure the status was successful 2. grab the last transaction from the `ExecutionPayload` and verify - transaction recipient matches the expected fee recipient - transaction value matches the expected value declared in the builder's bid - empty transaction calldata - transaction gas price is equal to the block's base fee with 0 tip note: all of this can be done without querying the execution client outside of `eth_validatePayload` to ensure the transaction succeeded