Produce block v4 with payload by shane-moore · Pull Request #580 · ethereum/beacon-APIs

shane-moore · 2026-02-12T18:42:30Z

Introduces the block production and execution payload envelope endpoints for post-Gloas (ePBS) forks. These were separated out from #552 to be discussed and reviewed independently. Prior discussion in PR 552 thread and shane-moore/beacon-APIs#2 as well.

New endpoints:

GET /eth/v4/validator/blocks/{slot} — Post-Gloas block production endpoint (produceBlockV4).
Supports an include_payload query parameter that controls whether the execution payload envelope and blobs are returned inline (stateless multi-BN operation) or cached by the beacon node for separate retrieval (stateful single-BN operation).
GET /eth/v1/validator/execution_payload_envelope/{slot} — Fetch the cached execution payload envelope for the current
proposer's self-built payload. Only available for the current slot; returns 404 for past slots or when no envelope has been cached. Used in stateful mode.
POST /eth/v1/beacon/execution_payload_envelope — Publish a signed execution payload envelope to the network.

Open Questions

Whether a BlindedExecutionPayloadEnvelope (omitting transactions) should replace the full envelope in the stateful POST flow for both proposer self-building and builder envelope submission, since the beacon node already has the data cached (see discussion)

nflaig · 2026-02-13T13:07:38Z

Sign in to view

+    - Validator
+    - ValidatorRequiredApi
+  parameters:
+    - name: slot


while implementing this, I noticed the slot alone is not definitive enough (eg. in case of forks), we should consider also passing the beacon_block_root here

hm, what do you think about making it optional to pass beacon_block_root like in 0c45859? pretty sure the VC already computes the block's tree hash root during signing, so passing it here should be straightforward

Yes, we do already compute the block root on the vc side. I am not a big fan of optional parameters, so I'd rather have it as required or remove it if it's not needed, so far it makes our implementation simpler, maybe get more feedback from others who already implemented the apis

I feel you, perhaps @eserilev @tersec @StefanBratanov or others from your teams have some thoughts here

@nflaig, thought more about this. made beacon_block_root a required field in 5413e57 since just passing the slot alone isn't sufficient under potential fork equivocations. open to feedback if folks have a different stance on this

Yes, prefer required to optional fields.

james-prysm · 2026-02-17T16:57:57Z

+      description: "Slot for which the execution payload envelope is requested."
+      schema:
+        $ref: "../../beacon-node-oapi.yaml#/components/schemas/Uint64"
+    - name: builder_index


Will this endpoint be used for all builders outside of self building? I think the pipeline might endup being very different which makes me question if we would ever be caching more than just the current slot's payload envelope. terence asked this internally and I didn't have a good answer.

this endpoint is only meant for self-building if you are the proposer or the "act as a builder" mode where you build the payload for another proposer

