Omniscia SaucerSwap Audit
Finding Types
Finding Types
A description of each finding type included in the report can be found below and is linked by each respective finding. A full list of finding types Omniscia has defined will be viewable at the central audit methodology we will publish soon.
Input Sanitization
As there are no inherent guarantees to the inputs a function accepts, a set of guards should always be in place to sanitize the values passed in to a particular function.
Indeterminate Code
These types of issues arise when a linked code segment may not behave as expected, either due to mistyped code, convoluted if blocks, overlapping functions / variable names and other ambiguous statements.
Language Specific
Language specific issues arise from certain peculiarities that the Circom language boasts that discerns it from other conventional programming languages.
Curve Specific
Circom defaults to using the BN128 scalar field (a 254-bit prime field), but it also supports BSL12-381 (which has a 255-bit scalar field) and Goldilocks (with a 64-bit scalar field). However, since there are no constants denoting either the prime or the prime size in bits available in the Circom language, some Circomlib templates like Sign
(which returns the sign of the input signal), and AliasCheck
(used by the strict versions of Num2Bits
and Bits2Num
), hardcode either the BN128 prime size or some other constant related to BN128. Using these circuits with a custom prime may thus lead to unexpected results and should be avoided.
Code Style
In these types of findings, we identify whether a project conforms to a particular naming convention and whether that convention is consistent within the codebase and legible. In case of inconsistencies, we point them out under this category. Additionally, variable shadowing falls under this category as well which is identified when a local-level variable contains the same name as a toplevel variable in the circuit.
Mathematical Operations
This category is used when a mathematical issue is identified. This implies an issue with the implementation of a calculation compared to the specifications.
Logical Fault
This category is a bit broad and is meant to cover implementations that contain flaws in the way they are implemented, either due to unimplemented functionality, unaccounted-for edge cases or similar extraordinary scenarios.
Privacy Concern
This category is used when information that is meant to be kept private is made public in some way.
Proof Concern
Under-constrained signals are one of the most common issues in zero-knowledge circuits. Issues with proof generation fall under this category.