Staked Builder API for Glamsterdam by bharath-123 · Pull Request #138 · ethereum/builder-specs

bharath-123 · 2025-11-28T16:00:00Z

This PR begins work and discussions on the Builder-API for ePBS for staked builders.

ePBS introduces the following protocol upgrades:

Enshrining of builders into the protocol by allowing them to stake collateral (used for trustless payments).
Decoupling of BeaconBlock validation and ExecutionPayload validation.

We introduce 3 new APIs. We ideally want to have new APIs to make the transition from Fulu to Gloas easier:

getExecutionPayloadBid: POST /eth/v1/builder/execution_payload_bid/{slot}/{parent_hash}/{parent_root}/{proposer_pubkey}

Called by the proposer to the builder/relay. The builder/relay returns the best execution payload bid available to it. Per-request validator inputs are communicated as follows:
- SignedRequestAuthV1 request body (optional): authenticates the request. The body MAY be encoded as JSON (Content-Type: application/json) or SSZ (Content-Type: application/octet-stream); when SSZ is used, the Eth-Consensus-Version header MUST also be set. If the body is omitted, the builder MAY still serve a bid.
submitBuilderPreferences: POST /eth/v1/builder/builder_preferences/{validator_pubkey}

Called by the proposer in the epoch prior to the epoch in which they will be proposing. The proposer sends a BuilderPreferencesRequestV1 containing a BuilderPreferencesV1 (with max_execution_payment) and a SignedRequestAuthV1 to authenticate the request. The builder MUST check that auth.message.data matches its own URL and MUST verify the BLS signature against the validator_pubkey path parameter to ensure that the preference came from the intended proposer.
submitSignedBeaconBlock: POST /eth/v1/builder/beacon_block

Called by the proposer when it commits to the bid received from getExecutionPayloadBid. The proposer sends the SignedBeaconBlock with the execution payload bid embedded. The builder is then responsible for constructing and broadcasting the corresponding SignedExecutionPayloadEnvelope to the PTC committee.

ValidatorRegistrationV1 is deprecated in favour of ProposerPreferences from the consensus specs. General validator preferences (fee_recipient, gas_limit, etc.) are now communicated via the proposer_preferences gossip topic defined in the consensus specs. Validators broadcast SignedProposerPreferences messages at the beginning of each epoch for their proposal slots in the next epoch, and builders SHOULD subscribe to this gossip topic.

We introduce RequestAuthV1 which contains the following fields:

data: MUST be set to the URL of the builder the request is intended for.
slot: The slot for which the request is being sent.

SignedRequestAuthV1 is a container holding a RequestAuthV1 message and a BLS signature over it. The goal is to allow the proposer to authenticate to a specific builder for a given slot, preventing DDOS and replay attacks from other parties. Sending the SignedRequestAuthV1 with getExecutionPayloadBid is optional; builders MAY use it for authentication purposes.

We also introduce BuilderPreferencesV1, which carries max_execution_payment — the maximum execution layer payment (in Gwei) the proposer will accept from this builder. If no preferences have been submitted, the builder MUST treat max_execution_payment as 0 and MUST NOT include an execution layer payment in its bid.

Closes: #137

bharath-123 · 2025-12-12T09:13:09Z

Open questions:

How is the fee_recipient communicated to the builder? Do we keep ValidatorRegistrations or do we send the fee_recipient along as a header while receiving the bid. Or we can use the ProposerPreferences gossip topic as specified in: Add specs for proposer preferences consensus-specs#4777
The API currently assumes all builders are staked. do we have to also support builders who choose to not stake?

bharath-123 · 2025-12-12T10:17:24Z

Spellcheck fixes are trivial and shuoldn't block any feedback.

bharath-123 · 2025-12-15T05:42:35Z

Note: We want the response to the get the bid to be signed by the validator on the builder pub key and slot. This is so that the builder won't get spammed by other builders to reveal their bid.

bharath-123 · 2025-12-23T16:26:58Z

+def verify_registration_signature(state: BeaconState, signed_registration: SignedValidatorRegistrationV2) -> bool:
+    validator = state.validators[signed_registration.message.validator_index]
+    pubkey = validator.pubkey
+    domain = compute_domain(DOMAIN_APPLICATION_BUILDER)


Do we need to update the domain as we are introducing a new type of registration?

bharath-123 · 2025-12-23T16:37:57Z

