# Staking Guide

* [Pectra Compatibility](#pectra-compatibility)
* [Staking using the Batch Contract](#staking-eth-using-the-batch-contract)
* [Staking without the Batch Contract](#staking-eth-without-the-batch-contract)
* [Staking without batch contract (using raw deposit data)](#staking-without-batch-contract-using-raw-deposit-data)
* [Consolidation and Switching](#consolidation-and-switching)
* [Exiting an Ethereum Validator](#exiting-an-ethereum-validator)

### Pectra Compatibility

Our node APIs support both 0x01 type and 0x02 type validators depending on your needs. You can choose to stake either 0x02 type validators or 0x01 type validators through our [Luganodes’ Node Provisioning APIs](/apis/ethereum/node-provisioning-apis.md) by setting the `compounding` parameter to `true` or `false` while calling the [Provision Request API](/apis/ethereum/node-provisioning-apis.md#provision-request). \
\
Additonally, clients can set the `amountPerValidator` based on their requirements and it is set to 32 when `compounding` is set to `false`.

### **Staking ETH using the Batch Contract**

The ETH Staking contract currently supports only one deposit transaction at a time. Clients looking to stake large amounts of ETH would have to make many transactions in multiples of 32 ETH ( for 0x01 type validators ) or any value from 32 - 2048 ETH ( for 0x02 type validators ). This can be simplified by using a Batch contract which can club 100 deposits into a single transaction for the user.

Use [Luganodes’ Node Provisioning APIs ](/apis/ethereum/node-provisioning-apis.md)to stake ETH. The steps are as follows:

1. Sign up using the [Signup API](/apis/ethereum/authentication.md#sign-up) with your organisation details to receive your API key.
2. Initiate the provision of nodes by calling the [Provision Request API](/apis/ethereum/node-provisioning-apis.md#provision-request) with `batch` parameter as `true`. The API triggers the creation of nodes by Luganodes in the background. Allow some time (\~4 mins for 100 validators) for the creation of deposit details required for transaction signing before calling the next API
3. Retrieve the unsigned transaction object `depositInput`, by calling the [Get Validator Objects API](/apis/ethereum/node-provisioning-apis.md#get-validator-objects). Use `depositInput` as transaction data to execute the deposit transaction on the Batch Contract address mentioned below

<table data-header-hidden><thead><tr><th width="293"></th><th>Chain</th></tr></thead><tbody><tr><td>Batch Contract Address (Hoodi)</td><td>0xCdf86Bf3E4B2D8777F1e6C70D6C694936c3459A6</td></tr><tr><td>Batch Contract Address (Mainnet)</td><td>0x33c10a5518a881ABfe318758646bB8C7cE613704</td></tr></tbody></table>

{% hint style="info" %}
The batch contract used is a forked version of Kiln's [contract](https://github.com/kilnfi/vyper_batch_deposit) that has been audited by Runtime Verification Inc.
{% endhint %}

4. Post deposit, allow approximately 13 minutes for the protocol to verify details and queue your validators for activation (the activation time itself will depend on the number of validators awaiting activation in the network)
5. Use the Get User Validator and Provision ID API to check your validators’ status at any point in this process.

Refer to the sequence diagram below for a detailed guide on batch contract staking:

<figure><img src="/files/QZSYXmTFeJcRpAyWhe0z" alt=""><figcaption></figcaption></figure>

### **Staking ETH without the Batch Contract**

Clients can stake their ETH without using the batch contract and directly interacting with the Beacon deposit contract

Use [Luganodes’ Node Provisioning APIs](/apis/ethereum/node-provisioning-apis.md) to stake ETH. The steps are as follows:

1. Sign up using the [Signup API](/apis/ethereum/authentication.md#sign-up) with your organisation details to receive your API key.
2. Initiate the provision of nodes by calling the [Provision Request API](/apis/ethereum/node-provisioning-apis.md#provision-request) with `batch` parameter as `false`. The API triggers the creation of nodes by Luganodes in the background. Allow some time (\~4 mins for 100 validators) to create the deposit details required for transaction signing before calling the next API.
3. Retrieve unsigned transaction objects, specifically `depositInput` in the `result` array by calling the [Get Validator Objects API](/apis/ethereum/node-provisioning-apis.md#get-validator-objects). Use `depositInput` as transaction data to execute the deposit transaction on the Beacon deposit contract mentioned below. Each transaction should be made individually based on the number of validators being set up (e.g., Setting up 100 validators would require 100 transactions to be signed).

<table data-header-hidden><thead><tr><th width="336"></th><th>Chain</th></tr></thead><tbody><tr><td>Beacon Deposit Contract (Mainnet)</td><td>0x00000000219ab540356cBB839Cbe05303d7705Fa</td></tr><tr><td>Beacon Deposit Contract (Hoodi)</td><td>0x00000000219ab540356cBB839Cbe05303d7705Fa</td></tr></tbody></table>

4. Post deposit, allow approximately 13 minutes for the protocol to verify details and queue your validators for activation (the activation time will depend on the number of validators awaiting activation in the network).
5. Use the Get  Validator and Provision ID API to check your validators’ status at any point in this process.

Refer to the sequence diagram below for a detailed guide on non-batched contract staking:

<figure><img src="/files/ayrp3m4F5nbFtkTyaE7x" alt=""><figcaption></figcaption></figure>

### [Staking without batch contract (using raw deposit data)](#staking-eth-using-raw-deposit-data)&#x20;

Users can get the raw deposit data using the Get Deposit Details API. They can use this data to initiate a deposit transaction on the Beacon deposit contract. The steps are as follows

1. Sign up using the [Signup API](/apis/ethereum/authentication.md#sign-up) with your organisation details to receive your API key.
2. Initiate the provision of nodes by calling the [Provision Request API](/apis/ethereum/node-provisioning-apis.md#provision-request) with `batch=false` (batch will have to be false here as deposit data will have to be shared separately for individual validators). The API triggers the creation of nodes by Luganodes in the background. Allow some time (\~4 mins for 100 validators) for the creation of deposit details required for transaction signing before calling the next API
3. Call the Deposit Details API to generate the raw deposit data which would include the following: `signature`, `deposit message root`, `deposit data root`, `fork version`. These would be essential to generate the input required for the deposit transaction.&#x20;
4. Post deposit, allow approximately 15-24 hours for the protocol to verify details and queue your validators for activation (the activation time itself will depend on the number of validators awaiting activation in the network)
5. Use the Get Validator and Provision ID API to check your validators’ status at any point in this process.

### **Consolidation and Switching**

Pectra EIP 7251 enables consolidation of stake of multiple validators into a single validator. This operation requires the client to sign an unsigned transaction with the validator withdrawal address and can be performed one validator at a time. Similarly, converting 0x01 withdrawal credentials to 0x02 credentials requires an unsigned transaction to be signed with the withdrawal address.&#x20;

Check out the [Consolidate API](/apis/ethereum/consolidation-and-switch.md#consolidation-request) and [Switch API](/apis/ethereum/consolidation-and-switch.md#switch-request), below are the contract addresses listed.

<table data-header-hidden><thead><tr><th width="336"></th><th>Chain</th></tr></thead><tbody><tr><td>Consolidation Contract (Mainnet)</td><td>To be added</td></tr><tr><td>Consolidation Contract (Hoodi)</td><td>0x0000bbddc7ce488642fb579f8b00f3a590007251v<br><br>NOTE: An audited version of the contract will be available soon</td></tr></tbody></table>

### **Exiting an Ethereum Validator**

You can choose to perform exits by declaring an intent to exit or by performing the exit with your validator withdrawal address.  You can perform partial withdrawals via the execution layer by signing and broadcasting an unsigned transaction.

### Via Intent

1. A signed challenge must be created that contains the validators' information signed by the withdrawal key or the controller key. The script to generate this signed challenge can be found here.
2. Call the Exit API with a signed challenge to initiate the validator exit. Refer to the [Exit API documentation](/apis/ethereum/exits.md).
3. After exiting, use the Get Validator and Provision ID API to check the status of your validators.

### Via Withdrawal Address

1. Partial withdrawals are triggered via the execution layer through the validators withdrawal address. This withdrawal is only possible for validators with 0x02 type withdrawal credentials.
2. Call the Partial Exit API to receive an unsigned transaction which needs to be signed with your validator withdrawal address and broadcasted to the network. Refer to the [Partial Exit API documentation.](/apis/ethereum/exits.md#partial-exit-request)

<table data-header-hidden><thead><tr><th width="336"></th><th>Chain</th></tr></thead><tbody><tr><td>EL Exit Contract (Mainnet)</td><td>To be added</td></tr><tr><td>EL Exit Contract (Hoodi)</td><td>0x00000961ef480eb55e80d19ad83579a64c007002<br><br>NOTE: An audited version of the contract will be available soon</td></tr></tbody></table>

2. After exiting, use the Get Validator and Provision ID API to check the status of your validators


---

# Agent Instructions: 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:

```
GET https://docs.luganodes.com/apis/ethereum/staking-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
