Skip to content
Merged
Show file tree
Hide file tree
Changes from all 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
50 changes: 50 additions & 0 deletions apis/builder/beacon_blocks.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
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.

After receiving 202, the proposer takes no further action on the block; the
builder is responsible for publishing the execution payload envelope.

This API is applicable from Gloas fork onwards.
tags:
- Builder
parameters:
- in: header
schema:
$ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
required: true
name: Eth-Consensus-Version
description: "The active consensus version to which the block being submitted belongs."
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":

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 proposer expected to do after 202? Wait for gossip envelope? Publish itself? Assume the block will be published?

Is the recommendation on what the proposer should do best after getting the 202 documented somewhere?

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.

Its the builders responsibility to publish the envelope in ePBS. The proposer has no way to build the envelope since the payload is with the builder. The proposer has actually nothing to do post this as the publishing of envelope is completely on the builder.
The proposer can listen to the PTC votes to see if it was revealed in a timely fashion or not.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Thanks, makes sense. Could the spec itself capture this? Something along the lines of:

After receiving 202, the proposer takes no further action on the block; the builder publishes the envelope. The proposer MAY observe PTC votes to monitor timely reveal.

Currently, it makes sense for builder-API clients to race relays for unblinding; therefore, this new clear responsibility switch is a significant control-flow change for any current builder-API client worth highlighting if we prefer being explicit.

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"
86 changes: 86 additions & 0 deletions apis/builder/builder_preferences.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
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.proposer_lookahead`, so that
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.data`
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: true
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"
examples:
BuilderPreferencesRequestV1:
$ref: "../../builder-oapi.yaml#/components/examples/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.data 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"
171 changes: 171 additions & 0 deletions apis/builder/execution_payload_bid.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,171 @@
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 or SSZ.

The proposer's `max_execution_payment` is communicated exclusively via the
`submitBuilderPreferences` endpoint. If no `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.
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: true
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
`data` 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."
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.data 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"
24 changes: 22 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_blocks:
$ref: "./apis/builder/beacon_blocks.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,9 @@ 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"
Gloas.BuilderPreferencesV1:
$ref: "./examples/gloas/builder_preferences.json"
Gloas.BuilderPreferencesRequestV1:
$ref: "./examples/gloas/builder_preferences_request.json"
5 changes: 5 additions & 0 deletions examples/gloas/builder_preferences.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
{
"value": {
"max_execution_payment": "1000000000"
}
}
Binary file added examples/gloas/builder_preferences.ssz
Binary file not shown.
14 changes: 14 additions & 0 deletions examples/gloas/builder_preferences_request.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
{
"value": {
"preferences": {
"max_execution_payment": "1000000000"
},
"auth": {
"message": {
"data": "0x68747470733a2f2f6275696c6465722e6578616d706c652e636f6d",
"slot": "1"
},
"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
}
}
}
Binary file added examples/gloas/builder_preferences_request.ssz
Binary file not shown.
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": {
"data": "0x68747470733a2f2f6275696c6465722e6578616d706c652e636f6d",
"slot": "1"
},
"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
}
}
Binary file added examples/gloas/signed_request_auth.ssz
Binary file not shown.
Loading
Loading