High-level Protocol Breakdown

The Cyfrin team reviewed all protocol features and entry points, including storage mappings data structures, user functions, and external protocol dependencies.

Variable instances of the type OrderStatus enum were particularly interesting since they were heavily used to trigger change based on the current Uniswap v3 pool tick. One particular scenario identified involved circumventing the OrderStatusvalidation to modify orders in a state in which this should not be possible.

Our most relevant findings were concerned with the implementation of the order book as a doubly linked list of BatchOrders with lower/upper ticks for a given target tick price, separated by one tick space.

However, limit orders go in both directions, so additional validation is also required on the direction of orders. Getting this validation wrong can result in registering the deposit of one asset as the other, which could allow an attacker to own an outsized proportion of the deposits for a given position.

This particular issue was fixed in an earlier commit, but we found that this order book implementation still gave rise to issues when creating and canceling orders under certain conditions.

Why is Cyfrin the best choice for this audit

With two of Cyfrin’s co-founders coming from the Chainlink ecosystem, Cyfrin was perfectly positioned for a thorough review of the Oku protocol - which leverages Chainlink automation functions to perform trades.

Our auditors’ deep knowledge of Chainlink meant we could jump quickly into the codebase, be better aware of its potential and limitations, ask more thoughtful questions, and look at edge cases we would’ve not likely thought out otherwise.

The team performed architecture analysis and diagrams, invariant tests, pattern mapping, entry point stress testing, stateful fuzzing, and a manual review process.

Our Auditing Process

At Cyfrin, our audit process is both meticulous and customer-centric. It begins with individual manual reviews of the codebase by each team member. We then examine previous audit reports to identify potential weak areas. This is complemented by an initial ramp-up period for auditors to familiarize themselves with the codebase, followed by continuous internal calls with the client's team throughout the audit timeframe.

We use static analysis tools like Cyfrin Aderyn and Slither to identify minimal findings, and Cyfrin Solodit, our vulnerabilities aggregator, for in-depth research into similar bugs in the field. Techniques like invariant testing and stateful fuzzing also come into play to support the primary manual audit process.

Communication is key in our process; we establish separate internal communication channels at the start of each audit and maintain a separate per-audit GitHub project board for more formal tracking of ideas and findings. Our commitment to our customers and open, ongoing communication is at the core of what we do at Cyfrin.

“At Cyfrin, we aim to be more than the sum of our parts; so each auditor individually follows their process to begin with, and then we come together within the team to exponentiate our findings and creative thought processes. We diverge and converge.” ~ Giovanni Di Siena, Lead Auditor