+
+```python
+class BuilderPreferences(Container):
+    execution_payment_accepted: boolean


Can we allow validators to express arbitrary preferences here? That might be useful for proposers and builders alike. But the proposer and builders will have to agree on the scheme for preferences ahead of time. And on the other hand, hard coding preferences into BuilderPreferences will have to involve a co-ordinated rollout amongst clients.

What arbitrary preferences are we talking about here? My feeling is that we don't necessarily need that. If proposers want builders to perform arbitrary logic, they just shouldn't connect to any other builder.

bharath-123 · 2025-12-23T16:49:51Z

+    assert signed_bid.prev_randao == get_randao_mix(state, get_current_epoch(state))
+    assert is_builder(state, builder.pubkey)
+
+    if signed_bid.value > 0:


it is not necessary for a builder to use the execution_payment field to pay the bid even through the builder-api.

bharath-123 · 2025-12-23T17:34:00Z

+
+```python
+def is_eligible_for_bid(state: BeaconState,
+                        registrations: Dict[BLSPubkey, ValidatorRegistrationV2],


I guess it shouldn't be relevant to use whether registrations are a Dict from BLSPubKey -> ValidatorRegistrationV2 or ValidatorIndex -> ValidatorRegistrationV2?

bharath-123 · 2025-12-23T17:44:28Z

+      description: Root of the beacon block the proposer will build on.
+      schema:
+        $ref: "../../builder-oapi.yaml#/components/schemas/Root"
+    - name: proposer_index


should we stick with the proposer pubkey or use proposer index?

we could just stick with proposer_index. its much easier to read.

There are ideas around reusing the proposer index, whereas the proposer pubkey is more in the custody of the proposer (rather than easily changeable with a protocol change).
Thus, pubkey might be preferable if it doesn't add any complexity.

I believe we use pubkey in the existing getPayloadHeader so maybe for consistency we should stick to pubkey?

This call is in the hot path I don't see any reason to send extra bytes. The slot is signed so index reuse is irrelevant. But this is a soft take. I think getting the index is always cheaper than the pubkey at the point of the call, but I empathize with @eserilev's comment that perhaps the caller code needs to be changed less if we stick to pubkey

In favour of simplifying client implementation by sticking to pubkeys

have changed it to pubkey here: https://github.com/ethereum/builder-specs/pull/161/changes#diff-a186f4bbbe96e38c7699013ced6e58643ff9a03dddbc4fd7584c817920f5ef41R60

bharath-123 · 2026-01-06T08:46:15Z

+
+```python
+class ValidatorRegistrationV2(Container):
+    builder_index: BuilderIndex 


do we have to specify the builder_index in validator registrations? The main issue it addresses is that, it disallows malicious builders to send registrations to other builders to whom the proposer doesn't intend to fetch a block from.
This could also be a list of builder indices instead of just a builder index because a builder could have multiple corresponding indices and i don't think we will specify preferences at the builder index level.

bharath-123 · 2026-01-06T16:12:49Z

+        schema:
+          type: array
+          items:
+            $ref: "../../beacon-apis/types/gloas/bid_request_auth.yaml#/Gloas/SignedBidRequestAuth"


We send a SignedBidRequestAuth for each builder index registered by the builder. This could become large if a builder has registered multiple builder indices for themselves. But I am unsure as to why they would do that.

We could send a list of indices per endpoint. The builder only needs to check that his index is in the list. In fact this is better for the CL as well: a validator can keep the full list of builders with the same builder preferences and send one signature to all. Replaying would become a race condition but given that the timeout is relatively large, I think this may not be a problem

bharath-123 · 2026-01-06T16:14:45Z

+                enum: [ gloas ]
+                example: "gloas"
+              data:
+                type: array


We get back a bid corresponding to each builder index. The builder may not choose to return bids for all builder indices.

For e.g, The builder could choose to just return one bid from one builder index.

bharath-123 · 2026-01-06T17:20:54Z

@@ -0,0 +1,38 @@
+Gloas:


We should move these to beacon-apis repo after the builder-api has been approved.

bharath-123 · 2026-01-06T17:46:09Z

+#### `ValidatorRegistrationV2`
+
+```python
+class ValidatorRegistrationV2(Container):


We are not specifying the builder_index in the ValidatorRegistrationV2 object because the preferences should ideally be per builder url instead of per builder index. I am unsure how preferences can change based on the builder index.

bharath-123 · 2026-01-06T18:22:36Z

+
+```python
+class BidRequestAuth(Container):
+  builder_index: BuilderIndex


Do we want to specify the builder_index here? Or could we do without it? Do we want to auth per builder_index or url?

bharath-123 · 2026-01-06T18:39:47Z

+
+### New Containers
+
+#### `BidRequestAuth`


We could probably have a better name here?

Maybe ProposerAuth?

* updates * remove header to communicate max_execution_payment * use proposer_pubkey instead of index * some spec updates * update is_eligible_for_bid * update error code * don't encapsulate the beacon block under a "data" field * add an identity api * reword sentence on block and payload decoupling * update request auth to use builder url * update error codes * add eth consensus version header * suffix containers with v1 * run make lint * fix spellcheck * minor spec updates * builder can choose to not serve bid if preferences not seen

jtraglia · 2026-06-01T21:40:34Z

+def is_eligible_for_bid(
+    state: BeaconState,
+    proposer_preferences: Dict[ValidatorIndex, ProposerPreferences],
+    slot: Slot,
+    parent_hash: Hash32,
+    # [New in Gloas]
+    parent_root: Root,
+    # [New in Gloas]
+    proposer_pubkey: BLSPubkey,
+):


Not all parameter changes here are documented. Like proposer_preferences is new too.

builder-specs/specs/bellatrix/builder.md

Lines 279 to 285 in 1bf8f49

def is_eligible_for_bid(

state: BeaconState,

registrations: Dict[BLSPubkey, ValidatorRegistrationV1],

slot: Slot,

parent_hash: Hash32,

pubkey: BLSPubkey,

) -> bool:

Should document what's removed as well. In consensus-specs, we'd do:

# [Modified in Gloas:EIP7732] # Removed `registrations` # [New in Gloas:EIP7732] proposer_preferences: Dict[ValidatorIndex, ProposerPreferences], ...

jtraglia · 2026-06-01T21:41:53Z

+    # Verify that proposer preferences have been received via the gossip topic
+    assert validator_index in proposer_preferences.keys()


This is modified but not marked as such.

This would be marked with # [New in Gloas:EIP7732] cause the check with proposer preferences is pretty new.

jtraglia · 2026-06-01T21:42:39Z

+    # Verify parent root
+    # [Modified in Gloas:EIP7732]
+    assert parent_root == hash_tree_root(state.latest_block_header)


This is completely new, not modified.

jtraglia · 2026-06-01T21:45:23Z

+[`BuilderPreferencesRequestV1`](#builderpreferencesrequestv1) to each builder
+via the [`submitBuilderPreferences`][submit-builder-preferences-api] API call in
+the epoch prior to the epoch in which they will be proposing, as determined from
+`state.lookahead`. This ensures builders have the preferences before the bid


It should be state.proposer_lookahead.

jtraglia · 2026-06-01T22:12:36Z

+the builder's staked collateral on-chain even when `bid.execution_payment` is
+also set.
+
+## Constructing a `SignedExecutionPayloadEnvelope`


Not sure if you want to specify this (because I do not want to in consensus-specs) but this would be an appropriate place to talk about when a builder should reveal their payload with some certainty that it will be included onchain, within some risk tolerance.

I am unsure if there is value in specifying it. I would assume builders would be sophisticated enough to have their own strategies here. We can revisit this in the future when builders start adapting their infra and there is value in adding it here.

jtraglia · 2026-06-01T22:14:40Z

+#### `BuilderPreferencesV1`
+
+`BuilderPreferencesV1` communicates a proposer's per-builder preferences to a
+specific builder ahead of the bid request.
+
+```python
+class BuilderPreferencesV1(Container):
+    max_execution_payment: Gwei
+```


I sort of suggest simplifying this to just be PreferencesV1. Because to me it sounds like these are the builder's preferences, not the preferences for each builder. Might just be me.

Yeah the intention is that, these are the per builder preferences of the validator. I am fine with PreferencesV1 too, will check what ppl think.

jtraglia · 2026-06-01T22:25:11Z

+
+Validators MAY communicate their per-builder preferences ahead of the bid
+request by calling the
+[`submitBuilderPreferences`][submit-builder-preferences-api] API in the epoch


I might suggest calling this something like prepareExecutionPayloadBid instead. Builders would use this as a signal to start working on a bid. Right now the name doesn't make this exactly clear.

I am not sure if prepareExecutionPayloadBid is right here. Builders start working on a bid for proposers ideally every slot based on the payload attributes SSE event.
This endpoint is for validators to be able to submit their preferences. The builder would build their bid based on the latest preference they have seen for the proposer. It is not an indication to start building their bids.

rolfyone · 2026-06-08T22:10:24Z

+        type: integer
+        format: int64
+        example: 10000


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

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.

this is already part of current getHeader

builder-specs/apis/builder/header.yaml

Lines 46 to 57 in 1bf8f49

- 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

nflaig · 2026-06-10T15:44:01Z

+    builder is responsible for publishing the execution payload envelope. The proposer 
+    MAY observe PTC votes to monitor the timely reveal of the execution payload envelope.


The proposer MAY observe PTC votes to monitor the timely reveal of the execution payload envelope.

why is that note here, is there any action you are suggesting the proposer should do, or clients should implement?

Nope that can be removed, that was a old line that shouldn't be there! this was back when we were thinking about payload reorg based on PTC. But regardless this shouldn't be there.

we are doing payload reorgs based on PTC, so builders, if you read this, watch out

nflaig · 2026-06-10T15:45:45Z

+    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


this should be state.proposer_lookahead

nflaig · 2026-06-10T16:27:56Z

+    - in: header
+      schema:
+        $ref: "../../builder-oapi.yaml#/components/schemas/ConsensusVersion"
+      required: false


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

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.

nflaig · 2026-06-10T16:30:57Z

+        $ref: "../../beacon-apis/types/primitive.yaml#/Pubkey"
+    - name: Eth-Consensus-Version
+      in: header
+      required: false


same here, we should make this header required

nflaig · 2026-06-10T16:51:38Z

+      (`Content-Type: application/octet-stream`).
+
+    The proposer's `max_execution_payment` is communicated exclusively via the
+    [`submitBuilderPreferences`][submit-builder-preferences-api] endpoint. If no


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

Shouldn't have added it here. Removing it!

nflaig · 2026-06-10T16:59:47Z

+        example: 10000
+    - name: Eth-Consensus-Version
+      in: header
+      required: false


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

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

yes please 🙏

nflaig · 2026-06-10T17:00:21Z

+          $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."


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 · 2026-06-10T17:02:25Z

    $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:


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:

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

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

nflaig · 2026-06-10T17:06:17Z

usually we also have a ssz example, see https://github.com/ethereum/builder-specs/tree/main/examples/bellatrix

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

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

nflaig · 2026-06-10T17:08:22Z

+      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."


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

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

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.

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

) This PR adds the protobuf types for the Gloas builder API: request auth and builder preferences plus the `DOMAIN_REQUEST_AUTH` signature domain and the `max_execution_payment` / `request_auth` fields on the keymanager config. Definitions only ethereum/builder-specs#138

bharath-123 changed the title ~~Builder API updates for Glamsterdam~~ Off-Protocol Builder API updates for Glamsterdam Dec 3, 2025

bharath-123 changed the title ~~Off-Protocol Builder API updates for Glamsterdam~~ Builder API updates for Glamsterdam Dec 3, 2025

bharath-123 force-pushed the epbs-updates branch from 01bb9e6 to 0cf7078 Compare December 12, 2025 09:07

bharath-123 commented Dec 12, 2025

View reviewed changes

Comment thread apis/builder/execution_payload_bid.yaml Outdated

bharath-123 commented Dec 12, 2025

View reviewed changes

Comment thread apis/builder/execution_payload_bid.yaml Outdated

bharath-123 commented Dec 12, 2025

View reviewed changes

Comment thread specs/gloas/builder.md Outdated

bharath-123 changed the title ~~Builder API updates for Glamsterdam~~ Staked Builder API for Glamsterdam Dec 15, 2025

bharath-123 marked this pull request as ready for review December 16, 2025 09:58

bharath-123 commented Dec 16, 2025

View reviewed changes

Comment thread specs/gloas/builder.md Outdated

bharath-123 commented Dec 16, 2025

View reviewed changes

Comment thread specs/gloas/builder.md Outdated

bharath-123 commented Dec 16, 2025

View reviewed changes

Comment thread specs/gloas/validator.md Outdated

bharath-123 force-pushed the epbs-updates branch from 1a37a61 to 9bd69ae Compare December 17, 2025 13:49

bharath-123 commented Dec 23, 2025

View reviewed changes

bharath-123 commented Jan 6, 2026

View reviewed changes

bharath-123 force-pushed the epbs-updates branch from c31ff96 to 154b1fe Compare January 6, 2026 15:58

bharath-123 commented Jan 6, 2026

View reviewed changes

bharath-123 force-pushed the epbs-updates branch from 154b1fe to fd4266f Compare January 6, 2026 16:48

bharath-123 commented Jan 6, 2026

View reviewed changes

bharath-123 force-pushed the epbs-updates branch from 2bbb09d to 59c3194 Compare January 6, 2026 17:51

bharath-123 commented Jan 6, 2026

View reviewed changes

jtraglia reviewed Jun 1, 2026

View reviewed changes

address justins + AntiD2ta feedback

8a51c81

bharath-123 mentioned this pull request Jun 8, 2026

Builder api impl gloas ethpandaops/buildoor#81

Merged

bharath-123 added 2 commits June 8, 2026 21:19

make the request auth more generic

9ec931e

rename MAX_URL_BYTES to MAX_DATA_BYTES

1e26b71

rolfyone reviewed Jun 8, 2026

View reviewed changes

bharath-123 added 2 commits June 9, 2026 10:26

remove unecessary specification

8bf1bee

update spec to use auth.data instead of auth.builder_url

1ac301a

nflaig reviewed Jun 10, 2026

View reviewed changes

bharath-123 added 2 commits June 11, 2026 10:24

address feedback and add examples

b573714

add ssz examples

cd89786

bharath-123 mentioned this pull request Jun 11, 2026

All Core Devs - Consensus (ACDC) #180, June 11 2026 ethereum/pm#2113

Closed

4 tasks

bharath-123 merged commit 25aaa5c into main Jun 11, 2026
5 checks passed

bharath-123 deleted the epbs-updates branch June 11, 2026 12:10

StefanBratanov mentioned this pull request Jun 11, 2026

Staked Builder API Consensys/teku#10822

Open

danceratopz mentioned this pull request Jun 15, 2026

All Core Devs - Testing (ACDT) #83, June 15, 2026 ethereum/pm#2116

Closed

4 tasks

terencechain mentioned this pull request Jun 15, 2026

Add Gloas builder API protobuf types and auth domain OffchainLabs/prysm#16977

Merged

hangleang mentioned this pull request Jun 24, 2026

[Glamsterdam] Staked Builder API grandinetech/grandine#769

Open

nflaig mentioned this pull request Jul 5, 2026

feat: implement gloas builder api ChainSafe/lodestar#9594

Closed

shane-moore mentioned this pull request Jul 7, 2026

ePBS (EIP-7732) Support ssvlabs/SIPs#94

Open

NikhilSharmaWe mentioned this pull request Jul 17, 2026

builder_api: add Gloas Staked Builder API client grandinetech/grandine#819

Open

StefanBratanov mentioned this pull request Jul 29, 2026

Staked Builder API REST Client Consensys/teku#11026

Open

2 tasks

	def is_eligible_for_bid(
	state: BeaconState,
	registrations: Dict[BLSPubkey, ValidatorRegistrationV1],
	slot: Slot,
	parent_hash: Hash32,
	pubkey: BLSPubkey,
	) -> bool:

		# Verify that proposer preferences have been received via the gossip topic
		assert validator_index in proposer_preferences.keys()

	- 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

		builder is responsible for publishing the execution payload envelope. The proposer
		MAY observe PTC votes to monitor the timely reveal of the execution payload envelope.

	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."

Uh oh!

Conversation

bharath-123 commented Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bharath-123 commented Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bharath-123 commented Dec 12, 2025

Uh oh!

Uh oh!

bharath-123 commented Dec 15, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 commented Nov 28, 2025 •

edited

Loading

bharath-123 commented Dec 12, 2025 •

edited

Loading

bharath-123 Dec 23, 2025 •

edited

Loading

bharath-123 Dec 23, 2025 •

edited

Loading

bharath-123 May 27, 2026 •

edited

Loading

bharath-123 Jan 6, 2026 •

edited

Loading

bharath-123 Jan 6, 2026 •

edited

Loading

bharath-123 Jun 9, 2026 •

edited

Loading

nflaig Jun 10, 2026 •

edited

Loading