builders that produce payloads outside of the beacon node would get their own endpoint which would be under the /builder namespace (at least that's how I am thinking about it right now)

it should be sufficient to only cache the current slot as you consume the cache within the same slot, maybe if that's the case my comment here #580 (comment) is also not needed but I feel like the block root is useful to specify, not just the slot

After thinking about it more, maybe we keep the current apis under /validator to be only used by proposers, which means we can remove builder_index here as it's only used for self-building

makes sense, removed builder_index in 0c45859

so looks like we might wanna use this for builders too if the validator "acts as a builder"

~~worth revisiting if we wanna re-add the builder_index here~~

Edit:

we might be fine, I think it's worth to wait until someone actually implement the "act as a builder" flow e2e, I rather tend towards not mixing up apis required by validators and builders too much

see discord for conversation about this

Notable changes - implement epbs stateful block production (self-build only) - `GET /eth/v4/validator/blocks/{slot}` added - `GET /eth/v1/validator/execution_payload_envelope/{slot}/{beacon_block_root}` added - `POST /eth/v1/beacon/execution_payload_envelope` added - `POST /eth/v2/beacon/blocks` updated - implement envelope state root computation - update block production cache for gloas (includes state root) - add validator block production flow for gloas - add envelope signing to validator store / remote signer - data column sidecar changes required to wire up new gloas type - update beacon-api spec to `v5.0.0-alpha.0` see ethereum/beacon-APIs#580 for reference

bharath-123 · 2026-02-23T21:48:01Z

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


I don't think this applies with gloas anymore. Regardless of whether we self-build or fetch a bid from a builder. We will get back a SignedExecutionPayloadBid in the beacon block. In the case of the builder, the envelope won't be available with the validator.

this needs to be rephrased for gloas, I think I brought that up in the other PR as well

made minimal changes to the description to remove the blinded/unblinded references in 8bf9080

agreed builder_boost_factor needs to be rethought for gloas. we discussed briefly in the old PR here and briefly in the discord

I also found this builder-specs PR defining how BN can set preferences between external bids/p2p bis/VC bids

The question is whether we want to be able to override these BN preferences via the VC. I'm sure the answer is yes, and the question becomes "how"?

Would we want to modify the validator registrations endpoint to signal a VC's per builder bid boost preferences similar to as proposed in the builder spec PR? Pretty sure this POST fires every epoch or when one of the values change

This could replace builder_boost_factor for example

Open to other ideas as well

Would we want to modify the validator registrations endpoint to signal a VC's per builder bid boost preferences similar to as proposed in the builder spec PR? Pretty sure this POST fires every epoch or when one of the values change

We want to get rid of this endpoint, by default, there won't be any registrations or builder preferences submitted to the beacon node, we only submit proposer preferences.

I left a comment related to this here #580 (comment). In my opinion, the beacon-api spec should have no notion of per builder configuration. The builder_boost_factor is still useful for the validator client to signal to the beacon node how it should decide on whether to self-build or pick a bid from the p2p pool, and the bid from the p2p pool is simply the one with the highest value.

bharath-123 · 2026-02-23T21:49:48Z

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


I guess with ePBS, the beacon node is always configured with a builder as it listens to the builder bids on the gossip topic anyways.

not necessarily, we currently have an option to only produce local blocks which I intend to keep, but the default behavior will likely change with gloas to either use bid from p2p or build local, there are still valid reasons to force the node to build a local block, eg. builders censoring, which especially until FOCIL is shipped requires local blocks or a really sophisticated logic in clients to filter out bids from censoring builders

ensi321 · 2026-02-27T05:34:42Z

+  description: |
+    Instructs the beacon node to broadcast a signed execution payload envelope to the network,
+    to be gossiped for payload validation. A success response (20x) indicates
+    that the envelope passed gossip validation and was successfully broadcast onto the network.


In publishBlockV2 we return 202 if block passed gossip validation but failed integration.

Are we doing something similar for publishExecutionPayloadEnvelope?

I guess from another angle to think about this is we broadcast the payload regardless the result of the payload integration, or we integrate first, if it goes well, we then gossip?

We probably want to propagate the envelope as quickly as possible, so ideally:

Apply gossip validation

Broadcast

Run process_execution_payload and import to DB

If (1) fails, we 400. If (3) fails we should probably 202 just like for blocks.

I was hoping we could avoid the nastiness of broadcast_validation for envelopes, but I think there might actually be an unbundling attack (background) for envelopes now:

I think there is an unbundling attack something like:

Malicious proposer publishes block A at slot N committing to bidA and payloadA, where bidA comes from an external builder (could be P2P or otherwise).

Malicious proposer publishes block B (slashable) at slot N committing to bidB and payload payloadB. They will be slashed at the next slot.

Builder for bidA starts to publish payloadA. Even on beacon nodes that have seen the equivocating block, the payload will PASS gossip validation as long as block A was imported.

Proposer publishes payloadB for block B. Envelope gossip validation passes for payloadB because it is signed by a different builder from payloadA.

Result: either A or B could become head, depending on timing. If B wins, the builder of A has revealed potentially valuable information, which could be worth the proposer slashing themselves for (they could use it for a self-build in the next slot).

Proposed fixes:

We could put the burden on the builder to check for block equivocations prior to revealing their payload (no API/spec changes).

We could add a gossip condition to reject envelopes for slashable blocks.

We could add a broadcast_validation=equivocation flag (like we have for pre-Gloas blocks) to check that the envelope's block is not an equivocation. This flag would likely be used by all builders when interacting with their BNs.

We could make the block equivocation check a default part of the API (same as broadcast_validation=equivocation from fix 3, but no flag required and no ability to opt-out).

based off the discord convo, seems like a broadcast_validation flag is warranted. I built it out in b9b6fc6 to use same BroadcastValidation schema as produceBlocksV2 since all the possible values seem to make sense for envelopes as well, but lmk if have some other thoughts on it

I'm just catching up on the discussions here, but I think the broadcast_validation flag and its values make sense to me.

If im understanding correctly, the broadcast_validation =consensus_and_equivocation value on the publish_block endpoint will no longer be useful for unbundling protection? Probably no harm to keep it though.

If im understanding correctly, the broadcast_validation =consensus_and_equivocation value on the publish_block endpoint will no longer be useful for unbundling protection?

no, it's not needed for this anymore, we could discuss if we wanna deprecate broadcast_validation on publishBlockV2, but might still be useful to have basic checks before publishing the block

**What type of PR is this?** Feature **What does this PR do? Why is it needed?** implements the new GET /eth/v4/validator/blocks/{slot} endpoint, we don't hook up the validator client to use it yet for post gloas in this pr. **Which issues(s) does this PR fix?** Fixes ethereum/beacon-APIs#580 **Other notes for review** **Acknowledgements** - [x] I have read [CONTRIBUTING.md](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md). - [x] I have included a uniquely named [changelog fragment file](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md#maintaining-changelogmd). - [x] I have added a description with sufficient context for reviewers to understand this PR. - [x] I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable).

Add a docstring on publish_execution_payload_envelope linking to the in-flight beacon-APIs PR that defines this endpoint (ethereum/beacon-APIs#580) and recording: - stateful-only mode (SignedExecutionPayloadEnvelope; the stateless SignedExecutionPayloadEnvelopeContents form is unimplemented) - spec endorsement of broadcast-before-integration ordering - spec response codes (200/202/400) and that current handler returns 200 even on post-broadcast failures because envelope integration into state is not yet implemented; integration-time failures should switch to 202 once it is.

**What type of PR is this?** Feature **What does this PR do? Why is it needed?** Introduces a stateless mode for validator client using getBlockv4 with payload included in response ``` participants_matrix: el: - el_type: geth el_image: ethpandaops/geth:glamsterdam-devnet-0 cl: - cl_type: prysm cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest vc_image: gcr.io/offchainlabs/prysm/validator:latest vc_extra_params: - --enable-beacon-rest-api - --enable-stateless - --verbosity=debug cl_extra_params: - --verbosity=debug - cl_type: lodestar cl_image: ethpandaops/lodestar:glamsterdam-devnet-0 - cl_type: lighthouse cl_image: ethpandaops/lighthouse:glamsterdam-devnet-0 count: 2 network_params: gloas_fork_epoch: 1 seconds_per_slot: 4 withdrawal_type: "0x01" validator_balance: 40000 num_validator_keys_per_node: 1000 additional_services: - dora - assertoor - spamoor - checkpointz spamoor_params: image: ethpandaops/spamoor:master assertoor_params: run_stability_check: false run_block_proposal_check: false tests: - { file: "https://raw.githubusercontent.com/ethpandaops/assertoor/refs/heads/master/playbooks/gloas-dev/builder-lifecycle.yaml" } snooper_enabled: false global_log_level: debug port_publisher: additional_services: enabled: true checkpointz_params: image: ethpandaops/checkpointz:gloas-latest docker_cache_params: enabled: false ``` needs OffchainLabs#16705 **Which issues(s) does this PR fix?** related to ethereum/beacon-APIs#580 **Other notes for review** **Acknowledgements** - [x] I have read [CONTRIBUTING.md](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md). - [x] I have included a uniquely named [changelog fragment file](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md#maintaining-changelogmd). - [x] I have added a description with sufficient context for reviewers to understand this PR. - [x] I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable). --------- Co-authored-by: james-prysm <jhe@offchainlabs.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…elope

Part of #8828 for the stateful path and helps align gloas `produceBlockV4` with beacon-APIs [PR](ethereum/beacon-APIs#580) - Plumb `include_payload` query through the handler. Ignored for now since stateless mode isn't wired up yet - Add `execution_payload_included` metadata field + `Eth-Execution-Payload-Included` header per spec. Both `false` until stateless lands - Drop the `{builder_index}` segment from the envelope GET URL since no longer included in spec Co-Authored-By: shane-moore <skm1790@gmail.com> Co-Authored-By: Eitan Seri-Levi <eserilev@ucsc.edu>

rolfyone · 2026-05-14T04:07:07Z

is this sorted now?

shane-moore · 2026-05-15T15:34:47Z

is this sorted now?

this pr could be merged as is imo. not sure if others think otherwise. my lingering question in #580 (comment) is about what to do with builder_boost_factor going forward since it doesn't make sense as is, but it probably doesn't make sense to spec it out in beacon api spec yet until builder api spec for how boosting certain builder's bid will work, i.e. ethereum/builder-specs#144. I could make a follow-up gh issue for this if preferable

rolfyone · 2026-05-17T22:51:22Z

sounds like the outstanding issues from discord are

builder_boost_factor
stateful endpoint
at least from @tersec - not sure if these are shared concerns but flagging here. Given this is required for gloas I'd be interested in seeing progress on this api to unblock gloas but we'll need to reconcile these issues in some way.

jimmygchen · 2026-05-18T07:58:15Z

stateful endpoint
at least from @tersec - not sure if these are shared concerns but flagging here. Given this is required for gloas I'd be interested in seeing progress on this api to unblock gloas but we'll need to reconcile these issues in some way.

@rolfyone could you elaborate the stateful endpoint issue? AFAICT the functionality is covered in this PR, or am I missing something?

EDIT: never mind, i see the R&D discussion now.

bharath-123 · 2026-05-18T14:30:29Z

is this sorted now?

this pr could be merged as is imo. not sure if others think otherwise. my lingering question in #580 (comment) is about what to do with builder_boost_factor going forward since it doesn't make sense as is, but it probably doesn't make sense to spec it out in beacon api spec yet until builder api spec for how boosting certain builder's bid will work, i.e. ethereum/builder-specs#144. I could make a follow-up gh issue for this if preferable

builder_boost_factor probably needs to be rethought with ePBS. We probably need a builder_boost for p2p and builder-api bids or sth like that?

I think builder-specific flags like builder_boost, min_bid etc can be specified in the builder-specs. The community did want some standardization of these flags. I can update ethereum/builder-specs#144 to include all the necessary flags and I think the builder-specs is probably the right place to keep these builder based configurations.

james-prysm · 2026-05-20T19:04:06Z

+    "200":
+      description: "Successful response"
+      headers:
+        Eth-Consensus-Version:


we don't need this header on a get request right?

the header is in the response, and from what I can see, it's needed

james-prysm · 2026-05-20T21:26:38Z

+            - $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Gloas.SignedExecutionPayloadEnvelope"
+      application/octet-stream:
+        schema:
+          description: "SSZ serialized `SignedExecutionPayloadEnvelopeContents` or `SignedExecutionPayloadEnvelope` bytes. Use Content-Type header to specify this format"


how are you checking which one was passed the contents of the payload envelope , i'm checking ssz offsets right now, but wondering if it makes sense to just add something in the header to separate the two

how are you checking which one was passed the contents of the payload envelope , i'm checking ssz offsets right now, but wondering if it makes sense to just add something in the header to separate the two

Yea Lodestar ran into the same problem. I think we should have Eth-Blob-Data-Included or something to distinguish the two.

We can either have a separate endpoint or add a header to differentiate both, ideally for the local stateful flow we just wanna pass a blinded execution payload envelope around to get the most out of it as passing the transactions around is not useful. If we go with BlindedExecutionPayloadEnvelope we could also nicely reuse the existing Eth-Execution-Payload-Blinded header here

nflaig · 2026-05-27T09:39:52Z

+  description: |
+    Instructs the beacon node to broadcast a signed execution payload envelope to the network,
+    to be gossiped for payload validation. A success response (20x) indicates
+    that the envelope passed gossip validation and was successfully broadcast onto the network.


If im understanding correctly, the broadcast_validation =consensus_and_equivocation value on the publish_block endpoint will no longer be useful for unbundling protection?

no, it's not needed for this anymore, we could discuss if we wanna deprecate broadcast_validation on publishBlockV2, but might still be useful to have basic checks before publishing the block

nflaig · 2026-05-27T09:49:06Z

+            - $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Gloas.SignedExecutionPayloadEnvelope"
+      application/octet-stream:
+        schema:
+          description: "SSZ serialized `SignedExecutionPayloadEnvelopeContents` or `SignedExecutionPayloadEnvelope` bytes. Use Content-Type header to specify this format"


We can either have a separate endpoint or add a header to differentiate both, ideally for the local stateful flow we just wanna pass a blinded execution payload envelope around to get the most out of it as passing the transactions around is not useful. If we go with BlindedExecutionPayloadEnvelope we could also nicely reuse the existing Eth-Execution-Payload-Blinded header here

nflaig · 2026-05-27T09:51:34Z

+                enum: [gloas]
+                example: "gloas"
+              data:
+                $ref: "../../beacon-node-oapi.yaml#/components/schemas/Gloas.ExecutionPayloadEnvelope"


I would be in favor of just returning a BlindedExecutionPayloadEnvelope here, that's the minimal object we need to pass to the validator client to sign over

nflaig · 2026-05-27T10:02:42Z

+      schema:
+        type: boolean
+        default: true
+    - name: builder_boost_factor


@bharath-123 if a client doesn't have builders configured via api, we don't wanna submit builder preferences at all, so moving boost factor and other parameters there seem wrong to me, we need a way for the validator to signal this to the beacon node. And I don't think the beacon api should be concerned about off protocol builders or per builder configs

nflaig · 2026-05-27T10:08:08Z

+    - name: beacon_block_root
+      in: query
+      required: true


I think we should move this to path instead

shane-moore added 5 commits February 12, 2026 10:00

add flag to include payload in produceBlockV4

e902e3b

chore: add include_payload_flag

56be573

chore: add get payload envelope

e74fde6

stateful and stateless envelope post

5c28168

update validator flow

6ee20eb

shane-moore mentioned this pull request Feb 12, 2026

add produceBlockV4 shane-moore/beacon-APIs#2

Closed

chore: update changelog

25de51f

nflaig added the Gloas api's needed in Gloas fork. label Feb 12, 2026

nflaig reviewed Feb 13, 2026

View reviewed changes

nflaig mentioned this pull request Feb 14, 2026

feat: implement epbs block production ChainSafe/lodestar#8838

Merged

eserilev mentioned this pull request Feb 16, 2026

Gloas stateless/stateful block production endpoints sigp/lighthouse#8828

Open

james-prysm reviewed Feb 17, 2026

View reviewed changes

james-prysm reviewed Feb 19, 2026

View reviewed changes

Comment thread apis/validator/execution_payload_envelope.yaml Outdated

chore: remove builder index from get execution payload envelope

0c45859

bharath-123 reviewed Feb 23, 2026

View reviewed changes

ensi321 reviewed Feb 27, 2026

View reviewed changes

shane-moore added 2 commits March 6, 2026 10:03

chore: update blockv4 builder_boost_factor description

8bf9080

chore: update post envelope with broadcast validation

b9b6fc6

nflaig mentioned this pull request Mar 10, 2026

feat: add gloas execution payload envelope import pipeline ChainSafe/lodestar#8962

Merged

james-prysm mentioned this pull request Mar 12, 2026

Get block v4 OffchainLabs/prysm#16488

Merged

4 tasks

wheelercameron193-hub approved these changes Mar 20, 2026

View reviewed changes

james-prysm closed this in OffchainLabs/prysm#16488 Apr 14, 2026

nflaig reopened this Apr 14, 2026

shane-moore mentioned this pull request Apr 16, 2026

gloas VC block production sigp/lighthouse#8313

Closed

james-prysm mentioned this pull request Apr 27, 2026

stateless block v4 OffchainLabs/prysm#16699

Merged

4 tasks

Merge branch 'master' into produce-block-v4-with-payload

f78aaef

jimmygchen mentioned this pull request Apr 28, 2026

Gloas HTTP API tests passing sigp/lighthouse#9154

Merged

chore: beacon_block_root as required param for getExecutionPayloadEnv…

5413e57

…elope

This was referenced May 5, 2026

chore: remove builder_index from produce_block_v4 sigp/lighthouse#9267

Merged

chore: make post envelope beacon api spec compliant sigp/lighthouse#9276

Open

Merge branch 'master' into produce-block-v4-with-payload

6a64ee1

Merge branch 'master' into produce-block-v4-with-payload

45f142a

This was referenced May 14, 2026

feat(ssv_types): Gloas decode branch on ProposerConsensusData (block-only) sigp/anchor#1014

Open

feat(validator_store): adapt sign_block destructure for Gloas FullBlockContents sigp/anchor#1017

Open

chore: rename dvs to distributed validators

3fed1ee

This comment was marked as spam.

Sign in to view

barnabasbusa mentioned this pull request May 18, 2026

All Core Devs - Testing (ACDT) #80, May 18, 2026 ethereum/pm#2049

Closed

4 tasks

james-prysm reviewed May 20, 2026

View reviewed changes

james-prysm mentioned this pull request May 21, 2026

fix gloas proposal endpoint support OffchainLabs/prysm#16818

Open

4 tasks

This was referenced May 23, 2026

feat: add stateless path to publishExecutionPayloadEnvelope ChainSafe/lodestar#9401

Open

fix: move beacon_block_root from path to query in getExecutionPayloadEnvelope ChainSafe/lodestar#9402

Open

kvqddbvyk6-cyber approved these changes May 27, 2026

View reviewed changes

nflaig reviewed May 27, 2026

View reviewed changes

Conversation

shane-moore commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

New endpoints:

Open Questions

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!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nflaig Feb 19, 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!

nflaig Mar 31, 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!

Uh oh!

bharath-123 Feb 23, 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!

nflaig Feb 24, 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!

rolfyone commented May 14, 2026

Uh oh!

shane-moore commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as spam.

rolfyone commented May 17, 2026

Uh oh!

jimmygchen commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bharath-123 commented May 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shane-moore commented Feb 12, 2026 •

edited

Loading

nflaig Feb 19, 2026 •

edited

Loading

nflaig Mar 31, 2026 •

edited

Loading

bharath-123 Feb 23, 2026 •

edited

Loading

nflaig Feb 24, 2026 •

edited

Loading

shane-moore commented May 15, 2026 •

edited

Loading

jimmygchen commented May 18, 2026 •

edited

Loading