> ## Documentation Index
> Fetch the complete documentation index at: https://docs.validationcloud.io/llms.txt
> Use this file to discover all available pages before exploring further.
# /eth/v1/validator/duties/proposer/{epoch}
> Get block proposers duties
```bash title="Mainnet" theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
curl -X GET \
"https://mainnet.ethereum.validationcloud.io/v1//eth/v1/validator/duties/proposer/1" \
-H "Content-Type: application/json"
```
```bash title="Testnet" theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
curl -X GET \
"https://sepolia.ethereum.validationcloud.io/v1//eth/v1/validator/duties/proposer/1" \
-H "Content-Type: application/json"
```
## OpenAPI
````yaml nodeapi/openapi/beacon-node-oapi-v2.json GET /eth/v1/validator/duties/proposer/{epoch}
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.
All requests by default send and receive JSON, and as such should have
either or both of the "Content-Type: application/json"
and "Accept: application/json" headers. In addition, some requests can
return data in the SSZ format. To indicate that SSZ
data is required in response to a request the header "Accept:
application/octet-stream" should be sent. Note that only a subset
of requests can respond with data in SSZ format; these are noted in each
individual request.
API endpoints are individually versioned. As such, there is no direct
relationship between all v1 endpoints, all v2 endpoints,
_etc._ and no such relationship should be inferred. All JSON responses
return the requested data under a `data` key in the top
level of their response. Additional metadata may or may not be present in
other keys at the top level of the response, dependent
on the endpoint. The rules that require an increase in version number are
as follows:
- no field that is listed in an endpoint shall be removed without an increase in the version number
- 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
increase in the version number
Note that it is possible for a field to be added to an endpoint's data or
metadata without an increase in the version number.
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: https://mainnet.ethereum.validationcloud.io/v1//
description: Mainnet Beacon API
- url: https://sepolia.ethereum.validationcloud.io/v1//
description: Sepolia Beacon API
security: []
tags:
- name: Beacon
description: Set of endpoints to query beacon chain.
- name: Config
description: Endpoints to query chain configuration, specification, and fork schedules.
- name: Debug
description: Set of endpoints to debug chain and shouldn't be exposed publicly.
- name: Events
description: Set of endpoints to for event subscription.
- name: Node
description: Endpoints to query node related informations
- name: Validator
description: Endpoints intended for validator clients
- name: ValidatorRequiredApi
description: >
Minimal set of endpoints to enable a working validator implementation.
[Checkout validator
flow](https://github.com/ethereum/beacon-APIs/blob/master/validator-flow.md)
to learn how to use this api.
paths:
/eth/v1/validator/duties/proposer/{epoch}:
get:
tags:
- ValidatorRequiredApi
- Validator
summary: Get block proposers duties
description: >-
Request beacon node to provide all validators that are scheduled to
propose a block in the given epoch.
Duties should only need to be checked once per epoch, however a chain
reorganization could occur that results in a change of duties. For full
safety, you should monitor head events and confirm the dependent root in
this response matches:
- event.current_duty_dependent_root when
`compute_epoch_at_slot(event.slot) == epoch`
- event.block otherwise
The dependent_root value is `get_block_root_at_slot(state,
compute_start_slot_at_epoch(epoch) - 1)` or the genesis block root in
the case of underflow.
operationId: getProposerDuties
parameters:
- name: epoch
in: path
required: true
schema:
type: string
example: '1'
responses:
'200':
description: Success response
content:
application/json:
schema:
title: GetProposerDutiesResponse
type: object
properties:
dependent_root:
allOf:
- type: string
example: >-
0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2
pattern: ^0x[a-fA-F0-9]{64}$
- description: The block root that this response is dependent on.
execution_optimistic:
allOf:
- type: boolean
- example: false
- description: >-
True if the response references an unverified
execution payload. Optimistic information may be
invalidated at a later time. If the field is not
present, assume the False value.
data:
type: array
items:
type: object
properties:
pubkey:
type: string
pattern: ^0x[a-fA-F0-9]{96}$
description: >-
The validator's BLS public key, uniquely identifying
them. _48-bytes, hex encoded with 0x prefix, case
insensitive._
example: >-
0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a
validator_index:
allOf:
- type: string
example: '1'
- description: Index of validator in validator registry.
slot:
allOf:
- type: string
example: '1'
- description: >-
The slot at which the validator must propose
block.
'400':
description: Invalid epoch
content:
application/json:
schema:
allOf:
- 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: 400
message: 'Invalid epoch: -2'
'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
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.