The public data availability (DA) MEV attack vector highlighted by Sei Research prompted me to reflect on a key architectural divergence between Sei and chains like Aptos or Sui: validator differentiation in transaction dissemination. While Aptos and Sui employ broadcast-based protocols that ensure all validators see a largely uniform transaction mempool, Sei takes the opposite approach—intentionally fragmenting the view of the mempool by allowing each validator to maintain a private batch of transactions in any order they choose before forwarding them to the leader. This design encourages proliferated validator perspectives and opens the door for app-level sequencing strategies to emerge natively within the Sei ledger itself.

So I followed up on that.

If we use the Aptos's Sender Aware Transaction shuffling by the leader in the tip cut the problem for the transactions where the validators can replace the whole transaction and the user's transaction does not get through can be solved to a limit But there still remains the problem vector from public DA where:

• A validator cannot reorder transactions (e.g., due to Sender Aware Shuffling or deterministic order),

• Cannot change the priority fee,

• But can steal the tip by signing and relaying the same transaction as their own before the original validator's version is confirmed.

This represents a Public Data Availability (DA) vector that arises even under strict ordering and fee structures, because the validator's signature and propagation advantage become the tools for theft.

Suppose a validator receives a transaction with a large tip as a fee. The validator then re-broadcasts this transaction to other validators. A malicious validator could potentially steal the transaction, including the tip and gas fee, and re-broadcast it as their own.Since the transaction contents are the same, it's difficult to detect whether the validator who re-broadcasted it is the original or a malicious one.

Both versions of the transaction are then received by the network. Normally, when conflicting transactions are observed, the leader selects the one with the lower Validator ID.

However, this approach (or even first-come-first-serve based on identical signatures) has issues.

• If a validator sends a transaction and another validator geographically close to them intercepts it, the second validator can:

  1. Steal the transaction,

  2. Delay the Proof-of-Authority (PoA) vote on the original transaction's containing tip

  3. Gain inclusion in the block due to faster propagation or manipulation.

This can be especially harmful because in a system with f+1 voting (where f is the number of tolerated faulty validators), even a small number of malicious validators can cause honest transactions to be excluded.

As a result, the original validator's transaction may not gather enough votes in Time. So the validator's geographical location and co-location with the validators is a big factor.

Quorum Attestation of Origin

• When the original validator broadcasts a transaction, it also gathers f+1 soft attestations that confirm it was the origin.

• Any conflicting version is provably second.

• Can be implemented using BLS signature aggregation or timestamped receipts.

Works even when some validators collude to delay propagation.

Pre-Signed Proof-of-Origin (Transaction Anchoring)

• Users or relayers bind the transaction to a specific validator by including its identity in a signed message.

• Any version signed by another validator is invalid.

• Lightweight and simple, but breaks if delay lets a malicious validator insert their version first.

The public data availability (DA) MEV attack vector highlighted by Sei Research prompted me to reflect on a key architectural divergence between Sei and chains like Aptos or Sui: validator differentiation in transaction dissemination. While Aptos and Sui employ broadcast-based protocols that ensure all validators see a largely uniform transaction mempool, Sei takes the opposite approach—intentionally fragmenting the view of the mempool by allowing each validator to maintain a private batch of transactions in any order they choose before forwarding them to the leader. This design encourages proliferated validator perspectives and opens the door for app-level sequencing strategies to emerge natively within the Sei ledger itself.

So I followed up on that.

If we use the Aptos's Sender Aware Transaction shuffling by the leader in the tip cut the problem for the transactions where the validators can replace the whole transaction and the user's transaction does not get through can be solved to a limit But there still remains the problem vector from public DA where:

• A validator cannot reorder transactions (e.g., due to Sender Aware Shuffling or deterministic order),

• Cannot change the priority fee,

• But can steal the tip by signing and relaying the same transaction as their own before the original validator's version is confirmed.

This represents a Public Data Availability (DA) vector that arises even under strict ordering and fee structures, because the validator's signature and propagation advantage become the tools for theft.

Suppose a validator receives a transaction with a large tip as a fee. The validator then re-broadcasts this transaction to other validators. A malicious validator could potentially steal the transaction, including the tip and gas fee, and re-broadcast it as their own.Since the transaction contents are the same, it's difficult to detect whether the validator who re-broadcasted it is the original or a malicious one.

Both versions of the transaction are then received by the network. Normally, when conflicting transactions are observed, the leader selects the one with the lower Validator ID.

However, this approach (or even first-come-first-serve based on identical signatures) has issues.

• If a validator sends a transaction and another validator geographically close to them intercepts it, the second validator can:

  1. Steal the transaction,

  2. Delay the Proof-of-Authority (PoA) vote on the original transaction's containing tip

  3. Gain inclusion in the block due to faster propagation or manipulation.

This can be especially harmful because in a system with f+1 voting (where f is the number of tolerated faulty validators), even a small number of malicious validators can cause honest transactions to be excluded.

As a result, the original validator's transaction may not gather enough votes in Time. So the validator's geographical location and co-location with the validators is a big factor.

Quorum Attestation of Origin

• When the original validator broadcasts a transaction, it also gathers f+1 soft attestations that confirm it was the origin.

• Any conflicting version is provably second.

• Can be implemented using BLS signature aggregation or timestamped receipts.

Works even when some validators collude to delay propagation.

Pre-Signed Proof-of-Origin (Transaction Anchoring)

• Users or relayers bind the transaction to a specific validator by including its identity in a signed message.

• Any version signed by another validator is invalid.

• Lightweight and simple, but breaks if delay lets a malicious validator insert their version first.