Method Analysis of Frontrunner Contracts
Ethereum Smart contracts have massive flexibility, and one aspect of that is the MethodID system. Smart contracts are very similar to wallets, having an address that transactions can be sent to. When the user interacts with a smart contract, the main flexibility comes from choosing the input data they send to the contract. The above sketch shows a basic example from the Wrapped Ether Contract (WETH). Wrapped Ether is the same as Ether (ETH), but more useful in the DEFI ecosystem, so many contracts convert ETH to WETH, and vice versa
This example transaction was sent from a wallet address, and calls the MethodID 0x2e1a7d4d, with a 256 bit value, wad. This method tells the contract to convert 11 WETH for 11 ETH, and transfer that back to the sender wallet. This MethodID system allows the user to interact with 1 Smart Contract in many different ways, with a variety of inputs.
While the most commonly used smart contracts like Token Routers, or Uniswap Routers have publicly available source code to understand the inputs, and desired outputs, the frontrunners are very secretive, and use entirely different conventions at times. In order to further understand the different functions and tasks carried out by the frontrunner contracts, I created a script that indexed the number of times a method was called each day, and ran this over the 9 month transaction history.
The above methods were all the method that were called more than 100 times over the 9 month history, and the contract contained 20 additional methods that were never called, and several more that were called less than 30 times, but I left those out in favor of readability.
Looking at the chart, you can see that the contract went through upgrades, and changed the methods it used to drain value. In the first weeks of the contract, you can see that methods were being called and tested, and then the contract rapidly upgraded until it began frontrunning in January of 2021. The first months predominantly used Method 2 and 6 in conjunction, as well as Method 0 and 1 in conjunction. Other methods were called occationally, but those 4 made up the majority of the transactions for those first few months.
In early April, the method calls change completely, and Methods 1, 2, and 6 are almost never called again, and the majority of the new calls are to Methods 0, 5, and 7. This marks a major upgrade in the contract, and the transaction inputs are changing as well. This style of frontrunning continues until late June, where another upgrade occurs, and the Fallback method begins processing the majority of transactions. This Fallback method is called when the first 4 bytes of the input data, (MethodID) don’t match up with any of the other MethodIDs of the contract. In most contracts, this method creates an error, and returns the ETH to the sender with an error message, but the frontrunner is using this to gain additional flexibility and efficiency with its calls, and uses an uncommon data input mechanism as shown below.
The fallback function of this frontrunner, which currently processes the majority of transactions, doesn’t follow the data input most contracts use, where every input it 32 bytes, with extra zeros to pad out smaller input values. Instead of storing contract addresses with 12 bytes of zeros and 20 bytes of data, the fallback method takes inputs of different byte ranges, lowering the number of bytes required, and making the contract more difficult to understand.
The more I learn about frontrunning on the Ethereum network, the more confused, frightened, and amazed I become. Looking at the call data and methods of this 1 contract, you can see that frontrunners are continuously being upgraded, improved, and changed to more efficiently drain value from average users, and the tools and methods these frontrunners utilize are different from what is normally seen on the Ethereum network, which makes it harder to understand what they are doing, which can make this a daunting problem to attempt to remedy.
