--- updatedAt: 2025-09-18T22:06:54.000Z agentTools: projectIndex: https://docs.nodereal.io/llms.txt --- # Signal beacon node to prepare for a committee subnet After beacon node receives this request, search using discv5 for peers related to this subnet and replace current peers with those ones if necessary If validator `is_aggregator`, beacon node must: - announce subnet topic subscription on gossipsub - aggregate attestations received on that subnet # 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/beacon_committee_subscriptions": { "post": { "operationId": "prepareBeaconCommitteeSubnet", "summary": "Signal beacon node to prepare for a committee subnet", "description": "After beacon node receives this request,\nsearch using discv5 for peers related to this subnet\nand replace current peers with those ones if necessary\nIf validator `is_aggregator`, beacon node must:\n- announce subnet topic subscription on gossipsub\n- aggregate attestations received on that subnet\n", "tags": [ "ValidatorRequiredApi", "Validator" ], "requestBody": { "content": { "application/json": { "schema": { "title": "SubscribeToBeaconCommitteeSubnetRequestBody", "type": "array", "items": { "type": "object", "properties": { "validator_index": { "type": "string", "example": "1" }, "committee_index": { "type": "string", "example": "1" }, "committees_at_slot": { "allOf": [ { "type": "string", "example": "1" }, { "description": "Number of committees at the returned slot" } ] }, "slot": { "allOf": [ { "type": "string", "example": "1" }, { "description": "Should be slot at which validator is assigned to attest" } ] }, "is_aggregator": { "type": "boolean", "description": "Signals to BN that a validator on the VC has been chosen for aggregator role." } } } } } } }, "responses": { "200": { "description": "Slot signature is valid and beacon node has prepared the attestation subnet.\n\nNote that we cannot be certain the Beacon node will find peers for that subnet for various reasons.\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" } } } }, "503": { "description": "Beacon node is currently syncing, try again later.", "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": 503, "message": "Beacon node is currently syncing and not serving request on that endpoint" } } } } } } } }, "x-readme": { "explorer-enabled": true, "proxy-enabled": true } } ```