proposer preference rest

[james-prysm]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

• adding /eth/v1/validator/proposer_preferences POST endpoint, also hooks up validator client
• adding proposer_preferences SSE event topic on /eth/v1/events

kurtosis setup

participants:
  - el_type: ethrex
    el_image: ethpandaops/ethrex:glamsterdam-devnet-4
    el_extra_params:
      - --http.api=eth,net,web3,admin
    cl_type: prysm
    cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest
    vc_image: gcr.io/offchainlabs/prysm/validator:latest
    supernode: true
    count: 2
    cl_extra_params:
      - --subscribe-all-subnets
      - --verbosity=debug
    vc_extra_params:
      - --enable-beacon-rest-api
      - --verbosity=debug

  - el_type: ethrex
    el_image: ethpandaops/ethrex:glamsterdam-devnet-4
    el_extra_params:
      - --http.api=eth,net,web3,admin
    cl_type: prysm
    cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest
    vc_image: gcr.io/offchainlabs/prysm/validator:latest
    validator_count: 63
    cl_extra_params:
      - --verbosity=debug
    vc_extra_params:
      - --enable-beacon-rest-api
      - --verbosity=debug

network_params:
  fulu_fork_epoch: 0
  gloas_fork_epoch: 2
  seconds_per_slot: 6
  genesis_delay: 40

additional_services:
  - dora

global_log_level: debug

depends on #16421 + adding some connection changes for ptc duties
for more perfect run otherwise you will see some orphans

Which issues(s) does this PR fix?

implements ethereum/beacon-APIs#608 changes
note: this pr does not implement deprecation or the get proposer preferences endpoint

Other notes for review

Acknowledgements

• I have read CONTRIBUTING.md.
• I have included a uniquely named changelog fragment file.
• I have added a description with sufficient context for reviewers to understand this PR.
• I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable).

[satushh]

Should there be a nil check on operationNotifier ?

[james-prysm]

no operationNotifier should be initialized at startup

[syjn99]

LGTM.

Done some local testing with these:

Kurtosis config

PR description.

Submitting the preference

Modified validation function a bit: To ignore signature. (for building data conveniently)

Bash script to generate a `proposer_preferences.json`

BN=http://127.0.0.1:33113
SLOTS_PER_EPOCH=$(curl -s "$BN/eth/v1/config/spec" | jq -r '.data.SLOTS_PER_EPOCH')
GLOAS_FORK_EPOCH=$(curl -s "$BN/eth/v1/config/spec" | jq -r '.data.GLOAS_FORK_EPOCH')
HEAD_SLOT=$(curl -s "$BN/eth/v1/beacon/headers/head" | jq -r '.data.header.message.slot')
echo $BN
echo $SLOTS_PER_EPOCH
CUR_EPOCH=$((HEAD_SLOT / SLOTS_PER_EPOCH))
TARGET_EPOCH=$((CUR_EPOCH + 1))

if [ "$TARGET_EPOCH" -lt "$GLOAS_FORK_EPOCH" ]; then
  echo "Too early: current epoch=$CUR_EPOCH, Gloas fork epoch=$GLOAS_FORK_EPOCH. Wait until epoch $((GLOAS_FORK_EPOCH - 1))."
  exit 1
fi

DUTIES=$(curl -s "$BN/eth/v2/validator/duties/proposer/$TARGET_EPOCH")

DEPENDENT_ROOT=$(echo "$DUTIES" | jq -r '.dependent_root')
PROPOSAL_SLOT=$(echo "$DUTIES" | jq -r '.data[0].slot')
VALIDATOR_INDEX=$(echo "$DUTIES" | jq -r '.data[0].validator_index')
SIG="0x$(printf '00%.0s' {1..96})"

jq -n \
  --arg dependent_root "$DEPENDENT_ROOT" \
  --arg proposal_slot "$PROPOSAL_SLOT" \
  --arg validator_index "$VALIDATOR_INDEX" \
  --arg signature "$SIG" \
  '[{
    message: {
      dependent_root: $dependent_root,
      proposal_slot: $proposal_slot,
      validator_index: $validator_index,
      fee_recipient: "0x0000000000000000000000000000000000000000",
      target_gas_limit: "30000000"
    },
    signature: $signature
  }]' > proposer_preferences.json

Request with:

$ curl -i -X POST "$BN/eth/v1/validator/proposer_preferences" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Eth-Consensus-Version: gloas" \
  --data @proposer_preferences.json

HTTP/1.1 200 OK
Vary: Origin
Date: Mon, 08 Jun 2026 17:10:12 GMT
Content-Length: 0

proposer_preferences event:

$ curl -N "$BN/eth/v1/events?topics=proposer_preferences"

Result:

event: proposer_preferences
data: {"version":"gloas","data":{"message":{"dependent_root":"0x4fbae0555738e07f528dd408dced944daf5998f3d4349889f5c65c0f4014fdb8","proposal_slot":"64","validator_index":"33","fee_recipient":"0x0000000000000000000000000000000000000000","target_gas_limit":"30000000"},"signature":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}}

Note that the fee recipient becomes zero hash as I built the data.

Also checked with Dora.