EigenPhi

Posted on May 16, 2022Read on Mirror.xyz

How EigenPhi Identifies Arbitrage Transactions - EigenPhi - Medium

Photo by Marten Newhall on Unsplash

Unlike the traditional Internet, which comprises web pages and hyperlinks, DeFi is built upon Smart Contracts and their complex transaction interactions and structures. The interplays between Smart Contracts, DeFi assets, and their callers are so diverse and flexible that they are impossible to decipher without a powerful tool, let alone decode the hidden market signal.

For example, consider the Cream Finance Flash Loan attack from last year. There were 29 tokens, 30 liquidity pools, 5 protocols, and 75 transfers involved. These transactional elements formed the behaviors, which in turn established the networks.

Structures, behaviors, and networks are the invisible pillars of the DeFi that you have to figure out if you want to be a conqueror of the new world.

Photo by Jeremy Bezanger on Unsplash

As the pioneer of the new generation of DeFi data analysis platforms, EigenPhi adopts methodologies focusing on starting from a thorough inspection of transaction structures formed by Smart Contracts.

With the rigorous dissection and simplified presentation of the asset transfers among liquidity pools, EOAs, and protocols in an easy-to-understand way, EigenPhi’s behavior and network analysis have a solid premise to help users with means of pricing the liquidity and recognizing the risks, eventually being able to take in not only the story behind the curtain but also profits and gains from their assets.

It’s a challenging path to take, but an essential one that EigenPhi has been working on since the beginning. And we are the only team in the market capable of managing to get it done.

Here is the EigenPhi way of dissecting transaction structures in a nutshell.

Recognizing Atomic Arbitrage Transactions

Given that a transaction can be arbitrarily complex and can have an endless number of unknown transaction patterns, the approach of using specific transaction pattern matching cannot cope with new arbitrage patterns. To determine whether arbitrage occurs in a transaction, we need a universal abstraction for transactions.

Here are the principles we set up for the recognition.

We consider a transaction to be a collection of asset transfers, and we use a set of rules to see if an arbitrage has happened by assessing the outcomes of these transfers. The rule of thumb is that there is more than one transfer (or swap) in the transaction, and the trader ends up with a surplus.

Abstract Approach

A Transaction can be abstracted into the following behaviors: Transfer, Trade, and their combinations. TransferTable is generated by merging the Transfers into a single table called Transfer Table. Then we merge the rows with the same address in the TransferTable to get CombinedTransferTable.

Implementation

Asset

  • ETH or ERC20 Token

Transfer method

We use it to describe a flow of Assets between two addresses in a transaction.

  • Transfer :: (From Address, To Address, Asset, Amount)
  • Meaning: transfer Asset from one Address to another Address。

TransferTable

  • makeTransferTable :: [Transfer] -> TransferTable

We use it to describe the** process** of the multiple Assets flows happening between all the involved Addresses in one transaction.

  • The columns of TransferTable are the assets.
  • Each row of the TransferTable indicates that an Asset of an Address has changed, with a positive value indicating an increase and a negative value indicating a decrease.
  • A Transfer corresponds to two rows in the TransferTable: one for the from Address, which corresponds to a negative Asset value, indicating an outflow of Asset, and one for the to Address, which corresponds to a positive Asset value, indicating an inflow of assets.

CombinedTransferTable

We use it to describe the** final outcome** of the multiple Assets flows happening between all the involved Addresses in one transaction.

We merge the rows with the same Address in the TransferTable and add all the Asset values, generating the CombinedTransferTable.

  • makeCombinedTransferTable :: TransferTable -> CombinedTransferTable

Trade

An Address is said to have made a Trade when it ends up with changes in assets after a Trade, where there is a decrease in an Asset AND an increase in another Asset.

Rules for Arbitrage Recognition

Arbitrage is considered to have occurred when the following conditions are met after a Trade.

  • An arbitrage trader has made more than one Trade at another Address.
  • Each Asset involved in the Trades has experienced inflows and outflows in the respective Trade.
  • The trader’s net surplus is positive

Example

A typical Triangular arbitrage identified by EigenPhi

The transfers list:

The TransferTable of the transaction:

The resulted CombinedTransferTable:

The Judgment

  • According to the CombinedTransferTable, we can tell that–SushiSwap USDC 0x397, SushiSwap USDT 0x06d, and Uniswap V3 USDC-USDT 0x785–this three Addresses have engaged in the Trades.
  • The 3 Trades involve USDC, WETH, and USDT, and the columns of each asset have both positive and negative values.
  • MEV-Bot 0x80d has no Trade and its net surplus is positive.

Therefore, we identify this transaction as an arbitrage.

OK then, we’ve walked you through EigenPhi’s methodology of identifying atomic arbitrages. In the next post, let’s take a look at how to recognize a Sandwich arbitrage.


Follow us via these to dig more hidden wisdom of DeFi: