Proposal: Introducing higher-level struct and abstractions for the RPC MEV-Share client

[optimiz-r]

Hello,

After noticing @zeroXbrock's request for a Rust MEV-Share client on X/Twitter, I began working on an implementation.

Now that I'm aware of this repo, I'm unsure whether to publish mine on crates.io. I'm concerned about contributing to DX confusion or decision fatigue. I'm considering whether it makes more sense to refactor my code into a higher-level struct on top of this modular implementation (which is of top quality, by the way) or simply PR the diffs here and archive mine.

The benefits I'd like to retain in the client include:

• The ability to client.send_bundle(params).await?.inclusion().await?
• The ability to initialize a client without the use of a tower::ServiceBuilder and to abstract the signing away.

Regarding 1: Your implementation currently returns Ok() when the bundle is accepted by the relayer. However, I find it useful to keep the inclusion logic abstracted within the client lib.

You can view my take on it here. With this, usage can be extended to:

client
    .send_bundle(params)
    .await? // relayer accepted the bundle
    .inclusion()
    .await?; // bundle was included in a block

Regarding 2: Since there's only one signing logic/method, it makes sense to abstract it.

Unsure if I should retain these enhancements in my repo or if they're better suited here.

I'd be happy to draft a PoC PR if you think this is a good direction: I’m considering introducing a higher-level mev_share_rpc::RpcClient in a new mev-share-rpc crate which would operate using mev-share-rpc-api, and maintain the same abstraction level as the existing mev_share_sse::EventClient.

Of course, if you have a different direction in mind or feel the other approach would be more suitable, I'm entirely open to that as well.

Cheers

[mattsse]

cool,

having a better client dx would be great.

I'm okay with enhancing/revamping client trait completely