[EIP-8148] Implement a POC

[nalepae]

What type of PR is this?
Other

What does this PR do? Why is it needed?
POC: Implement EIP-8148 (custom sweep threshold for validators).

• https://eips.ethereum.org/EIPS/eip-8148
• https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip8148

Important

No EL currently supports the Heze fork, so we chose to build this POC as part of the Gloas fork rather than the Heze fork.

Important

No EL currently supports this EIP, so we chose to implement a custom debug endpoint directly in Prysm to "simulate" a sweep threshold change coming from the EL. This endpoint is /prysm/v1/debug/beacon/sweep_threshold_requests.

This comes with some limitations, like a very limited Dora support.

Kurtosis configuration file

participants:
  - cl_type: prysm
    cl_image: prysm-bn-custom-image:latest
    vc_type: prysm
    vc_image: prysm-vc-custom-image:latest
    count: 3

network_params:
  gloas_fork_epoch: 1
  seconds_per_slot: 4

  withdrawal_type: "0x02"
  withdrawal_address: "0x8943545177806ED17B9F23F0a21ee5948eCaa776"
  validator_balance: 32 

additional_services:
  - dora
  - spamoor
  - assertoor

spamoor_params:
  image: ethpandaops/spamoor:master
  spammers:
    - scenario: eoatx
      config:
        throughput: 10
    - scenario: blobs
      config:
        throughput: 6

dora_params:
  image: dora-custom-image:latest

global_log_level: debug

The Dora docker image must be built from https://github.com/nalepae/dora.

docker build -t dora-custom-image:latest . 

Recipe:

1. Run the devnet with Kurtosis
2. Once the Gloas fork Epoch is reached, you can check the validator_sweep_thresholds values in the beacon state.

curl <beacon-url>/eth/v2/debug/beacon/states/head | jq '.data.validator_sweep_thresholds'
[
  "2048000000000",
  "2048000000000",
  "2048000000000",
  "2048000000000",
  "2048000000000",
  ...
]

Everything should be set at 2048 ETH.

3. Send a fake 2048 ETH -> 33ETH withdrawal threshold change request for validators 0 and 1 to the beacon node with:

curl -X POST <beacon-url>/prysm/v1/debug/beacon/sweep_threshold_requests \
    -d '{
      "requests": [
        {
          "source_address":   "0x8943545177806ed17b9f23f0a21ee5948ecaa776",
          "validator_pubkey": "0xaaf6c1251e73fb600624937760fef218aace5b253bf068ed45398aeb29d821e4d2899343ddcbbe37cb3f6cf500dff26c",
          "threshold":        "33000000000"
        },
        {
          "source_address":   "0x8943545177806ed17b9f23f0a21ee5948ecaa776",
          "validator_pubkey": "0x8aa5bbee21e98c7b9e7a4c8ea45aa99f89e22992fa4fc2d73869d77da4cc8a05b25b61931ff521986677dd7f7159e8e6",
          "threshold":        "33000000000"
        }
      ]
    }' | jq

You should see in the beacon logs:

[2026-08-11 14:20:57.22]  INFO gloas: Processing EIP-8148 set sweep threshold requests from the parent payload count=2 slot=56
[2026-08-11 14:20:57.22]  INFO gloas: Applied EIP-8148 set sweep threshold request balance=32000899755 effectiveSweeps=will sweep once balance and effective balance both exceed the threshold previous=2048000000000 pubkey=0xaaf6c1251e73fb600624937760fef218aace5b253bf068ed45398aeb29d821e4d2899343ddcbbe37cb3f6cf500dff26c threshold=33000000000 validatorIndex=0
[2026-08-11 14:20:57.22]  INFO gloas: Applied EIP-8148 set sweep threshold request balance=32000046970 effectiveSweeps=will sweep once balance and effective balance both exceed the threshold previous=2048000000000 pubkey=0x8aa5bbee21e98c7b9e7a4c8ea45aa99f89e22992fa4fc2d73869d77da4cc8a05b25b61931ff521986677dd7f7159e8e6 threshold=33000000000 validatorIndex=1

then:

curl <beacon-url>/eth/v2/debug/beacon/states/head | jq '.data.validator_sweep_thresholds'
[
  "33000000000",
  "33000000000",
  "2048000000000",
  "2048000000000",
  "2048000000000",
  ...
]

The values of validator_sweep_thresholds in the beacon state for validators 0 and 1 are now 33 ETH. The rest is still 2048 ETH.

Now, you can wait for a long time for the effective balance of validators 0 and 1 to reach 33.25 ETH, or you can make a deposit.

4. To make a deposit, copy this test file on your system:

id: eip8148-topup-deposit
name: "EIP-8148: top-up deposit to trigger a custom-threshold sweep"
timeout: 30m
config:
  validatorPubkey: ""
  topUpAmount: 2
  depositContract: "0x00000000219ab540356cBB839Cbe05303d7705Fa"
tasks:
  - name: check_clients_are_healthy
    timeout: 5m
  - name: generate_deposits
    timeout: 10m
    config:
      limitTotal: 1
      limitPerSlot: 1
      topUpDeposit: true
      awaitReceipt: true
      failOnReject: true
    configVars:
      publicKey: "validatorPubkey"
      depositAmount: "topUpAmount"
      depositContract: "depositContract"
      walletPrivkey: "walletPrivkey

and register it to Assertoor with:

curl -X POST <assertoor-url>/api/v1/tests/register -H 'Content-Type: application/yaml' --data-binary @<path-to-the-test-yaml-file> | jq

Important

Don't forget the @ before the file path.

5. Once done, trigger a 2 ETH deposit for the validator 0 with:

curl  -X POST <assertoor-url>/api/v1/test_runs/schedule \
  -d '{"test_id":"eip8148-topup-deposit",
        "config":{
       "validatorPubkey":"0xaaf6c1251e73fb600624937760fef218aace5b253bf068ed45398aeb29d821e4d2899343ddcbbe37cb3f6cf500dff26c",
          "topUpAmount":2
        }}' | jq

6. Once the sweep is done for this validator, you should see:

curl http://<beacon-url>/eth/v1/beacon/states/head/validators/0xaaf6c1251e73fb600624937760fef218aace5b253bf068ed45398aeb29d821e4d2899343ddcbbe37cb3f6cf500dff26c | jq '{index: .data.index, balance: .data.balance, effective_balance: .data.validator.effective_balance, status: .data.status}'
{
  "index": "0",
  "balance": "33000000427",
  "effective_balance": "34000000000",
  "status": "active_ongoing"
}

(balance is slightly higher than 33 ETH and effective_balance is exactly 34 ETH)

After the start of the next epoch, the same request should return:

{
  "index": "0",
  "balance": "33000000427",
  "effective_balance": "33000000000",
  "status": "active_ongoing"
}

(balance is slightly higher than 33 ETH and effective_balance is exactly 33 ETH)

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).