Fundamental Problem For DeFi on Ethereum Has Been Exposed

On Friday, Dan Robinson published a breaking blog post about the Ethereum network. Dan is a lawyer and programmer as per his Twitter account. According to his analysis, there are multiple bots scanning the Ethereum mempool (the pool of transactions awaiting execution), looking for ways to profit off of other users.

User inadvertently sent the wrong tokens to the smart contract

Robinson was shown the problem right under his eyes when he was contacted by an Ethereum user. The user wanted to supply liquidity to a trading pair on Uniswap. But instead of sending the required tokens, he mistakenly sent the associated Pool-tokens. Pool-tokens are usually the obtained after depositing the original ones to the pool. They make it possible to later retrieve the original tokens in addition to the interest gained from providing liquidity. The tokens sent mistakenly were worth approximately $12.000.

Originally, Robinson assumed that these tokens were lost for good. But then he realized that the contract executes the “burn” function. This function destroys all Pool-tokens obtained by the contract and sends the associated original tokens to a selected address specified when calling the smart contract. In other words, anyone can claim these tokens if they know of it.

Plands to recover the tokens

Robinson then assumed that he only had to call the burn function with the user’s address to retrieve the tokens, and all would be good. But he didn’t immediately act on it, instead he thought about it. It is obvious that, wherever there’s the possibility of making profit, others will attempt to get to them as well. It is no secret that bots constantly scan the Ethereum mempool in search of such opportunities. The bots will try to overwrite such transactions by racing them to be included first in blocks (e.g. by using higher fees).

The Uniswap contracts are standardized. Anyone can open a new pool with an ETH/ERC-20 or ERC-20/ERC-20 trading pair. Therefore, it is easier for malicious agents to scan the mempool for certain function calls, than to monitor every single smart contract. Whenever a transaction calling the “burn” function lands in the mempool, the attackers are alerted.

Robinson knew that someone was most certainly waiting for this gift, which he would be handing over by calling the burn function. He decided to seek expert help to mask the transaction. To this end, he installed two smart contracts on the mainnet. One of them calls the burn function, after being earlier activated by the other.

The bots were faster

Due to some mishaps, a bot was faster and beat them to the $12.000: when the contracts were deposited on Ethereum, they sent the transaction that activates the contract, that was supposed to call the burn function. When they tried to order this contract to call the burn function, their wallet indicated a mistake, because the gas estimator couldn’t be overwritten manually. This cost important time and the second transaction was included one block later.

This small mistake was all the attackers needed to succeed. Robinson admitted having made mistakes, and that it was most probably possible to retrieve the tokens with more care. But he simultaneously refers to a larger problem.

Miners could’ve executed this action much more efficiently

Robinson writes that the “frontrunning” example is only one of many that happen every day. The financial incentives might motivate the miners to do the same as these bots, but with significant advantages. Miners don’t have to push the transactions to the mempool, but could directly include them in the block once it’s their turn, while omitting the transactions they are trying to overwrite. Additionally, they would only have to simulate a high gas fee, as they will earn the fees for mining the block. Even more, the miners could ignore previous blocks, given enough financial incentive. This makes the possibility of profit higher.

Is there a solution to this problem?

Robinson calls the readers to contact him if they are thinking about this problem, or working on possible solutions. Daniel Larimer, the developer of the EOS software, picked the blog post up on Twitter:

This is why #ethereum is unsuitable for #defi The problems described don’t exist on #EOS as it is both too fast to front run and producers are known and can be held accountable. Scary what happens on #eth. https://t.co/o6MdVW8u6U

EOS is indeed involved in the development of DeFi, but still lags behind Ethereum as all the other platforms. If this problem is important enough to motivate DeFi projects to migrate to EOS, remains to be seen. But it is definitely worth keeping an eye on.

Want more crypto news and price analyses? Join CryptoTicker on Telegram and Twitter