Poolshark Audit

- 4 mins

Poolshark Audit

Markdown Image

Luckily for me, when we wrapped up the GMX audit, I was left with a feeling of “What now?” I was ready to go again. The day after, Owen joined the chat and said we had another audit for Poolshark lined up, and we would start tomorrow.

Poolshark is a decentralized protocol for directional liquidity. It provides much-needed limit orders to DeFi and ways to offset impermanent loss. For more information about Poolshark, check out the docs.

Poolshark utilizes a lot of Uniswap v3’s tick math. My experience with Uniswap v3 was essentially zero at this point, but I had a good high-level understanding of how Uniswap v2 worked. From the get-go, I knew that I was in for some long days. (I will leave a few links to the resources that helped me out a ton at the end.)

Here’s a quick summary of how the system works: Users provide liquidity over a tick range, and when we reach a tick, users’ liquidity gets auctioned off through a gradual Dutch auction. Essentially, users pay an amount of basis points for arbitrageurs to buy their tokens.

I felt more confident going into this audit, despite the codebase being a lot more complex and it not being a traditional audit. This was going to be an adaptive audit, meaning that the team would resolve our findings as we went along. This meant that we could get a slightly different commit every so often that would contain small changes and fixes. It brought a sort of competitive aspect to the audit as well, which was interesting.

The audit

In our initial call with Poolshark founder alphakΞY, he gave us an excellent rundown of how the code was supposed to work. Before I knew better, that recording quickly became extremely valuable because it was now time to start my initial read-through of the codebase. Even with all of the context that I had gathered, I still found it hard to construct a mental model because there were so many different things that needed to be kept track of. I spent around a full week just studying the code and discussing it with my fellow auditors before I felt like I had started to build a solid understanding of how the ticks were handled in the code. An equally big expedition was waiting for me, which was understanding how users’ positions were handled.

After spending approximately three days to grasp how positions were handled, Owen and I engaged in a nine-hour call, discussing everything related to positions. This not only assisted me in developing a strong understanding but also brought to light two critical issues (PS-1 in the report) and (CL-3 in the report), along with numerous leads to pursue.

We are around 2 and a half weeks into the audit, and I still have plenty of leads left to review and test. One of these was to find out what would happen if price movement outpaced the rate at which ticks would be initialized. This scenario indeed led to a loss of users’ funds. The problem was to track down and find the root cause of this. Luckily, Owen is an absolute machine. We hopped on a call and were able to figure out that the issue stemmed from ticks not being initialized, which led to the liquidity we had allocated to that tick range being lost (see EP-2 in the report).

Over the next 3 days, Danny and I went on a tear. During those 3 days, we managed to find 2 critical issues and 2 high issues. It was all due to the lengthy discussion we had about how overlapping positions could cause trouble. The findings can be found in DT-3, EP-3, and CL-4 in the report. Most interestingly, we were able to steal tokens from other users by sandwiching another user’s burn order (CL-2 in the report).

I will also share my favorite finding of the entire audit, which was found by Owen (CL-1 in the report). It involved an underflow in an unchecked block, allowing someone to swap for all the liquidity the pool has at the current price. Besides the ones I shared, we found a ton of other vulnerabilities. You can read the full report here.

That was all for me and as promised here are 3 of the best resources that I came across regarding Uniswap V3.

  1. Uniswapv3book by jeiwan.eth
  2. Smart contract Programmer — has a ton of great videos on Uni v3
  3. Uniswap v3 whitepaper Gradual Dutch Auctions by Frankie, Dan Robinson, Dave White, and Andy8052

  4. Bonus — Uniswap V3 Made Easy by Owen Thurm

Guardian provides an amazing model that is pay-per-vulnerability, which incentives auditors to do a better job and minimizes costs for clients in cases where not many bugs are present or found.

Feel free to reach out to me if you have any questions, and I’ll be happy to elaborate on anything or just connect with more people!