Handling exit requests
As the channels can automatically select a number of validators that should be stopped, the "Exit Daemon" is here to signal the exit requests on a given vFactory.
This utility is a REST endpoint and also a webhook for the operators to automate exit flow of the validators.
📝 You will run one Exit Daemon for one vFactory
You can find the exit daemon inside the operatord repository.
The daemon is configured using a config.yaml file, the same as the Oracle Daemon.
You have the option to either incorporate the following lines into a new configuration file or append them to the existing Oracle Daemon configuration file:
factory: Address of the operator vFactory (mandatory).
hook-endpoint: REST endpoint that will be called (POST) when a report is available (optional).
Then, we can run the exit daemon by running:
execution-node-url is an rpc endpoint on the execution layer (geth, erigon, etc...).
consensus-node-url is an rpc endpoint on the consensus layer (prysm, lighthouse, etc...).
config-file is the path to the file we configured above.
At every epoch (finalized), if exits are needed, the Exit Daemon craft a report for each withdrawal channel associated with the specified vFactory.
A report follows this JSON structure:
epoch: Epoch of the report
withdrawalChannel: Withdrawal channel id.
lastRequestTxHash: TX hash of the latest SetExitTotal event.
validatorCountToExit: Delta between the requested and actual exited validators.
totalCurrentlyExited: Total exited validators for the withdrawal channel.
suggestedValidatorExits: Lists suggested validators, providing their index and public key, that are eligible for exit. The suggested validators for exit are those with the oldest activationEpoch.
exitableValidators: Complete list of index / public Keys of all the currently exitable validators of the withdrawal channel.
The last (up to date) reports can be accessed using the REST API.
Every epoch, the daemon has the capability to forward the reports to an endpoint.
As outlined in the configuration, you can specify a hook-endpoint in the configuration file. This endpoint will be triggered with a POST request when a report becomes available.
To illustrate its operation, we've created a demo server:
The demo server accepts these reports and displays the corresponding JSON data in the terminal. It provides access to these reports via the /report route.