Skip to content

Decouple signed builder auth data from the HTTP dial target - #17124

Open
terencechain wants to merge 1 commit into
developfrom
builder-proxy
Open

Decouple signed builder auth data from the HTTP dial target#17124
terencechain wants to merge 1 commit into
developfrom
builder-proxy

Conversation

@terencechain

@terencechain terencechain commented Jul 7, 2026

Copy link
Copy Markdown
Collaborator
  • Adds per-builder builders entries to proposer settings builder config: url is the HTTP dial target, optional auth_data (0x-hex bytes) is signed into request auths and defaults to the UTF-8 bytes of url, optional pubkey credits execution payments only from that builder, optional max_execution_payment, min_bid, and builder_boost_factor override the config-level defaults. relays remains a deprecated alias; duplicate (url, auth_data) entries are rejected.
  • One signed request auth per (pubkey, slot, auth_data) authenticates both getExecutionPayloadBid and submitBuilderPreferences. The beacon node routes by url only and forwards auths byte-for-byte unchanged, so proxying needs no special support: point url at the sidecar and set auth_data to identify the downstream builder.
  • Moves the builder entries onto the block request so proposals no longer depend on a preference push having repopulated a restarted beacon node.
  • Aligns the HTTP client with builder-specs#165: the auth body is required on getExecutionPayloadBid, Date-Milliseconds and X-Timeout-Ms headers are sent on bid requests, and Eth-Consensus-Version is dropped from the request-auth endpoints since their bodies are not fork-versioned.

Example config:

{
  "version": 2,
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3",
      "gas_limit": "45000000",
      "builder": {
        "enabled": true,
        "builders": [
          {
            "url": "https://builder-a.example.com",
            "pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a",
            "max_execution_payment": "250000000"
          },
          {
            "url": "https://sidecar.example.com",
            "auth_data": "0x68747470733a2f2f6275696c6465722d622e6578616d706c652e636f6d",
            "min_bid": "10000000",
            "builder_boost_factor": "150"
          }
        ],
        "max_execution_payment": "500000000"
      }
    }
  },
  "default_config": {
    "fee_recipient": "0x8943545177806ED17B9F23F0a21ee5948eCaa776",
    "builder": {
      "enabled": true,
      "builders": [
        {"url": "http://buildoor-lodestar-nethermind-2-1:8080"},
        {"url": "http://buildoor-lodestar-nethermind-2-2:8080"}
      ],
      "max_execution_payment": "18446744073709551615"
    }
  }
}

Entry fields: url required (where requests are sent), auth_data/pubkey and the per-builder limits optional. An entry without auth_data signs the UTF-8 bytes of its url; an entry without pubkey accepts execution payments from any builder on that channel up to its cap. default_config applies to every key, so large operators define builder entries once; proposer_config is only for keys that deviate.

@JasonVranek

Copy link
Copy Markdown

LGTM and really appreciate this. Without this change, optional sidecars would be unable to route signed request authorizations to downstream builders. This will preserve out-of-protocol experimentation without friction 😄

@terencechain terencechain changed the title Decouple signed builder URL from the HTTP dial target Decouple signed builder auth data from the HTTP dial target Jul 24, 2026
@james-prysm james-prysm mentioned this pull request Jul 24, 2026
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants