GetValidatorBlocksBySlotV3

get

https://api.zan.top/node/v1/eth/mainnet/{apiKey}/eth/v3/validator/blocks/{slot}

Produce a new block, without signature.

Requests a beacon node to produce a valid block, which can then be signed by a validator. The returned block may be blinded or unblinded, depending on the current state of the network as decided by the execution and beacon nodes.

The beacon node must return an unblinded block if it obtains the execution payload from its paired execution node. It must only return a blinded block if it obtains the execution payload header from an MEV relay.

Metadata in the response indicates the type of block produced, and the supported types of block will be added to as forks progress.

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Path Params

apiKey

string

required

Defaults to public

.custom-style { color: #048FF4; }

For higher throughput, please create your own API key.

slot

string

required

The slot for which the block should be proposed.

Query Params

randao_reveal

string

required

The validator's randao reveal value.

graffiti

string

Arbitrary data validator wants to include in block.

skip_randao_verification

string

Skip verification of the randao_reveal value. If this flag is set then the randao_reveal must be set to the point at infinity (0xc0..00). This query parameter is a flag and does not take a value.

builder_boost_factor

string

Percentage multiplier to apply to the builder's payload value when choosing between a builder payload header and payload from the paired execution node. This parameter is only relevant if the beacon node is connected to a builder, deems it safe to produce a builder payload, and receives valid responses from both the builder endpoint and the paired execution node. When these preconditions are met, the server MUST act as follows:

if exec_node_payload_value >= builder_boost_factor * (builder_payload_value // 100), then return a full (unblinded) block containing the execution node payload.
otherwise, return a blinded block containing the builder payload header.

Servers must support the following values of the boost factor which encode common preferences:

builder_boost_factor=0: prefer the execution node payload unless an error makes it unviable.
builder_boost_factor=100: default profit maximization mode; choose whichever payload pays more.
builder_boost_factor=2**64 - 1: prefer the builder payload unless an error or beacon node health check makes it unviable.

Servers should use saturating arithmetic or another technique to ensure that large values of the builder_boost_factor do not trigger overflows or errors. If this parameter is provided and the beacon node is not configured with a builder then the beacon node MUST respond with a full block, which the caller can choose to reject if it wishes. If this parameter is not provided then it should be treated as having the default value of 100. If the value is provided but out of range for a 64-bit unsigned integer, then an error response with status code 400 MUST be returned.

Headers

string

enum

Defaults to application/json

Generated from available response content types

Allowed:

Response

200Block