> For the complete documentation index, see [llms.txt](https://docs.kiln.fi/v1/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiln.fi/v1/kiln-products/onchain/node-operators-how-to-integrate/deprecated-dedicated-validators-v1/deprecated-manage-validators.md).

# \[Deprecated] Manage Validators

## Provision new validation keys

The Operator can generate new validation keys and upload their deposit data to the Staking Contract to make them available to fund. Note that they need to be approved by SYS\_ADMIN before being able to be funded.

The Staking Contract generates deterministically CL / EL Recipient addresses from the validator public key. To know the withdrawal\_credentials of the validators to generate (ie their CL Recipient), the recommended setup is:

1. Generate a new validation key
2. call the `getCLFeeRecipient(bytes calldata _publicKey)` view function with the validator public key as parameter
3. Re-create the signature of the validator deposit data with the address outputed during step 2 as withdrawal\_credentials

Once the keys are generated with the proper withdrawal\_credentials, they can be registered on the Deposit Contract with: 

* OPERATOR calls `addValidators(uint256 _operatorIndex, uint256 _keyCount, bytes calldata _publicKeys, bytes calldata _signatures)` to upload multiple public keys and their signatures

## Make Operator keys available to deposit

SYS\_ADMIN can approve the keys uploaded by the OPERATOR with the following call:

* `setOperatorLimit(uint256 _operatorIndex, uint256 _limit)` to set the new number of approved keys for the operator `_operatorIndex`

It is recommended that the SYS\_ADMIN verifies the validation keys before approving them (no duplicates, valid signatures etc). To do so Kiln provides a verification utility available [here](https://github.com/kilnfi/staking-contract-key-checker).

## Manage Validator Exit Requests

At any point in time, a validator owner (ie staker) can notify onchain the operator that it wants to exit a validator.

When doing the `requestValidatorsExit` function call, the validator owner emits one event per validator exit request.

This event is as follow:

* `event ExitRequest(address caller, bytes pubkey)` where `caller` is the validator owner address and `pubkey` the validator public key to exit. This event is emitted only if the caller is the owner of the validator registered in the Smart Contract

It is expected that Operators watch for these events and trigger accordingly the exit of the requested validators within 48 hours.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kiln.fi/v1/kiln-products/onchain/node-operators-how-to-integrate/deprecated-dedicated-validators-v1/deprecated-manage-validators.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.