Understanding the Mechanics of MetaMask Swap: A Deep Dive
Written on
In this article, we will dissect the functionality of MetaMask Swap, revealing its intricacies and assessing the validity of the SEC’s claims against Consensys.
It will become evident that the SEC's assertion that MetaMask Swap functions as an unregistered broker holds some weight. Additionally, we will highlight that while MetaMask Swap is often referred to as open-source, it is only partially so, which is significantly different from being entirely open-source.
To conduct this analysis, we’ll employ tools beyond Etherscan, as the latter tends to obscure critical aspects of the process. We will utilize multiple explorers for a comprehensive view.
Examining a Sample Swap
Let's analyze swap transaction 0x66faafe68a2bc3ab0bca75fa84a50dfeca263789ad176d8411c7ad6fa17039f9, in which 0x1aE2B2b7bd085215604a94aF9c900eCb81F0356e exchanged approximately 890k HOPPY for around 0.052 ETH through MetaMask Swap, utilizing the oneInchV5FeeDynamic execution strategy.
MetaMask refers to this as an "aggregator," whereas we term it an "execution strategy." Regardless of terminology, it signifies the algorithm chosen by the user for executing their HOPPY sale order.
The Transaction Breakdown
Most transaction flows can be traced on Etherscan. Let’s take a closer look:
From our analysis, it is clear that the end user interacted, likely via the MetaMask browser extension, with the "MetaMask: Swap Router" contract. The code for the MetaMask: Swap Router is accessible for review.
As indicated in the transaction details, they invoked the "swap" function on this contract:
The critical components of the "swap" function include:
The inputs to the "swap" function are as follows:
The "swap" function performs the following steps:
- Identifies the adapter for the execution strategy.
- Transfers the incoming tokens to the Spender.
- Encodes various data encompassing execution instructions and the adapter.
- Calls "swap" on the Spender, passing the encoded execution data.
This process closely resembles the operations of a broker, doesn't it?
It's important to note that the mapping from the execution strategy to the adapter is governed by a specific address, which is the sole entity permitted to invoke setAdapter on the Router. This address corresponds to a GnosisSafe, and you can verify the owners independently.
Continuing with our analysis, what does the "swap" function on the Spender entail?
The code is available for review, but the key aspect is:
This represents another layer of indirection. After confirming that the message originates from the MetaMask: Swap Router, the "swap" function calls the adapter, passing the encoded execution instructions.
To summarize, the router utilized the oneInchV5FeeDynamic strategy and located a smart contract address for that execution.
The router compiled the input data and transmitted both the address and the data to the Spender alongside the HOPPY tokens intended for sale.
What is the Adapter Address?
The adapter address is 0x7CDf68CE9A05413Cbb76cb7F80EAF415A826E313. You can confirm this by querying etherscan with "adapters" and the input "oneInchV5FeeDynamic," revealing that this is a closed-source contract.
If you’re skeptical, let’s employ a superior explorer for smart contract interactions to visualize the entire transaction:
In this view, we can note:
- Line 0 represents the incoming call.
- Line 5 details the transfer of HOPPY tokens to the Spender.
- Line 39 shows the invocation of "swap" on the Spender.
- Line 40 indicates the handoff of the data blob to the 0x7cd contract. Due to its closed-source nature, our visibility into internal processes is limited, but we can ascertain some details.
- Line 41 confirms the Spender is now the holder of the HOPPY tokens and is allocating execution authority.
- Line 45 executes the transaction, providing a glimpse into the closed-source action. Importantly, this does not imply the entire process is open-source; rather, it reveals MetaMask’s closed-source code calling public external functions.
The aggregation router evidently opted to utilize Uniswap V2 in this instance.
Line 126 subsequently forwards the fee to the MetaMask: DS Proxy contract, which warrants an entirely separate discussion regarding fee processing. MetaMask collects these fees, and we can explore these mechanisms at a later date.
Finally, Line 133 returns the ETH to the user, although this overview omits certain details about wrapping and unwrapping ETH for brevity. Feel free to verify these transactions independently.
Frequency of Interaction
The following image illustrates how frequently the Spender interacts with this specific closed-source contract:
It is evident that the Spender engages with the closed-source contract frequently.
This analysis highlights how MetaMask Swap operates, revealing numerous contracts and a multitude of closed-source function calls. Here are a few examples:
- 0x: 0x727fc6c510F5C5dCBA136471b2451baff0bE4078
- oneInchV3: 0xD2742961d645218FbE0b50227C9b074d4FEC4937
- 0xFeeDynamic: 0x3d1d55c23dFc759C5Ae48500cA88dDF477b3c9E5
- pmmFeeDynamicv4: 0x7bBa8Bd42A19DA78326bE908E2cd52604399a748
If you grasp this explanation, you can track more by monitoring the router's incoming transactions.
Summary of the Workflow
The following outlines the sequence of steps involved in a MetaMask Swap transaction:
- The user places an order including an execution strategy.
- The order is directed to an order router.
- The router identifies the execution adapter for that strategy.
- The router sends the tokens designated for sale, the adapter address, and the order specifics to a spender contract.
- The spender relinquishes control over the received tokens as necessary for executing the order.
- The spender invokes a closed-source contract to implement the execution strategy.
- Fees are transferred from the spender to the “MetaMask Fee Complex.”
- The proceeds from the sale are returned to the user.
If you find this process reminiscent of brokerage operations, you are correct. It parallels the functioning of a money transmitter as well.
Notably, steps 4, 5, and 6 mirror the concepts of "transmittal order" and "transmittal of funds." If you have the capability to publish adapters, invoke setAdapter on the router, and modify the input data blob, you could effectively manipulate the process at will.
Even possessing partial control allows significant maneuverability with the input tokens. This, undoubtedly, characterizes the role of a broker.