NethermindEth / NethermindEth/pluto

feat(app): submit proposal preparations on startup and each epoch (setFeeRecipient)

Open
#528 1 comment 0 reactions 1 assignee View on GitHub

@varex83 is already working on this.

Since Sep 17, 2026.

  • #592 by @varex83agent — open
enhancement rust track:orchestration-cli
Dominant language
Rust
Stars
8
Forks
5
Avg merge
4d 16h
Merged PRs (30d)
37

Description

Part of #402 — follow-up to the app-wiring PR.

Scope

Register the proposal-preparations (setFeeRecipient) scheduler slot subscriber: on startup and on each epoch's first slot, submit ProposalPreparation{validator_index, fee_recipient} for every active cluster validator to the beacon node. Charon registers this as the first slot subscriber (app/app.go:475-478; implementation at app.go:1145-1193) — keep that registration order.

This is financial correctness on proposals: without it the node's beacon node never learns the fee recipients, so any block the cluster adopts from this node's BN pays execution rewards to the BN's default address. Charon peers only prepare their own BNs, so they cannot cover for a Pluto node in a mixed cluster.

Also surface fee-recipient hex-parse errors while implementing this: build_validators (crates/app/src/node/mod.rs) currently maps malformed/missing lock addresses to the zero address via unwrap_or_default, whereas Charon surfaces a decode error at proposal-preparation time — this issue is the natural place to align that.

Dependencies

  • #527 — eth2api submit_proposal_preparations client method.

Acceptance

  • First subscribe_slot subscriber; on_startup || first_in_epoch gate; no-op on zero active validators (Charon parity).
  • Malformed fee-recipient addresses produce an error, not a silent 0x0.
  • Wiring test against beaconmock asserting the POST content on startup and on an epoch boundary.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.