Gas price ordering not being respected

Polygon Mainnet (PoS) Proof of Stake
1

EDIT: looks like this is expected behavior due to nonces, see posts below.

Hello everyone,

I am writing to share a concerning finding with you, which is that I have seen a block where transactions were mined out of order with regards to gas price. I do not intend to make any conclusions in this post; I would just like to present the information.

As you will see, this type of behavior is concerning because of the potential for MEV extraction by validators. Bor is currently programmed to order transactions first by gas price, and then by “time seen”. Validators already a vast advantage over non-validators when it comes to MEV, as they are peered with all other validators and thus, have extremely low latency to whomever is the current block producer. (Detailed in this thread regarding BSC, but still applicable to Polygon: https://github.com/binance-chain/bsc/issues/269)

However, if the validators start ordering transactions in a non-default manner, they can effectively capture all of the MEV that is created on the Polygon network.

The information is as follows.

(I apologize for the lack of links in this post; I was limited by the forum rules for new users. Please copy/paste into Polygonscan as needed.)

This is the block:
16531502

The out of order transaction:
0x67cbda1263aae047f249a8d53fce11cd6557fa4fc7a62621194c474736837681

Why is the transaction out of order?
The transaction immediately before and after this one uses exactly 4 gwei.
This transaction uses 4.000010001 gwei.

Now, what is this transaction?
This transaction itself didn’t do anything. It is important to note, however, that the transaction appears immediately after an oracle update to Aave’s USDC oracle: 0x7b340f63074f94d0088186f85884c4687451d3813db24495d9ee0c09c43e569a

Why is this oracle important? Because it can trigger an Aave account’s health factor to go below 1, which means that the user can now be liquidated.

Who is the recipient of this transaction?
The recipient of the out of order transaction is a smart contract: 0xb4171e36cbeea21a8b5a2dab5f9ed9f5dc7ecfe4

What does this smart contract do? Aave Liquidations. In the 17 days that this contract has been active, they have made approximately $767,901.36 from liquidation bonuses, before accounting for trading fees (as they are using flashloans as the upfront capital to perform liquidations.) I calculated this figure using Aave’s subgraph, however you can just go to the “ERC-20 Token Txns” tab on Polygonscan to easily verify that they are receiving large amounts of liquidation bonuses.

Here is an example of a successful transaction:
0x12f6c67c6fccc1495b7936abbe6cc4083b3c23b1834892f341de9e27ca308443

2 Likes
2

Want to echo the opinions from the Ethereum community that are against this type of MEV. Allowing validators to reorder trasactions in their own favor is especially unfair in Proof-of-Stake systems where there are a limited number of validators.

And approaches like Flashbots essentially create a separate “lane” for robbing Ethereum users. Polygon has a chance here to get this right and create a meaningful product differentiator.

Two things to mitigate this:

1/ weight validator stake on a curve to boost voice/weight of smaller validators as was proposed by Polygon team a while ago

2/ implement some kind of fair ordering mechanism via encrypting orders or using Chainlink Fair Ordering system or other

2 Likes
4

An update: I have been told that this is expected behavior due to account nonces. I am not familiar with this, but I am nowhere near an expert on the matter, so it’s very possible that I am missing something. I plan to look into this now…

1 Like
5

It seems like Polygon community needs to decide this in the future either way – whether it is already happening or starts happening in the future.

6

@adamb Did you find any detailed explanation on the same. I am trying to understand transaction ordering.