1. Does the native delegation module automatically detect the network of the connected node?

Yes! The connected Ethereum network (Goerli or Ethereum) is detected by querying the beacon node that was configured when starting MEV Plus and extracting the correct chain. No need to specify any special flags on start up.

2. I am managing many validators. Can I register all of them?

Yes! Your validators are registered in batches when interacting with the smart contracts. This is all automated. Additionally, the native delegation module will allow you to specify a max GAS price you are willing to pay so that network spikes don’t affect you. Not every transaction in the Ethereum network has immediate urgency.

3. I am already running MEV Boost. Is that a problem?

Not a problem! Native delegation works alongside MEV boost. In general your node operations will have minimal impact - it should be business as usual. When configuring MEV plus and native delegation, you simply need to tell the software what port Boost is running on and you also need to update your beacon node. This is all detailed in the tutorial. If your staking configuration is not compatible - let us know!

4. When would registrations happen?

Pre-registration and native delegation status checks are driven by your beacon node every epoch. As per the default specification of all beacon clients, validator registration messages are signed by every active validator. This will trigger a hook in Plus that will check whether on-chain registrations and native delegation have been performed. If the registrations have not been performed, eligibility checks are conducted, keys are split into transaction batches and the transactions are fired with the representative account. This is all taken care of by the native delegation module.

5. Would these registrations affect my normal relay registrations?

Native delegation and pre-registration do not affect your PBS relay registrations. That is taken care of by MEV Boost and native delegation does not interfere with that flow in any way.

6. Do I need to sign anything myself?

Only if you don’t use the native delegation module since you would need to use the K2 SDK instead: https://docs.restaking.cloud/k2/k2-native-delegation-sdk

7. Funds Safu?

K2 native delegation module does not have access to any of your validator signing keys - security is top priority. MEV + K2 delegation module is your airgap friendly validator fren

8. Can I change my execution and/or beacon node URL?

You should be connected to the node where the validator is running so that the validator keys can be correctly detected. Since Ethereum is not recommending using an external execution endpoint, we follow that advice too.

9. Where do I set the contract addresses?

No need to worry about this. The module is already pre-configured with the correct smart contracts.

If you want to verify you have downloaded the correct software and are interacting with the correct contracts you can check the following repo: https://github.com/restaking-cloud/K2-contract-deployments

10. What happens when I change the validator keys on my node?

New keys are automatically detected and at the next epoch will be registered. The representative needs to decide themselves which keys need to be de-registered. Validators that leave the beacon chain will be kicked by the K2 protocol reporters.

11. What is the representative address?

It is the execution layer address that represents the validators that are registered on-chain and act on their behalf like in the case of native delegation it is the representative that gives consent for the staked balance on consensus layer to be re-staked into K2. The representative address is NOT the same as the fee recipient address.

12. Can I have a different payout/fee recipient?

Yes if you run the web3 signer you can configure a different fee recipient to the one configured on your node. The web3 signer software used in the native delegation module or Plus never has direct access to your validator keys. If a web3 signer url is provided to the module the signatures are automatically generated during the registration processes.

Fee recipient management is particularly useful, if you are a node runner for staking pool, DVT platforms where you need to assign the rewards to a fund splitter contract for a specific protocol.

13. I am a DVT node operator. Can I participate?

Yes! It is only important that your beacon node is compliant with the Ethereum specification and signing the appropriate registration messages. Importantly, from an operational perspective, no changes required. Just point your validators address to its DVT cluster fund splitter address for receiving K2 yield.

My question was not answered!

Do you have any burning questions?

Please submit via following form

We will get back to you and add if it’s relevant to others as part of the FAQ.