Briefly, fuzzing is a technique of iteratively modifying the inputs to uncover new code paths in the software. In SNARK development context we can have many variants of fuzzing - low-level fuzzing for ensuring the completness of serialization, arithmetic etc; - SNARK circuit input fuzzing where we try to provide invalid inputs for which we would be able to compute a valid proof <-- Rio does this - SNARK circuit fuzzing <-- Rio does this There are general purpose fuzzers which understand the program code to create more inputs which would increase the coverage, but Rio is special for SNARKs as it understands the circuit context. The idea is to perform transformations on the circuit which should be theoretically be idempotent, for example replace subtraction with adding a negative value. Ideally, when we perform such modifications then the compiled circuits should be exactly the same, but this assumes that we take same optimization paths for different circuit definitions. But when we apply many such mutations to the circuit then it is quite improbable that the compiled versions are the same. But in general - the circuits should still be the same in principle i.e. the set of valid inputs to the circuits should be the same. Now, Rio tries to find witness inputs for which the different mutations of the same circuits lead to conflicting outcome. The different outcomes may be that some input is valid for one circuit but not for other. Or maybe there is some internal error during solving etc. We can additionally also look at different proof systems to ensure that the same circuits behave similarly both for PLONK and Groth16 over different mutations.