---
updatedAt: 2025-09-18T22:06:56.000Z
agentTools:
  projectIndex: https://docs.nodereal.io/llms.txt
---

# Provide beacon node with proposals for the given validators.

Prepares the beacon node for potential proposers by supplying information
required when proposing blocks for the given validators.  The information
supplied for each validator index will persist through the epoch in which
the call is submitted and for a further two epochs after that, or until the
beacon node restarts.  It is expected that validator clients will send this
information periodically, for example each epoch, to ensure beacon nodes have
correct and timely fee recipient information.

Note that there is no guarantee that the beacon node will use the supplied fee
recipient when creating a block proposal, so on receipt of a proposed block the
validator should confirm that it finds the fee recipient within the block
acceptable before signing it.

Also note that requests containing currently inactive or unknown validator
indices will be accepted, as they may become active at a later epoch.

# OpenAPI definition

```json
{
  "openapi": "3.0.3",
  "info": {
    "title": "Eth Beacon Node API",
    "description": "API specification for the beacon node, which enables users to query and participate in Ethereum 2.0 phase 0 beacon chain.\n\nAll requests by default send and receive JSON, and as such should have either or both of the \"Content-Type: application/json\"\nand \"Accept: application/json\" headers.  In addition, some requests can return data in the SSZ format.  To indicate that SSZ\ndata is required in response to a request the header \"Accept: application/octet-stream\" should be sent.  Note that only a subset\nof requests can respond with data in SSZ format; these are noted in each individual request.\n\nAPI endpoints are individually versioned.  As such, there is no direct relationship between all v1 endpoints, all v2 endpoints,\n_etc._ and no such relationship should be inferred.  All JSON responses return the requested data under a `data` key in the top\nlevel of their response.  Additional metadata may or may not be present in other keys at the top level of the response, dependent\non the endpoint.  The rules that require an increase in version number are as follows:\n\n  - no field that is listed in an endpoint shall be removed without an increase in the version number\n  - no field that is listed in an endpoint shall be altered in terms of format (_e.g._ from a string to an array) without an\n    increase in the version number\n\nNote that it is possible for a field to be added to an endpoint's data or metadata without an increase in the version number.\n",
    "version": "v2.3.0 - Eth2Spec v1.1.0",
    "contact": {
      "name": "Ethereum Github",
      "url": "https://github.com/ethereum/beacon-apis/issues"
    },
    "license": {
      "name": "CC0-1.0",
      "url": "https://creativecommons.org/publicdomain/zero/1.0/"
    }
  },
  "servers": [
    {
      "url": "{server_url}/{api_key}",
      "variables": {
        "server_url": {
          "description": "Beacon node API url",
          "default": "eth2-beacon-mainnet.nodereal.io/v1"
        },
        "api_key": {
          "description": "Beacon node API key",
          "default": "api_key"
        }
      }
    }
  ],
  "tags": [
    {
      "name": "Validator",
      "description": "Endpoints intended for validator clients"
    },
    {
      "name": "ValidatorRequiredApi",
      "description": "Minimal set of endpoints to enable a working validator implementation.\n\n[Checkout validator flow](./validator-flow.md) to learn how to use this api.\n"
    }
  ],
  "paths": {
    "/eth/v1/validator/prepare_beacon_proposer": {
      "post": {
        "operationId": "prepareBeaconProposer",
        "summary": "Provide beacon node with proposals for the given validators.",
        "description": "Prepares the beacon node for potential proposers by supplying information\nrequired when proposing blocks for the given validators.  The information\nsupplied for each validator index will persist through the epoch in which\nthe call is submitted and for a further two epochs after that, or until the\nbeacon node restarts.  It is expected that validator clients will send this\ninformation periodically, for example each epoch, to ensure beacon nodes have\ncorrect and timely fee recipient information.\n\nNote that there is no guarantee that the beacon node will use the supplied fee\nrecipient when creating a block proposal, so on receipt of a proposed block the\nvalidator should confirm that it finds the fee recipient within the block\nacceptable before signing it.\n\nAlso note that requests containing currently inactive or unknown validator\nindices will be accepted, as they may become active at a later epoch.\n",
        "tags": [
          "ValidatorRequiredApi",
          "Validator"
        ],
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "type": "array",
                "items": {
                  "type": "object",
                  "properties": {
                    "validator_index": {
                      "type": "string",
                      "example": "1"
                    },
                    "fee_recipient": {
                      "type": "string",
                      "description": "An address on the execution (Ethereum 1) network.",
                      "example": "0xabcf8e0d4e9587369b2301d0790347320302cc09",
                      "pattern": "^0x[a-fA-F0-9]{40}$"
                    }
                  }
                }
              }
            }
          }
        },
        "responses": {
          "200": {
            "description": "Preparation information has been received.\n"
          },
          "400": {
            "description": "Invalid request syntax.",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "code": {
                      "description": "Either specific error code in case of invalid request or http status code",
                      "type": "number",
                      "example": 400
                    },
                    "message": {
                      "description": "Message describing error",
                      "type": "string"
                    },
                    "stacktraces": {
                      "description": "Optional stacktraces, sent when node is in debug mode",
                      "type": "array",
                      "items": {
                        "type": "string"
                      }
                    }
                  }
                }
              }
            }
          },
          "500": {
            "description": "Beacon node internal error.",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "code": {
                      "description": "Either specific error code in case of invalid request or http status code",
                      "type": "number",
                      "example": 404
                    },
                    "message": {
                      "description": "Message describing error",
                      "type": "string"
                    },
                    "stacktraces": {
                      "description": "Optional stacktraces, sent when node is in debug mode",
                      "type": "array",
                      "items": {
                        "type": "string"
                      }
                    }
                  }
                },
                "example": {
                  "code": 500,
                  "message": "Internal server error"
                }
              }
            }
          }
        }
      }
    }
  },
  "x-readme": {
    "explorer-enabled": true,
    "proxy-enabled": true
  }
}
```