NethermindEth / NethermindEth/pluto
feat(app): submit proposal preparations on startup and each epoch (setFeeRecipient)
- 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_preparationsclient method.
Acceptance
- First
subscribe_slotsubscriber;on_startup || first_in_epochgate; 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.