Strong Builder Identity for Combating Builder Imposter Attacks

Strong Builder Identity

co authored with @kobigurk from Geometry and @mmp from SMG
Thanks to @akinovak for comments.

5 Hours ago, Titan Builder announced on twitter that they had evidence of a builder impersonating them. In the post Titan described how an imposter has been using Titan’s extradata, “Titan (”, in blocks produced by the imposter. The imposter also set Titan’s address as the block recipeint (titanbuilder.eth). The only identifying information that the attacker couldn’t spoof was the proposer payment transaction which it sends from (titanpayload.eth).

You can see a recent example imposter block here.

What the imposter is trying to acomplish is unclear at this stage. That said, as of the time of writing, Titan estimates they have spent over 17 eth and an attacker rarely does this without a plan for making it back.

There are also possibly connected reports of a flashbots imposter.

Motivated by this, we suggest a stronger builder identity system. Rather than rely on plaintext extradata to identify builders, which is easy to spoof, the extradata should be used for a builder signature.

The main design constraint we have is that the system must integrate into the current block structure.


BN254 BLS signatures

BN254 is a pairing-friendly curve commonly used for SNARKs, and has cryptographic operations precompiled on Ethereum since EIPs 196 and 197.

BLS signatures are a pairing-based signature scheme, where the signature is a single group element. For BN254, this means we can encode a signature in 32 bytes.

Additionally, it’s possible to (somewhat) efficiently verify BLS signatures on Ethereum.


The registry smart contract would accept the following from builders:

  • Builder info:
    • Name
    • BN254 public key
    • .eth address and a signature from it (or some other identifiying mechanism)
  • BN254 signature on the builder info hash

The registry would verify the signature before approving the builder.

The builder info would be stored in an append-only list, and the builder would keep their index in this list, denoting it builder index.


The builder has the ability to set the extra data field in a block, which is 32 bytes long. The builder would put a BLS signature on the block hash in the extra data.

Proposers may verify the signatures before proposing, but they don’t have to.

Gas limit watermarking

The builder also has to tell the signature verifiers which builder they are, and they don’t have enough space in the extra data anymore.

Note that the builder can at least control the last 3 digits in the gas limit arbitrarily, allowing them to use it for their builder index.


Verifiers would then get the corresponding name and public key from the smart contract.

Explorers can use this data to verifiably display builder identities in blocks.


Note that with current relay design, the relay can change the gas limit unilaterally, which may be a concern. However, a malicious relay can already do a lot worse things than this in the present design, so we are comfortable assuming a trusted relay.

Other design possibilities

  • Use longer but cheaper signatures and encode them in the proposer payment transfer transaction. The problem is that the proposer payment transfer txn does not always exist
  • Encode the builder index in the same place. Same problem

1 post – 1 participant

Read full topic

Improving User Experience for Time Sensitive Transactions with a Simple Change to Execution Logic

As usage of the Ethereum network for DeFi has increased, more and more transactions are time sensitive. That is, there are transactions for which, if they are not executed in a timely manner users would prefer that they not be executed at all.

For example, consider a simple trade on UNIv3 ETH/USDC. If it executes quickly, then users get a reasonable price and they are happy. If it executes slowly however, it may become stale, users may get a worse price or get sandwiched because their slippage tolerance is no longer set correctly. If is not executed quickly, users might prefer it be automatically canceled so they can submit another transaction.

It is possible to get this kind of behavior currently; however, it requires costly on chain operations, and the transaction may be included on chain anyway, meaning that even though the transaction has been killed, the user still pays gas.

To accommodate these preferences, I suggest adding a new field to ethereum transactions fillBy. fillBy is an optional field where a user can choose a slot which if specified would make a transaction invalid after a certain slot has passed in the same way it would be invalid if the signature didn’t check out or if a transaction with the same nonce from the same user had already landed on chain.

This would be extremely useful for searchers particularly in preventing low carb crusader attacks over multiple blocks, which could eliminate the attack even without single slot finality.

1 post – 1 participant

Read full topic