MEV

This is a summary of my first taste of MEV (if you can call it that), where I "competed" with other bots to receive a fee for providing a service to boo stakers. But before we continue, I think we should lay out some terms and definitions. What is MEV?

The definition of what MEV encompasses within the EVM world can be debated, as even the name itself is not well established (is it miner extractable value, or maximal extractable value??). However, I'll go with the following definiton: MEV refers to the maximum value that can be extracted from block production in excess of block rewards and gas fees, by including/excluding/changing the order of transactions in a block. This is a cool website on MEV.

Next term, DEX (decentralised exchange). An exchange is fairly simple to understand - as the name implies it is a place where buyers and sellers meet to exchange stuff, in this case cryptocurrencies. So what makes a decentralised exchange unique from a centralised one. Simply put, the latter is facilitated by a single intermediary, which by nature will give them extraordinary power. In addition, they use what's known as a CLOB (central limit order book), which are too complicated for your average joe to participate in as a market maker. On the other hand, DEXes implement a different design known as an AMM, which allows anyone to participate in as a liquidity provider with the click of a button. With those out of the way, let's get into my amazing MEV experience.

To give a bit of context, I had just read this article on how a well know DEX called Trader Joe's had been exploited for hundreds of thousands due to a vulnerability in their fee converter contract. So, what exactly is this fee converter contract? To explain that we need to understand what providing liquidity means. At a very high level providing liquidity means you deposit your assets in a pool to facilitate others to trade between those assets, and you, the liquidty provider, are simply happy to take the other side of every trade. Why would anyone want to do this? Well, for starters you receive a percentage fee on every trade that occurs against your pool. In addition, you will also receive the native token of the exchange. This native token can have multiple purposes, but the common use cases are governance power in the decision-making of the protocol, and receiving part of the revenue of the protocol (generated through fees - it doesn't all go to liquidity providers). More on liquidity providing here.

We're specifically interested in the process by which fees generated by the protocol are distributed to the holders of the native token of a DEX. Again, staying at a high level, users are able to stake these tokens (meaning deposit in a contract). They then own a share of the number of tokens in that contract. The next step in the process, is the following, the protocol starts generating fees from every swap, these fees being in the form of LP (liquidity provider) tokens, which will all be sent to the same place - the converter contract, whose sole purpose is to convert these lp tokens into the native token. It then sends the native token to the staking contract, hence increasing the number of tokens in it, meaning your share now represents more tokens. Hence, as a user the workflow is pretty simple, you just stake the token, and watch the number of tokens you have go up (the value of each token could of course decrease, meaning this strategy is by no means risk free).

Long story short, Trader Joe messed up they're converter contract, and allowed someone to steal a lot of money. The details of which are out of scope of this article and can be found in the link attached previously. Anyhow, here I was, with this new-found knowledge of how to exploit fee converters, which by the way are implemented in every DEX out there, and there are a lot. Surely I could find another DEX which the exact same vulnerability.

Spoiler: I didn't. However I did find something interesting in one of the DEXes called Spookyswap, they actually paid people to convert fees (LP tokens) into the native token (boo), or rather they paid you to call the function that would do so, in exchange giving the caller a percentage (0.1%) of the value converted. So if you converted 100$ worth of lp tokens, you received 10 cents - its not much but its honest work. If only I could find a way to automate this, I would be able to make money while sleeping - what else can you want in life right? Well guess what, Spookyswap actually provides an already made python script that you can copy and run on your computer. So that's what I did, I copied the code, followed the instructions, and ran the script. Again, spoiler: I did not instantly make free money (big surprise!). At this point it makes sense to add some code in the explanation, so if you don't understand solidity feel free to skip, or not! The following is a screenshot of the function you get paid to call.

