TL;DR

• BidBlock moves validator re-execution after broadcast.
• Block validity rules remain unchanged.
• Builders retain SendBid as a fallback.
• reth-bsc v0.1.3 improves transport and revocation handling.

BNB Smart Chain (BSC) block production can involve executing the same transactions twice before a block is sealed. A builder runs them to construct its bid, then the validator runs them again to check it. As blocks grow, that repeated work takes more of the available block interval.

BEP-675 introduces BidBlock, which lets builders submit blocks with execution results already attached. Validators can assemble and seal a selected block, then re-execute it after broadcast. The reth-bsc v0.1.3 release adds transport and reliability improvements to this process.

BidBlock accompanies the Jenner upgrade as a client implementation change. BEP-675 requires no hard fork. Jenner’s formal hard fork specification covers BEP-702, BEP-703 and BEP-706.

How BidBlock Changes the Production Flow

In the existing SendBid flow, a builder imports the parent block, constructs a transaction bid and submits it. The validator simulates the bid before producing the next block. More gas in the proposed block means more execution work for both parties.

SendBidBlock moves the validator’s simulation out of the work that must finish before sealing. The builder still executes the transactions, and the validator performs full execution checks when it imports the sealed block after broadcast.

This gives builders more time within the block interval to construct blocks and creates room for higher gas limits. It does not automatically raise the network’s gas limit or establish a particular transaction throughput.

Figure 1. SendBidBlock moves validator re-execution after broadcast, removing one execution pass before sealing. Source: BEP-675.

What Builders Submit and Validators Check

A BidBlock carries the transactions and their execution results. It includes:

• A header containing results such as the state root and receipts root.
• Signed user transactions.
• Unsigned system transactions.
• Optional blob sidecars.

The builder signs its submission and sends it through MEV-Sentry, which forwards it to the validator.

Before sealing, the validator checks deterministic header fields against the parent block and consensus rules. It signs only permitted system transactions, recomputes the transaction root, and supplies its own extra data and seal.

After broadcast, the validator imports the block locally and re-executes it to check the submitted results. Other nodes continue to apply normal block validation. The protocol’s block validity rules remain in force.

Figure 2. A signed BidBlock carries transactions and execution results. The validator checks fields before sealing and execution after broadcast. Source: BEP-675.

What Happens When a BidBlock Fails Validation?

Moving execution checks after broadcast creates a tradeoff: a bad BidBlock may already have been sealed and broadcast when the validator discovers an execution failure. BEP-675 limits repeated exposure by revoking a builder’s SendBidBlock permission and retaining the older SendBid flow as a fallback.

Each validator maintains permissions for individual builders. The revocation period depends on the failure:

Condition

• Block import fails: SendBidBlock permission revoked for 24 hours.
• Block imports successfully, but its average user-transaction gas price falls below the validator’s configured minimum: SendBidBlock permission revoked for one epoch.
• Permission returns when the applicable builder-specific window expires.

During revocation, the builder can continue submitting through SendBid, where the validator simulates the bid before sealing. Builders need to query their permissions and switch submission paths when required.

Figure 3. Different failures trigger different local revocation windows. Builders retain the simulation protected SendBid fallback. Source: BEP-675.

What reth-bsc v0.1.3 Adds

The reth-bsc v0.1.3 release improves how BidBlocks are transmitted and how validators handle invalid submissions.

For transport, it uses RLP-encoded binary payloads over gRPC, avoiding JSON parsing and hexadecimal conversion. This reduces serialization work and payload size for large blocks and blob sidecars. The release does not provide a measured speedup percentage.

The release also:

• Rejects BidBlocks with a zero state root.
• Uses bad-block evidence from other validators to revoke local SendBidBlock access.
• Preserves revocations across node restarts.
• Adds metrics for observing bad BidBlocks and revocation activity.

Preserving revocations prevents a restart from clearing an active restriction. Evidence from other validators informs each validator’s local permissions; each validator continues to maintain its own permissions.

Understanding the Performance Estimate

BEP-675 models the critical path as three execution passes under SendBid and two under SendBidBlock. Under its stated assumptions about execution and network overhead, the analysis estimates an approximately 50% higher gas-limit ceiling.

That figure describes modeled capacity headroom. It does not represent a measured 50% increase in live transactions per second or a promise of 50% lower latency.

Builders, validators and sentry operators can validate BidBlock transport and permission handling as part of their deployment. Review BEP-675 for the submission and fallback rules, and the reth-bsc v0.1.3 release notes for the transport and revocation changes.

Further Reading

• BEP-675: Builder Proposed Blocks with Validator Blind Signing
• Jenner upgrade specification
• reth-bsc v0.1.3 release notes