Skip to content
Merged
Show file tree
Hide file tree
Changes from 51 commits
Commits
Show all changes
58 commits
Select commit Hold shift + click to select a range
74b53c1
initial builder-api for gloas
bharath-123 Dec 17, 2025
0c55646
updates
bharath-123 Dec 12, 2025
278df30
pass in params while querying execution payload bid
bharath-123 Dec 12, 2025
1577ba9
introduce validator registrations v2
bharath-123 Dec 16, 2025
a3db7f7
run doctoc
bharath-123 Dec 17, 2025
df52176
update validator registration v2
bharath-123 Dec 17, 2025
6e1a777
add more specs
bharath-123 Dec 17, 2025
80974bc
run lint
bharath-123 Dec 17, 2025
a242d3b
updates
bharath-123 Dec 17, 2025
4ab5a0f
abstract execution_payment_accepted to a BuilderPreferences struct
bharath-123 Dec 18, 2025
9901fdc
minor fixes
bharath-123 Dec 18, 2025
6959fda
run doctoc
bharath-123 Dec 18, 2025
e752694
use correct method to check if builder is active
bharath-123 Dec 19, 2025
d5773ac
save
bharath-123 Dec 23, 2025
68c1f21
updates
bharath-123 Dec 23, 2025
373493a
add information for bidding
bharath-123 Dec 23, 2025
b0d9542
update
bharath-123 Dec 23, 2025
77be521
add bid request auth
bharath-123 Jan 6, 2026
56a5ec9
remove builder index from validator registration
bharath-123 Jan 6, 2026
dd644e5
add validator registration type
bharath-123 Jan 6, 2026
80dbeb0
link to api calls
bharath-123 Jan 7, 2026
3a9640a
add some notes
bharath-123 Jan 7, 2026
8962cc3
fix return type of execution_payload_bid.yaml
bharath-123 Jan 7, 2026
2cdc29c
use max_trusted_bid in builder preferences
bharath-123 Jan 7, 2026
5ab4d6d
run linter
bharath-123 Jan 8, 2026
f4a9e04
fix spellchecker
bharath-123 Jan 8, 2026
35fb5a7
update bid request auth according to feedback
bharath-123 Jan 8, 2026
e33dfed
minor updates
bharath-123 Jan 8, 2026
8aaa3b5
use a salt in the bid request auth
bharath-123 Jan 9, 2026
3625f54
correctly render constants table
bharath-123 Jan 9, 2026
66c15dc
address feedback
bharath-123 Jan 9, 2026
31dc1d4
update bid request auth to request auth
bharath-123 Jan 14, 2026
0644e07
fix typo
bharath-123 Jan 20, 2026
b02106f
use salt instead of url
bharath-123 Jan 23, 2026
dbce4d6
use get-upcoming-proposal-slots
bharath-123 Jan 27, 2026
b0e3d0c
Update liveness failsafe section
bharath-123 Feb 6, 2026
e7d4321
update RequestAuth types
bharath-123 Feb 6, 2026
37c8e87
deprecate validator registrations in favour of proposer preferences
bharath-123 Mar 9, 2026
3b5735b
updates to api
bharath-123 Mar 12, 2026
19c272f
run lint
bharath-123 Mar 12, 2026
18ca2ed
remove description of proposer preferences
bharath-123 Mar 16, 2026
c1f2af3
add validator pubkey in builder preferences and request auth
bharath-123 Mar 30, 2026
48c6ad8
specify setting fee reicpient in execution payload bid
bharath-123 Apr 25, 2026
3d53d8d
updates to epbs
bharath-123 Apr 30, 2026
d125dea
updates
bharath-123 May 8, 2026
5a618ae
minor updates
bharath-123 May 8, 2026
6429ef9
address feedback
bharath-123 May 8, 2026
9d4a18d
minor updates
bharath-123 May 11, 2026
fbc4747
add an error type for missing auth request
bharath-123 May 12, 2026
7bd4ea1
Endpoint to submit builder preferences (#160)
bharath-123 May 22, 2026
75ea726
Gloas Builder-API spec updates (#161)
bharath-123 Jun 1, 2026
8a51c81
address justins + AntiD2ta feedback
bharath-123 Jun 2, 2026
9ec931e
make the request auth more generic
bharath-123 Jun 8, 2026
1e26b71
rename MAX_URL_BYTES to MAX_DATA_BYTES
bharath-123 Jun 8, 2026
8bf1bee
remove unecessary specification
bharath-123 Jun 9, 2026
1ac301a
update spec to use auth.data instead of auth.builder_url
bharath-123 Jun 9, 2026
b573714
address feedback and add examples
bharath-123 Jun 11, 2026
cd89786
add ssz examples
bharath-123 Jun 11, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions apis/builder/beacon_block.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
post:
operationId: "submitSignedBeaconBlock"
summary: Submit a signed beacon block with the execution payload bid.
description: |
Submits a `SignedBeaconBlock` to the builder, binding the proposer to the block.

A success response (202) indicates that the signed beacon block was
valid. If the signed beacon block was invalid, then the builder
must return an error response (400) with a description of the validation
failure.

This API is applicable from Gloas fork onwards.
tags:
- Builder
parameters:
- in: header
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
required: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should make this required, or how exactly do you determine the consensus type otherwise?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes agreed, i was not sure if we should make it required because we don't do it in the previous apis. But I see no harm in making it required. A builder can use the header when they need to.

name: Eth-Consensus-Version
description: "The active consensus version to which the block being submitted belongs. Required if request is SSZ encoded."
requestBody:
description: A `SignedBeaconBlock`.
required: true
content:
application/json:
schema:
$ref: "../../beacon-apis/types/gloas/block.yaml#/Gloas/SignedBeaconBlock"
application/octet-stream:
schema:
description: "SSZ serialized `SignedBeaconBlock` bytes. Use content type header to indicate that SSZ data is contained in the request body."
responses:
"202":
description: Success response.
"400":
description: Error response.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
example:
code: 400
message: "Invalid signed beacon block: missing signature"
"415":
$ref: "../../builder-oapi.yaml#/components/responses/UnsupportedMediaType"
"500":
$ref: "../../builder-oapi.yaml#/components/responses/InternalError"
83 changes: 83 additions & 0 deletions apis/builder/builder_preferences.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
post:
operationId: "submitBuilderPreferences"
summary: Submit builder preferences for a proposer.
description: |
Submits a proposer's `BuilderPreferencesRequestV1` to the builder, including
the `max_execution_payment` that the proposer is willing to accept from this
builder, authenticated via a `SignedRequestAuthV1`.

Validators MAY call this endpoint in the epoch prior to the epoch in
which they will be proposing, as determined from `state.lookahead`, so that

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be state.proposer_lookahead

builders have the preferences before the bid request arrives.

The builder MUST verify the BLS signature in `auth` against
`validator_pubkey`, and check that `auth.message.builder_url`
matches its own URL. If the signature check fails, the builder MUST
return a 401 response. If the URL or slot check fails, the builder MUST
return a 400 response.

A success response (202) indicates that the preferences were accepted. If
the preferences are invalid, then the builder MUST return an error response
(400) with a description of the validation failure.

This API is applicable from Gloas fork onwards.
tags:
- Builder
parameters:
- name: validator_pubkey
in: path
required: true
description: "The BLS public key of the validator expressing these preferences."
schema:
$ref: "../../beacon-apis/types/primitive.yaml#/Pubkey"
- name: Eth-Consensus-Version
in: header
required: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, we should make this header required

description: "The active consensus version to which the request body belongs. Required if the request body is SSZ encoded."
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
requestBody:
description: A `BuilderPreferencesRequestV1` containing the proposer's preferences and a `SignedRequestAuthV1` for authentication.
required: true
content:
application/json:
schema:
$ref: "../../types/gloas/builder_preferences.yaml#/Gloas/BuilderPreferencesRequestV1"
application/octet-stream:
schema:
description: "SSZ serialized `BuilderPreferencesRequestV1` bytes. Use content type header to indicate that SSZ data is contained in the request body."
responses:
"202":
description: Success response.
"400":
description: Error response.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
examples:
SlotMismatch:
value:
code: 400
message: "Invalid SignedRequestAuthV1: auth.message.slot does not match the requested slot"
WrongBuilder:
value:
code: 400
message: "auth.message.builder_url does not match this builder's URL"
InvalidPreferences:
value:
code: 400
message: "Invalid builder preferences: max_execution_payment malformed"
"401":
description: Authentication required.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
examples:
SignatureVerificationFailed:
value:
code: 401
message: "Invalid SignedRequestAuthV1: signature verification failed"
"500":
$ref: "../../builder-oapi.yaml#/components/responses/InternalError"
177 changes: 177 additions & 0 deletions apis/builder/execution_payload_bid.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,177 @@
post:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the reason of using POST for a get operation? if POST request is required, what is the reason for putting those 4 params in the path segments, rather than in request body?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used a post cause we are sending the request auth in the body. I put the params in the path segments cause it was what we are doing previously. Let me think more on whether we should put the params in path segments or request body. This point was raised by a builder too

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just pass the signature in the request header? because builder must know its own pubkey and slot is already passed in the path segments, so builder can construct the message, and verify with the signature in the header

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If in the future, we update the request auth the builder would probably need to try multiple structs to verify the signature. Just sending the full body with the signature seems much easier to me to avoid this issue?

operationId: "getExecutionPayloadBid"
summary: Get an execution payload bid.
description: |
Requests a builder node to produce a valid execution payload bid, which
can be integrated into a beacon block and signed.

The proposer sends a POST request to the builder with the following information:
- The slot for which the block should be proposed.
- The hash of the execution layer block the proposer will build on.
- The root of the beacon block the proposer will build on.
- The index of the proposer.
- Optionally, a `SignedRequestAuthV1` in the request body that
authenticates the request. The body MAY be encoded as JSON
(`Content-Type: application/json`) or SSZ
(`Content-Type: application/octet-stream`).

@nflaig nflaig Jun 10, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it shouldn't be necessary to denote the content-type header here again, it is already in the schema

and we have this general note on the spec

Image


The proposer's `max_execution_payment` is communicated exclusively via the
[`submitBuilderPreferences`][submit-builder-preferences-api] endpoint. If no

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[submit-builder-preferences-api] is this a placeholder?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't have added it here. Removing it!

`BuilderPreferencesV1` have been submitted for the proposer, the builder MUST
treat `max_execution_payment` as `0` and MUST NOT include an execution layer
payment in the bid.

The `SignedRequestAuthV1` body is optional. If it is present but malformed
or fails signature verification, the builder MAY return a 401 response.
If it is absent, the builder MAY still serve a bid, but builders MAY
use the presence and validity of the `SignedRequestAuthV1` to apply
per-validator policy (e.g. rate-limiting, prioritization, or refusing
unauthenticated requests).

The builder responds with a 200 response containing an execution payload bid if it can provide one.

If the builder is unable to produce a valid execution payload bid, then
the builder MUST return a 204 response. If the request is invalid, then the
builder MUST return an error response (400) with a description of the
validation failure.

This API is applicable from Gloas fork onwards.
tags:
- Builder
parameters:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the existing api the query params make sense as it's a GET, but this new one is a POST with a mix of query params, a body, and headers that contain application data rather than just meta data.

Shouldn't it all just be in the body if it's a POST?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I am unopinianated on this. We can discuss this again.

- name: slot
in: path
required: true
description: The slot for which the block should be proposed.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Uint64"
- name: parent_hash
in: path
required: true
description: Hash of execution layer block the proposer will build on.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Root"
- name: parent_root
in: path
required: true
description: Root of the beacon block the proposer will build on.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/Root"
- name: proposer_pubkey
in: path
required: true
description: BLS public key of the proposer.
schema:
$ref: "../../beacon-apis/types/primitive.yaml#/Pubkey"
- name: Date-Milliseconds
in: header
required: false
description: |
Optional header containing a Unix timestamp in milliseconds representing
the point-in-time the request was sent. This header can be used to measure
latency.
schema:
type: integer
format: int64
example: 1710338135000
- name: X-Timeout-Ms

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if clients agreed NOT to make this configurable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage in not making it configurable? Would it be incentive compatible?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We ideally don't want people to be able to abuse the X-Timeout-Ms to play timing games and risk orphaning out blocks. As blob counts become higher with upcoming BPOs, timing games can degrade attestation performance.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

refer to https://ethpandaops.io/posts/fusaka-more-blobs-less-votes/ for an analysis on the relation between timing games and attestation performance degradation as blob count increases with BPOs.

@ltitanb ltitanb Jan 16, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my view the tradeoff is that if something is not incentive compatible for the proposer the outcome is just that a subset of "sophisticated" proposers will fork clients, which is undesirable

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it was configurable there'd want to be strict sanity limits imo, but i think it really does open up some degenerate behaviour to have it available potentially... Probably just not having it settable is the better option than the guards it'd need...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it was configurable there'd want to be strict sanity limits imo, but i think it really does open up some degenerate behaviour to have it available potentially... Probably just not having it settable is the better option than the guards it'd need...

Tend to agree with this.

in: header
required: false
description: |
Optional header containing the proposer's timeout for the request in milliseconds.
Builders should use this header to adjust the amount of time by which they delay the
requests to maximise block rewards. Otherwise, requests will timeout and the proposer

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this even specified?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was something added to MEV-Boost by Obol here: flashbots/mev-boost#817 , it made sense to specify it in the builder-spec.

We specify it today too: https://github.com/ethereum/builder-specs/blob/main/apis/builder/header.yaml#L46

This is also a completely optional header which clients don't have to send.

will not receive the header in time.
schema:
type: integer
format: int64
example: 10000
Comment on lines +80 to +82

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

int64 would need to be a string format because of limitations over 54? bits in javascirpt iirc.. @nflaig knows better than me on this though... its the reason most of beacon-api numbers being contained in string anyway...
Not sure if that's a problem here specifically, but figured its worth talking about

@bharath-123 bharath-123 Jun 9, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The header is sent as ASCII bytes over the wire anyways. I think specifying it as int64 here is good to clarify the type of the header value for the servers parsing the header.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is already part of current getHeader

- name: X-Timeout-Ms
in: header
required: false
description: |
Optional header containing the proposer's timeout for the request in milliseconds.
Relays should use this header to adjust the amount of time by which they delay getHeader
requests to maximise block rewards. Otherwise, getHeader requests will timeout and the proposer
will not receive the header in time.
schema:
type: integer
format: int64
example: 10000

I don't think it matters as @bharath-123 already noted as this is not transmitted via json

- name: Eth-Consensus-Version
in: header
required: false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this header not required? if we change SignedRequestAuth in the future it has to be present

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noted this before, I think this header should be required

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah clients should it send it regardless of SSZ or JSON encoding, it seems useful to have in general

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes please 🙏

description: |
The active consensus version to which the `SignedRequestAuthV1` in the
request body belongs. Required if the request body is SSZ encoded.
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
requestBody:
description: |
Optional `SignedRequestAuthV1` authenticating the request. If provided,
the builder MAY verify the BLS signature against the validator pubkey
resolved from the `proposer_pubkey` path parameter, and check that
`builder_url` matches its own URL and that `slot` matches the
requested slot. If absent, the builder MAY still serve a bid subject
to its own policy.
required: false
content:
application/json:
schema:
$ref: "../../types/gloas/request_auth.yaml#/Gloas/SignedRequestAuthV1"
application/octet-stream:
schema:
description: "SSZ serialized `SignedRequestAuthV1` bytes. Use Content-Type header to indicate that SSZ data is contained in the request body. The `Eth-Consensus-Version` header MUST also be set."

@nflaig nflaig Jun 10, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: "SSZ serialized `SignedRequestAuthV1` bytes. Use Content-Type header to indicate that SSZ data is contained in the request body. The `Eth-Consensus-Version` header MUST also be set."
description: "SSZ serialized `SignedRequestAuthV1` bytes. Use Content-Type header to indicate that SSZ data is contained in the request body."

we should always sent the version header

@nflaig nflaig Jun 10, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did anyone ssz encode a SignedRequestAuthV1 already and made sure it can be decoded by the receiver? I might be wrong, but arbitrary strings like urls seem problematic

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a unit test in buildoor on a sort of round trip with request auth here: https://github.com/ethpandaops/buildoor/pull/81/changes#diff-9e15279d13b1890a9f040f159e5d3431a84f9a3406480a4e304b1bd8d75b55e3R58
We basically marshall it into SSZ, unmarshal it, get its hash tree root, sign it and verify the signature

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very similar to extra data: https://github.com/ethereum/consensus-specs/blob/6ebb2216ca8d7fdac7c108fcfddb74d0e56c42ab/specs/bellatrix/beacon-chain.md#L174
which is also a ByteList[MAX_DATA_BYTES] and can be any arbitrary string.

@nflaig nflaig Jun 11, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we are fine with data being hex encoded in the json and not human readable, then this works. worth pointing out that depending on what character encoding you use to convert an arbitrary string to bytes it may produce different results, but I am assuming everyone is using utf-8 and for urls, this is mostly irrelevant even with other encodings like ascii

responses:
"200":
description: Success response.
headers:
Eth-Consensus-Version:
$ref: "../../builder-oapi.yaml#/components/headers/Eth-Consensus-Version"
required: true
content:
application/json:
schema:
title: GetExecutionPayloadBidResponse
type: object
required: [version, data]
properties:
version:
type: string
enum: [ gloas ]
example: "gloas"
data:
$ref: "../../beacon-apis/types/gloas/execution_payload_bid.yaml#/Gloas/SignedExecutionPayloadBid"
application/octet-stream:
schema:
description: "SSZ serialized `SignedExecutionPayloadBid` bytes. Use Accept header to choose this response type"
"204":
description: No bid is available.
"400":
description: Error response.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
examples:
InvalidHash:
value:
code: 400
message: "Unknown hash: missing parent hash"
SlotMismatch:
value:
code: 400
message: "Invalid SignedRequestAuthV1: auth.message.slot does not match the requested slot"
WrongBuilder:
value:
code: 400
message: "Invalid SignedRequestAuthV1: auth.message.builder_url does not match this builder's URL"
"401":
description: Authentication required.
content:
application/json:
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ErrorMessage"
examples:
MissingAuth:
value:
code: 401
message: "Missing SignedRequestAuthV1: this builder requires authenticated requests"
InvalidAuth:
value:
code: 401
message: "Invalid SignedRequestAuthV1: signature verification failed"
"406":
$ref: "../../builder-oapi.yaml#/components/responses/NotAcceptable"
"415":
$ref: "../../builder-oapi.yaml#/components/responses/UnsupportedMediaType"
"500":
$ref: "../../builder-oapi.yaml#/components/responses/InternalError"
20 changes: 18 additions & 2 deletions builder-oapi.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -53,10 +53,16 @@ paths:
$ref: "./apis/builder/validators.yaml"
/eth/v1/builder/header/{slot}/{parent_hash}/{pubkey}:
$ref: "./apis/builder/header.yaml"
/eth/v1/builder/execution_payload_bid/{slot}/{parent_hash}/{parent_root}/{proposer_pubkey}:
$ref: "./apis/builder/execution_payload_bid.yaml"
/eth/v1/builder/beacon_block:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty sure plural is more correct here, see previous /eth/v2/builder/blinded_blocks

Suggested change
/eth/v1/builder/beacon_block:
/eth/v1/builder/beacon_blocks:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not too opinionated, we only send back 1 beacon block hahaha. But I am fine with this change

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but this is common REST naming convention, we also call it /eth/v2/beacon/blocks on the beacon-api

$ref: "./apis/builder/beacon_block.yaml"
/eth/v1/builder/blinded_blocks:
$ref: "./apis/builder/blinded_blocks.yaml"
/eth/v2/builder/blinded_blocks:
$ref: "./apis/builder/blinded_blocks_v2.yaml"
/eth/v1/builder/builder_preferences/{validator_pubkey}:
$ref: "./apis/builder/builder_preferences.yaml"
/eth/v1/builder/status:
$ref: "./apis/builder/status.yaml"

Expand All @@ -72,7 +78,7 @@ components:
$ref: "./beacon-apis/types/http.yaml#/ErrorMessage"
ConsensusVersion:
$ref: "./beacon-apis/beacon-node-oapi.yaml#/components/schemas/ConsensusVersion"
enum: [bellatrix, capella, deneb, electra, fulu]
enum: [bellatrix, capella, deneb, electra, fulu, gloas]
example: "bellatrix"
Bellatrix.ExecutionPayload:
$ref: "./beacon-apis/types/bellatrix/execution_payload.yaml#/Bellatrix/ExecutionPayload"
Expand Down Expand Up @@ -102,7 +108,15 @@ components:
$ref: "./types/fulu/blobs_bundle.yaml#/Fulu/BlobsBundle"
Fulu.ExecutionPayloadAndBlobsBundle:
$ref: "./types/fulu/execution_payload_and_blobs_bundle.yaml#/Fulu/ExecutionPayloadAndBlobsBundle"

Gloas.RequestAuthV1:
$ref: "./types/gloas/request_auth.yaml#/Gloas/RequestAuthV1"
Gloas.SignedRequestAuthV1:
$ref: "./types/gloas/request_auth.yaml#/Gloas/SignedRequestAuthV1"
Gloas.BuilderPreferencesV1:
$ref: "./types/gloas/builder_preferences.yaml#/Gloas/BuilderPreferencesV1"
Gloas.BuilderPreferencesRequestV1:
$ref: "./types/gloas/builder_preferences.yaml#/Gloas/BuilderPreferencesRequestV1"

responses:
InternalError:
$ref: "./types/http.yaml#/InternalError"
Expand Down Expand Up @@ -151,3 +165,5 @@ components:
$ref: "./examples/fulu/signed_blinded_beacon_block.json"
Fulu.SignedBuilderBid:
$ref: "./examples/fulu/signed_builder_bid.json"
Gloas.SignedRequestAuthV1:
$ref: "./examples/gloas/signed_request_auth.json"
9 changes: 9 additions & 0 deletions examples/gloas/signed_request_auth.json

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I will add the SSZ examples. I was considering adding them in a follow up PR.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude was able to get the ssz examples from the json correctly without any issues!

Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
{
"value": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this "value" needed? Shouldn't is just be message and signature?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to be the common pattern in writing examples in the builder-specs. To encapsulate them in value. I am not too opinionated on this honestly, we can revisit this nit later.

"message": {
"builder_url": "https://builder.example.com",
"slot": "1"
},
"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
}
}
Loading
Loading