Skip to content

Comments

feat: added ExecutionPayloadV4 and engine_newPayloadV5,engine_getPayloadV6#3330

Open
Rimeeeeee wants to merge 30 commits intoalloy-rs:mainfrom
Soubhik-10:exec-v4
Open

feat: added ExecutionPayloadV4 and engine_newPayloadV5,engine_getPayloadV6#3330
Rimeeeeee wants to merge 30 commits intoalloy-rs:mainfrom
Soubhik-10:exec-v4

Conversation

@Rimeeeeee
Copy link
Contributor

Added ExecutionPayloadV4 and engine_newPayloadV5, engine_getPayloadV6.
ref
cc: @mattsse

Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

nice, few nits

@github-project-automation github-project-automation bot moved this to In Progress in Alloy Dec 11, 2025
@Rimeeeeee Rimeeeeee requested a review from mattsse December 12, 2025 07:22
Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

great stuff

left some questions

could you perhaps rebase this one and also prepare a reth pr with alloy patches to this branch with activated amsterdam feature?
then we can start integrating this to main, basically splitting up the bal-devnet-1 branch into smaller chunks

/// Represents all possible payload versions.
#[derive(Debug, Serialize)]
#[serde(untagged)]
#[cfg(not(feature = "amsterdam"))]
Copy link
Member

Choose a reason for hiding this comment

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

instead of feature gating the type, can we instead feature gate the variant instead?

Comment on lines 102 to 103
#[cfg(not(feature = "amsterdam"))]
impl AnyHeader {
Copy link
Member

Choose a reason for hiding this comment

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

do we need this feature gated impl or can we instead feature gate the the access_list_hash usage instead?

mattsse added a commit that referenced this pull request Jan 21, 2026
Adds BeaconExecutionPayloadV4 struct and beacon_payload_v4 serde helper
module to support the Beacon API representation of ExecutionPayloadV4.

This complements the ExecutionPayloadV4 type added in #3330.

See: #3330

Co-authored-by: Rimeeeeee <[email protected]>
Co-authored-by: Soubhik-10 <[email protected]>
mattsse added a commit that referenced this pull request Jan 21, 2026
Adds BeaconExecutionPayloadV4 struct and beacon_payload_v4 serde helper
module to support the Beacon API representation of ExecutionPayloadV4.

This complements the ExecutionPayloadV4 type added in #3330.

See: #3330

Co-authored-by: Rimeeeeee <[email protected]>
Co-authored-by: Soubhik-10 <[email protected]>
mattsse added a commit that referenced this pull request Jan 21, 2026
Adds BeaconExecutionPayloadV4 struct and beacon_payload_v4 serde helper
module to support the Beacon API representation of ExecutionPayloadV4.

This complements the ExecutionPayloadV4 type added in #3330.

See: #3330

Co-authored-by: Rimeeeeee <[email protected]>
Co-authored-by: Soubhik-10 <[email protected]>
mattsse added a commit that referenced this pull request Jan 21, 2026
Adds BeaconExecutionPayloadV4 struct and beacon_payload_v4 serde helper
module to support the Beacon API representation of ExecutionPayloadV4.

This complements the ExecutionPayloadV4 type added in #3330.

See: #3330

Co-authored-by: Rimeeeeee <[email protected]>
Co-authored-by: Soubhik-10 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

3 participants