Summary
mev_sendBundle calls are consistently rejected with -32025 invalid flashbots signature, using the exact same signing implementation that works correctly for eth_sendBundle against the same relay.
Error received
{"jsonrpc": "2.0", "error": {"code": -32025, "message": "invalid flashbots signature"}, "id": null}
What works fine (control case)
eth_sendBundle and eth_callBundle against relay.flashbots.net, using the same auth key and signing function below. These succeed consistently.
Signing implementation (Python)
message = encode_defunct(text=Web3.keccak(text=payload_str).hex())
signed_msg = Account.sign_message(message, private_key=FLASHBOTS_AUTH_KEY)
signature = f"{auth_account.address}:{signed_msg.signature.hex()}"
# sent as X-Flashbots-Signature header
mev_sendBundle payload
{
"jsonrpc": "2.0",
"method": "mev_sendBundle",
"params": [{
"version": "v0.1",
"inclusion": {"block": "0x...", "maxBlock": "0x..."},
"body": [
{"hash": "0x<pending_tx_hash_from_event_stream>"},
{"tx": "0x<our_signed_backrun_tx>", "canRevert": false}
]
}],
"id": 1
}
What I've already ruled out
- Auth key correctness — verified length/prefix/suffix, same key works for
eth_sendBundle
- Signing logic — identical to the proven-working
eth_sendBundle implementation
privacy.builders field — removed entirely per docs noting hash-referenced ("unmatched") bundles can't use privacy; same error persists regardless
- Also tested
mev_simBundle with the same body shape — identical -32025 error there too
Question
Given identical signing code succeeds for eth_sendBundle but fails for mev_sendBundle/mev_simBundle against the same relay, is there a known difference in how MEV-Share specifically validates the signature — a different expected payload serialization, a registration/reputation requirement specific to MEV-Share endpoints, or something else I'm missing?
Happy to share more detail (redacted addresses/hashes) if useful. Thanks!
Summary
mev_sendBundlecalls are consistently rejected with-32025 invalid flashbots signature, using the exact same signing implementation that works correctly foreth_sendBundleagainst the same relay.Error received
{"jsonrpc": "2.0", "error": {"code": -32025, "message": "invalid flashbots signature"}, "id": null}What works fine (control case)
eth_sendBundleandeth_callBundleagainstrelay.flashbots.net, using the same auth key and signing function below. These succeed consistently.Signing implementation (Python)
mev_sendBundle payload
{ "jsonrpc": "2.0", "method": "mev_sendBundle", "params": [{ "version": "v0.1", "inclusion": {"block": "0x...", "maxBlock": "0x..."}, "body": [ {"hash": "0x<pending_tx_hash_from_event_stream>"}, {"tx": "0x<our_signed_backrun_tx>", "canRevert": false} ] }], "id": 1 }What I've already ruled out
eth_sendBundleeth_sendBundleimplementationprivacy.buildersfield — removed entirely per docs noting hash-referenced ("unmatched") bundles can't useprivacy; same error persists regardlessmev_simBundlewith the same body shape — identical-32025error there tooQuestion
Given identical signing code succeeds for
eth_sendBundlebut fails formev_sendBundle/mev_simBundleagainst the same relay, is there a known difference in how MEV-Share specifically validates the signature — a different expected payload serialization, a registration/reputation requirement specific to MEV-Share endpoints, or something else I'm missing?Happy to share more detail (redacted addresses/hashes) if useful. Thanks!