Most people who are used to trading on centralized exchanges are familiar with using limit orders, where one is able to set orders that are off from the market price. Automated market makers such as Uniswap don’t have these features, which makes trading Uniswap-only pairs a bit of a problem, especially when one is trying to take advantage of volatile tokens such as $PRIA.
I’ve been looking for ways to set limit orders with Uniswap, and after several dead ends I’ve found two that may work. One is an on-chain protocol, the other is a bot.
Pine.Finance calls itself an AMM order engine. They only support limit orders on Uniswap v1 and v2, but they say they plan on adding stop loss and market functionality across the DEX space, like Aave, Balancer, and others. In order to use it, you have to submit the input token along with your order details through an on-chain transaction, then wait. When the price hits the target, Pine’s network relayer’s should execute the transaction.
There’s a lot more detail in the link above. What is important to note is that each order gets its own order vault, meaning that your order input funds will be stored in a discrete Ethereum address. You can see them on chain.
The project is in beta, and hasn’t been audited, so this one is use at your own risk. I did go ahead and put in a very small order that I’m still waiting on to execute. The gas cost was nominal, about as much as a standard transfer, but I’ll also have to pay gas if I want to cancel the order. This is similar to the way that on-chain DEX like iDEX or Metamask have worked in the past, although Pine is a custodial solution, probably a requirement of the fact that the relayer pays the gas when they execute the trade (and arbitrages the difference).
[Update: Pine replied wanted to clarify the custodial claims:
I’ll need some more time to delve into the process used here. What I am sure of is that during the order process, a deterministic funds vault is created, and tokens are transferred to this vault. Even trusting that these funds are self-custodial, they are removed from the user’s wallet. This may be similar to how 0x works, as mentioned below, and I promise to do more research and follow up on this. ]
LimitSwap is a Uniswap limit order bot that is available on Github. After downloading, you’ll need to export your private keys and configure several settings to get things up and running. Set the tokens you want to trade, set your prices, and then let it go. You’ll also need to hold LimitSwap’s $LIMIT token in your wallet in order for the bot to function.
That’s the promise, anyways. I wasn’t willing to actually give it a shot. The project’s sole developer, who goes by the handle Crypt0Gnome, seem legit, but has taken steps to obfuscate his code. I understand his motives is to fund his development efforts via the $LIMIT token and prevent people from easily modifying his code to circumvent this requirement, but I’m not willing to trust my private keys with something like that.
I won’t go too far into the technical details but to say that he’s written the bot in Python using a Flask front-end and packaged all the dependencies in the zip file. This may make it easy for Windows users to get up and running, but shocked me a bit when I went to download the source code and found an empty repo.
I’m not trying to be unjustly harsh here, Crypt0Gnome seems to be sincere and to be community focused. However, in addition to the closed source nature of the project, I did find the Flask interface buggy and less than polished, and it was hard to justify digging into it when all I wanted to do was set a single limit order for a small amount. I do hope Crypt0Gnome can find a way to fund his project and open it up so that others might contribute to it as well. We’ll see.
The search continues
So while I’ve decided to do a small test transaction with Pine for now, I’m still looking for other solutions, preferably non custodial ones. The 0x protocol may offer a solution if one can find relayers supporting the tokens one wishes to trade, but I’ll need to do more research on that front to say more.
The bot approach would also be preferred over a custodial, on-chain solution if one is willing to maintain the bot, but a closed source solution with a single dev is a bit to risky for me to use, let alone recommend to others.
Google is a graveyard of dead links and others looking for solutions to this problem, so there is a need for it, but for now it seems that there is no good solution. I’ll keep searching and will probably do more research into both of these solutions for a future update.