Looking a little deeper into the code, we see the function expects three arrays as arguments: token0 and token1 which represent the LP tokens, and LPamounts, which represent the amount of each LP to convert. In other words, if I pass the following paramater [ftm, ftm], [eth, usdc], [10, 15], I would convert ten LP tokens of the FTM-ETH pool, and fifteen LP tokens of the FTM-USDC pool. So what exactly did the python script do for me? It encoded an arbitrary list of LP token addresses that it passed as parameters, and simply told the contract to convert however much it had of these LP tokens (this can be done by leaving the amount field blank). Turns out, if you specify an LP token whose balance in the converter contract is 10 cents, which you will make 1/10 of a cent from, you will not be able to cover gas costs with that - REKT. Ok, so we need to be a little smarter than just converting any LP token. How about this, lets loop through the list of LP tokens, probe the converter contract to check what the balance is for each LP token, and if its greater than, say 50$, add it to the array of tokens that we will pass as parameters. That way, if lets say ETH-USDC, ETH-FTM, and ETH-BTC all have 50$ worth of tokens, thats 150$ converted which equals 0.15$ for us, at least enough to cover gas costs (at least on the ftm network which is where all this is happening). If none of the LP tokens had more than 50$ we would not waste money sending unnecessary transactions. Great! Spoiler, once again: didn't work. This time the reason was more nuanced. While my script was busy adding up all the LP tokens that were worth converting, other bots said screw it, I'm converting this LP straight away before anyone else gets it. Hence, by the time my script finished adding all the possible LPs to a list, they had all been converted, leaving 0 left for me to convert. Ok, so the solution should be easy, forget adding up all the LPs into an array, as soon as my script finds one, convert it immediately! You guessed it: fail! But at least this time it was close, another bot frontran me by just 2 seconds! (Below is the failed tx);

At this point I decided it was time to throw in the towel, with more time I might have found a way to detect when the balance of an LP token rose dramatically (ie. listening to the events of big swaps as those generate the fees), but I was too tired and sick of the stupid converter contract that I decided to call it a day.
Overall the experience was definetely a lot fun, even watching other bots steal my well deserved fees was kind of cool in a way. Will close this off with the cliche - see u in the mempool anon...

Hide

In this article I'll be going through two simple solidity projects I built 'Aurora Futures' and 'Aurora OTC'.

To give a bit of context, the early founders of Aurora (a blockchain running as a smart contract on NEAR) were given, as part of their compensation plan, a number of vesting aurora tokens, which they had ownership over, but could only access them (to transfer/sell) at specific dates. One of the issues with this (as opposed to a linear vesting schedule), is that at the specific date of unlock, a lot of aurora tokens would hit the market at once, which could create a lot of downward pressure on the aurora token price. Hence, I suggested to one of the aurora core team members to create a "futures" aurora token. This "future" token would be a simple ERC20, but with some additional features - it would allow Aurora Labs (who is in possession of these locked tokens), to send aurora tokens to this futures contract, and it in return the contract would mint the equivalent amount of futures tokens. The final key feature of the futures contract is that it allows the holder of the futures token to redeem said tokens for the underlying aurora tokens held by the contract at a 1:1 rate, and, importantly, at the date of unlock. So why is this useful? Well, now Aurora Labs could send these futures tokens to each member who was allocated aurora tokens, who then have the freedom to do whatever they like with them. Some examples include adding liquidity to a DEX (ie. Trisolaris). Lending markets such as Bastion or Aurigami could add support for these futures, and allow holders to borrow against them, allowing them to get immediate liquidity from the tokens without having to sell them. The final option, and perhaps the most used, is selling these future tokens OTC (over the counter), in private deals. The latter use case is the one I'll be focusing on in the next few paragraphs.

Selling tokens in private deals is a perfectly viable solution. However, in my opinion, it's not as ideal as a free market where the tokens reach their true fair market value. With private deals, the buyer can be left wondering whether they could have gotten a better deal from another seller, and vice versa, a seller of aurora futures could be left wondering if they could have sold for higher to a different buyer. These are obviously small issues, as both parties will only agree to a trade if they're both happy with the outcome. However, the topic sparked an idea that I could implement as a simple solidity project - a trustless OTC desk. The common definition of OTC (over-the-counter) trading in its simplest form is trading done directly between two parties, without the supervision of an exchange. The use case tends to be for large trades which would otherwise have too big an impact on the price if traded on an exchange. Without further ado, below is an image of the smart contract that facilitates such transactions.



Due to my ineptitude in displaying images I'll link the Github Repo where you can find the code for the contract in uniform text size. Anyways, moving on. The contract above has defined a special type (struct) called Deal. This type, as described by the comments in the code, represents a single OTC deal. This includes the token provided by the creator of the deal, the amount of said token, the token the creator wishes to receive, and the amount he wishes to receive of said token. Once a deal is created, it is added to an array which contains all OTC available. Now, anyone can come along, scroll through the array of deals, and accept any by simply passing the index of the deal as a parameter. A useful feature is that deals can be partially accepted, ie. if theres an offer to exchange 10btc for 200k usdc, you can choose to take half of the deal (swap 100k usdc for 5 btc). Finally, once a deal has been completed, ie. theres no more tokens to swap, the deal is removed from the array. The next step for me regarding this project is to get a working frontend that doesnt look terrible (all of my websites do), and get people to try it out.

Hope this short story was interesting and see you in the next!

Hide