Fee Recipient Post Merge (WIP)

[james-prysm]

Post Merge, consensus clients will need to set an Eth 1 account when running a validator/beacon Chain in order to receive the fees on processing transactions while proposing a block. Currently, PoS validators only receive funds from the protocol and do not receive fees on the transactions themselves. Users would like a way to tell the Validator Client/ Beacon Node to change the fee recipients dynamically while the system is running.

Each validator index ( not public key according to this api ethereum/beacon-APIs#178) can have a fee recipient.

[james-prysm]

How do we protect this endpoint 🤔 ? is it merged into the existing endpoints or separate?

[dapplion]

To clarify this would be added to a validator_client oapi file not the keymanager right? Drawing similarities, the keymanager API does not handle graffiti.

[g11tech]

To clarify this would be added to a validator_client oapi file not the keymanager right? Drawing similarities, the keymanager API does not handle graffiti.

I think thats the proposal: to have a patch request to update fee-recipient (and may be graffiti too). Then the validator will update the beacon using beacon proposer api call. Right @james-prysm ?

But wouldn't this also necessitate a mappings DB validator side, as far as you know, your current implementation has this mapping updated in db beacon side.

[james-prysm]

I think thats the proposal: to have a patch request to update fee-recipient (and may be graffiti too). Then the validator will update the beacon using beacon proposer api call. Right @james-prysm ?

right for dynamic updating otherwise it'll use the burn address if you don't use any of the validator flags

But wouldn't this also necessitate a mappings DB validator side, as far as you know, your current implementation has this mapping updated in db beacon side.

i have it stored in memory right now but if the validator restarts it should probably use the updated file? we have it persisting on the beacon node side.

[james-prysm]

first spec used for fee recipient api merged in, closing issue.