Closed GLCNI closed 1 year ago
Thanks for the report but this is Already documented and already fixed. Just hasn't been published yet.
https://github.com/dappnode/DAppNodePackage-teku/issues/34
Temporary fix documented in the issue above along with the whole reason why this occurs and also that it really doesn't matter for dappnode use cases but it's a simple enough fix took like 30 mins to do all 4 Teku clients and document it.
This is a warning, not a bug. The fee recipient address is set in the validator service. Setting the fee recipient address also in the beacon service is a good practice, but not mandatory.
Furthermore, the fee recipient address is set through the stakers UI, so first of all it must be implemented in the dappmanager something like "Set fee recipient address in both services: validator and beacon when applying".
If is not implemented first this feature in the dappmanager, it may result into errors when using empty string as fee recipient address in the beacon service of teku
@alexpeterson91 do we still have this issue?
Yes. It's still present as of 2.0.7 (23.3.1 upstream).
If you try to add it manually to EXTRA_OPTS as validators-proposer-default-fee-recipient
then beacon chain and validator won't start (complaining it's set twice).
Yes. It's still present as of 2.0.7 (23.3.1 upstream).
If you try to add it manually to EXTRA_OPTS as
validators-proposer-default-fee-recipient
then beacon chain and validator won't start (complaining it's set twice).
This is normal behaviour, the flag has already been set in https://github.com/dappnode/DAppNodePackage-teku-gnosis/pull/41 . You should not need to set it in EXTRA_FLAGS
TEKU version: 0.1.4 (22.11.0 upstream)
Describe the bug multiple users reporting the same issue after switching from Prysm to Teku, fee recipient address not being detected after set in config
FEE_RECIPIENT_ADDRESS
has been set in the consensus client config, web3signer client changed to Teku, beacon node syncs fully and keys detected in validator however in the beacon node logsWARN - Remote Validator Client detected and no default fee recipient has been configured via the validators-proposer-default-fee-recipient option! It is strongly recommended to configure it to avoid possible block production failures in case the node has not been prepared for potential proposers by the Validator Client.
To Reproduce