Starting a quantitative trading firm with 0 experience
Why start a quant trading firm?
In 2021, I was sleeping very little. Naturally, I wanted to find a way to sleep more while making money.
I dreamed about running bots that would print money for me while I lay comfortably in bed.
As a naïve 21 year old, I thought: well, it can’t be that hard.
All of my advisors told me it was a stupid idea. I had no idea who I was up against (Jump, Tower, Jane Street), with 0 domain experience.
They were right.
Prior to Manifold:
- I got into crypto in 2016/17 as a white hat hacker
- I ran validators for a couple of years
- I made some lucky trades and investments during DeFi summer and NFT mania
None of the above had anything to do with quant trading. In fact, I didn’t even know what an “alpha” was!
But as always, I didn’t listen to my advisors. Five years later, I’ve gotten better at that (right shoku?), but 21-year-old me was quite stubborn and loved learning things the hard way.
The early days
A lot of people think quant trading is just:
- Make model
- Find pattern
- Execute
- Make profits
I was one of them. And it was far from the truth.
Some of the early iterations of our trading strategies were quite embarrassing.
We went wide. Arbitrage, spread capture, basis trading, stat arb, yield farming, and even deep learning!
In the beginning, none of them worked. Trading is a zero-sum game. If enough people are playing the same game better than you, there will be nothing left on the bone.
We had to find our edge. But what would it be?
Table selection
Most top firms have an edge in one of the following:
- Speed/latency (trading infrastructure)
- Proprietary data/flow
- Research/alpha generation
On centralized exchanges, the above was already completely dominated by the likes of Jump and Tower.
They already had state-of-the-art low latency infrastructure set up across all major exchanges (Binance, OKX, Bybit, Coinbase, etc). They had fee tiers that we couldn’t touch without their scale of volume. They had clients providing them with juicy flow and data.
Our trading and research infrastructure was basic at best, and we didn’t have an army of engineers and researchers to battle them on their turf.
We had to start by finding a different game, and build an advantage there.
I realized our edge had to be in DeFi, or decentralized exchanges.
Back then, most blockchain foundations were spending a crazy amount of capital incentivizing people to provide passive liquidity to decentralized exchanges. Instead of an orderbook, most decentralized exchanges used an AMM (automated market maker) model, executing trades on a pricing curve instead.
Simply put, decentralized exchanges required a unique trading system to handle both the market data (price, liquidity band/slippage) and order placement (trade execution / confirmation).
The top firms weren’t too aggressive yet in this game likely due to a) deviations from their robust infrastructure b) the market was smaller compared to classic centralized exchanges c) regulatory uncertainty around decentralized exchanges and d) they were already making a lot of money elsewhere.
The talent requirement was also a better fit for our team. We had a unique blend of crypto native engineers fluent with smart contracts (needed for executing trades on chain) working with quantitative researchers from more traditional backgrounds (from Citadel, Tower, etc).
For example, one of our best hires turned out to be a data engineer at an insurance company. He was an individual MEV searcher on the side who had been running his own atomic arbitrage strategies at small scale on the Polygon blockchain. Before he joined, I talked to him through his anonymous 0xaddress@protonmail, and I saw that he had potential scrolling through his bot address’ transaction history on a block explorer.
Before shifting the entire team’s focus into decentralized exchanges, I tested the thesis by writing a simple on-chain trading system entirely in typescript to run an arbitrage strategy between centralized and decentralized exchanges (Binance/FTX vs. top 10 blockchains in terms of liquidity). We called this CEX-DEX arb.
The reason this exists is because blockchains “block” transactions over some block time (some 200 ms, 1-2 seconds, or even several seconds). This is inherently slower than each tick on a centralized exchange, so there will always be some sort of a lead-lag. Most of the liquidity on decentralized exchanges were passive/stale liquidity and not actively managed by bots, so there would be price discrepancies between venues as price discovery mostly happened off-chain.
Even with such a crude, latency-insensitive prototype, the strategy was hitting real arbs, and was profitable after fees!
After months of research going nowhere, I had finally found a glimmer of potential.
Finding an edge
One of the exciting things about the strategy was that it was somewhat working even in its prototype state.
With arbitrage strategies, it’s rare for prototypes to work. By definition, arbitrage is risk free profit on the ground. Usually, there are other people that are readily able to pick it up (faster than you can), and the opportunity is gone or less clear.
We already knew several different ways to make the strategy better:
- Overhaul the typescript system into a different language (faster speed)
- Add more decentralized exchanges per chain, and add more chains (more opportunities to arbitrage)
- More precise math (sizing, slippage)
- Fee optimization (increase our margins per trade)
- Our centralized exchanges were far from top fee tier, which could get lower with higher volumes
- There were creative ways to reduce the gas fees (blockchain fee) per transaction on chain
- Better on-chain execution techniques (increase fill rate)
- Inventory optimization (increase rate of return, capital efficiency, and uptime)
It was all about implementation from here.
The nice thing about high frequency trading is that the market gives you immediate feedback. When you implement something and run the strategy, you get a binary result almost instantly whether it increased profitability. This gave us a very quick feedback loop on engineering to result in dollars.
Quick side story:
I remember December 24, 2021 when Sid (my co-founder) and I were sitting in our apartment office coding through the night. The two of us had no weekends or holidays. Ironically, starting Manifold forced me to work even more and sleep even less.
Through the constant keyboard clacking, neither of us even noticed it was Christmas until around 1am when I looked at the time and said “Sid, it’s Christmas!”
…
30 seconds later (I thought he completely ignored me but had forgotten about it and moved on already) he responded “oh. Merry Christmas.”
And then we went back to coding.
Looking back, this was probably my favorite office where it all started.
Improving and monetizing an edge
This piece is already longer than I thought. I need to practice writing with fewer words.
To save time, I’ll do a deeper dive on just a few of the improvements we made to CEX-DEX arbitrage that made it more profitable.
If you’re not interested in trading nitty gritty, you can skip this part. But maybe some of these techniques will inspire you to find and improve your edge in a different market, or even a completely different field. I will try to explain in words instead of mathematical formulas and code.
As we made the general improvements listed above, CEX-DEX arbitrage was starting to print over $10K per day on just a few million dollars deployed. We had focused our early efforts on getting a new system (written in Go + Solidity) good enough to scale across several chains and 10-20 DEXs on each. We also started integrating newer decentralized exchanges that adopted UniV3’s tick pricing model, which were more efficient DEXs with less price slippage due to concentrated liquidity. With more scale, our CEX trading fees came down, as we jumped up the volume thresholds. We also added more symbols to the trading universe as we added more capital.
Evolving game
As we took down the lower hanging fruits, we noticed that competition was starting to grow rapidly. On some chains, we could no longer trigger arbitrages at a 10 bp spread, because other bots were willing to trigger trades at lower. The game was evolving from a simple “identify arb then execute” bot, which had flushed out the initial hand-click arbitrageurs, to requiring slightly more sophistication.
A quick example:
ETH on Binance is $2,000
ETH on Quickswap on Polygon is $2,001
The spread is 2,001/2,000 = 0.05% = 5 bps
A bot (assuming net of fees and slippage) configured to trigger at any arbitrage opportunity at a 5 bp spread would sell ETH on Polygon and buy ETH on Binance, causing the price to revert back to approximate parity.
This means that our bot would never see an arbitrage opportunity because the other bot would close the spread before ETH on Polygon became $2,002, giving us the 10 bps spread we wanted.
Of course, everyone has a different cost to execute each arbitrage trade based on a) their fees on centralized exchanges b) whether they were taking or making on the CEX leg (making tends to be cheaper or gives you rebates in some cases) and c) their gas fees (blockchain fee to process the transaction, more on this later).
We were starting to run into other firms like Wintermute, and had to run priority-gas-auctions (PGAs) against a set of bot addresses to bid higher on specific transactions. This is a technique from the MEV (miner extractable value) world, where you constantly resubmit a specific transaction with a higher priority gas fee in order to move up the priority within a given block.
To participate in these, you had to:
- Know almost exactly how much you could profit from hitting a certain transaction, giving you the exact fee you would be willing to pay
- Have a reliable infrastructure that would allow you to land transactions within a block of seeing an arbitrage opportunity
- Know which addresses you were bidding against, and quickly know when you won (or lost) the auction
There are similar / adjacent techniques on different blockchains depending on their architecture on how transactions are ordered and submitted. Blockchains constantly changed the rules and mechanisms in order to try to bring more value accrual to users/protocols/the chain itself, and arbitrageurs had to constantly adapt to them.
Gas optimizations
The total gas fees to submit an on-chain transaction is approximately a function of the gas size needed for the transaction multiplied by the gas price, which is based on the current network’s congestion.
Gas price / priority fees come into play during PGA style auctions. There isn’t much further optimization to do here as long as you are landing transactions within a block.
The gas size, however, can be reduced significantly through gas optimizations, which linearly decreases the fees required to transact on chain.
Amongst many, a fun technique we used was efficient bit packing. The ethereum virtual machine (EVM) stores data in 32 byte (or 256 bit) slots. By using smaller data types next to each other, we could get Solidity to group them into a single slot. This reduced read/write (SSTORE and SLOAD) execution costs significantly.
As you can see, there is significantly less zero-padding on our transaction, which reduces the overall size we need to pay for the transaction, which reduces the total fee for our transactions.
Now, we could go for opportunities that were “invisible” to others who had higher gas fees, because it would only be profitable by making these optimizations. For example, an arbitrage trade that would net us $1 after fees may have netted someone else $0 with no optimizations. We would close the spread before other bots would even see the opportunity.
It would also allow us to bid higher on transactions to “win” the arb while staying profitable. Over time, winning more arbs not only meant more profit but also more volume, which compounded into more advantages (better fee tiers on CEXs and hitting larger arbs in one transaction).
Capital efficiency
With more and more optimizations and improvements, we focused all our efforts into scaling the strategy. We went wide by integrating more chains, DEXs, and symbols. With a larger trading universe came higher capacity. It made sense to deploy most of our book into CEX-DEX arb, which was generating over 100% in annualized returns with no down days.
But while our book was growing rapidly from the profits, we knew that there was much more capacity for the strategy. How could we make more with what we had?
The problem at the time was that CEX-DEX arbitrage required capital scattered across venues. It also required you to have inventory ready in several different symbols.
As a quick example, if you are arbitraging between ETH/USDT on Binance vs. Arbitrum, you need ETH and USDT readily available on both venues. Let’s say that you start off with $500K of ETH and USDT each on both venues, and that Binance is trading at a premium. You would end up selling the ETH on Binance while buying ETH on Arbitrum. If the premium persists, you could quickly end up with no more ETH on Binance from selling it all, while having no more USDT on Arbitrum from buying ETH.
Centralized exchanges offer margin services which allows you to take some leverage to keep trading throughout inventory skews. But on these chains, the bots stopped arbitraging if it was tapped out of inventory. To keep it running, we would have to rebalance by moving the now excess-USDT on Binance to Arbitrum and excess-ETH on Arbitrum to Binance.
But even if we were to readily rebalance 24/7, we would still be missing out on a lot of profits. Arbitrage PnL is concentrated during periods of high market volatility, because the spreads get wider. During these moments, $500K of inventory can be used up in mere seconds. During high volatility, exchange withdrawal times go from the already slow ~5 minutes to even longer. This meant our bots couldn’t arbitrage the juiciest moments!
Our first idea was to create an automated system called Hydra, which would be constantly moving capital around, utilizing bridges between blockchains and withdrawal APIs on CEXs. We wanted the system to identify excess assets in certain venues and use them to replenish assets getting low on others. This didn’t work as intended at all. Cross-chain bridges were extremely unreliable. Assets would go missing and disappear, and we’d have to manually track which bridge failed and when. Bridging would also often take too long, and we’d miss out on the volatility anyway.
Then came version 2 of Hydra. Instead of relying on bridging, we created our own on-chain spot margin system by integrating Aave (or something similar if unavailable), a lend/borrow natively deployed on most major chains.
The idea was quite simple. In our previous example, if we bought ETH on Arbitrum, we would end up with excess ETH and run low on USDT. The system would identify the excess ETH, lend some of it out on Aave, and borrow USDT against it.
This allowed our bots to continue arbitraging through high volatility by self-leveraging its assets, and automatically unwinding and leveraging the other way if a discount on-chain turned into a premium.
Although quite simple in implementation, Hydra v2 actually had one of the greatest impacts to our PnL at the time.
Reflection
Looking back, it would have been impossible to figure out all of these techniques at once, although no single improvement was rocket science. If the initial prototype had failed miserably, maybe we wouldn’t have tried to innovate much longer. But once we had a live strategy, we were constantly iterating by monitoring our fill rates, profitability, and figuring out what we could improve / optimize based on the market’s quick feedback loop. This feedback loop helped accelerate growth.
I learned that it is very difficult to crack a game when you start off with tons of mysterious barriers. It is easier to stay ahead if you are amongst the top players (frontier) and have the foundations figured out. Especially in markets, table/game selection is just as important as execution.
Life cycle of an alpha
CEX-DEX arb was a staple profit generator for quite a long time. During its glory days, it printed over six figures a day when paired with high market volatility. We generalized the infrastructure to a point where we could integrate a new chain within an hour. This consistently made us the first arbitrageur on some new chains during times of maximum inefficiency, where we could charge massive spreads.
But as with almost any alpha, it decays over time. With arbitrage especially, competition will reduce the spreads to levels where the margins get much lower. Imagine two firms with exactly equal gas optimizations and fee tiers on CEXs in our PGA example from earlier. Because they have the same cost per transaction, they will end up bidding up the PGA to their minimum profitability. By the end of 2025, CEX-DEX arb was no longer the crazy high-yielding strategy it once was.
Fortunately, by having a stable high-yielding strategy running in the background, we were able to re-invest our time and capital into other, even greater profit generating trading strategies over time.
I could write more about all the other crazy things we came up with in the years after, but that’s a story for another time. CEX-DEX arb still has a special place in my heart because it gave us a legitimate starting point and gave us an anchor to build our position from.